[PostGIS] #5788: ERROR: XX000: GEOSIntersects: TopologyException: side location conflict at

[PostGIS]

#5788: ERROR:  XX000: GEOSIntersects: TopologyException: side location conflict at
--------------------------------+---------------------------
  Reporter:  Lars Aksel Opsahl  |      Owner:  pramsey
      Type:  defect             |     Status:  new
  Priority:  medium             |  Milestone:  PostGIS 3.4.4
 Component:  postgis            |    Version:  3.4.x
Resolution:                     |   Keywords:
--------------------------------+---------------------------
Comment (by mdavis):

 The reason `ST_Intersects` works with the latest PostGIS but not with the
 older version is that GEOS 3.13 uses the new RelateNG algorithm, which
 handles GeometryCollections correctly.

 The difference in computed areas is caused by slight differences in the
 resultant geometries computed by `ST_Intersection`.  The results of the
 pairwise intersections produce some narrow sliver polygons (which have
 some small area), whereas the full-geometry intersection produces only a
 LineString result (with zero area, of course).

 I suspect the reason for the difference in intersection results is that
 the full intersection triggers some snapping due to robustness handling,
 whereas the pairwise ones don't in all cases.  Note that the geometry in
 the `free_area_geo_before_must_overlap` table contains numerous very
 narrow slivers, in addition to some larger polygon elements.  This kind of
 situation is likely to require internal snapping.

 Also note that the computed area (0.1569281251764355) is **much** smaller
 than the area of the `free_area_geo_before_must_overlap` input
 (25159.949244602714).  So, it's effectively zero, just like the snapped
 result.

 This is yet another lesson about working with double-precision geometry -
 geometric operations are not precise, and not commutative.  Different
 sequences of geometric operations on identical inputs may not produce
 exactly identical results, due to internal rounding.  Workflows need to
 incorporate some error tolerances to allow for this.  (This is exactly
 analogous to the situation when doing sequences of numerical operations on
 floating-point numbers.  Exact answers cannot be expected.)
-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/5788#comment:1>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.