[postgis-tickets] [PostGIS] #4749: Improve behaviour of spatial predicates with GeometryCollection inputs

[PostGIS]

#4749: Improve behaviour of spatial predicates with GeometryCollection inputs
-------------------------+---------------------------
 Reporter:  mdavis       |      Owner:  pramsey
     Type:  enhancement  |     Status:  new
 Priority:  medium       |  Milestone:  PostGIS 3.1.0
Component:  postgis      |    Version:  2.5.x
 Keywords:               |
-------------------------+---------------------------
 The behaviour of PostGIS spatial predicate operations with geometry
 collection arguments appears to be ill-defined, inconsistent, and error-
 prone.

 For instance, this query causes a segfault:
 {{{
 SELECT st_Intersects(
     'LINESTRING (0 0, 1 0)',
     'GEOMETRYCOLLECTION (MULTIPOLYGON (((922337 -922337, 922337 922337,
 -922337 922337, -922337 922337, 922337 -922337))))'
 );
 }}}

 This query causes an ERROR `GEOSContains: TopologyException`, which is not
 helpful to a typical user:
 {{{
 SELECT ST_Contains(
     'GEOMETRYCOLLECTION (POLYGON ((100 300, 300 100, 100 100, 100 300)),
 POLYGON ((250 250, 250 200, 100 200, 250 250)), LINESTRING (130 180, 220
 220))',
     'LINESTRING (130 180, 220 220)'
 );
 }}}
 There are other cases which succeed.  There may also be cases which appear
 to succeed, but return an incorrect answer.

 This is due to the behaviour of the underlying GEOS library.  The GEOS
 spatial predicate code has some fundamental limitations which mean that it
 cannot handle some cases of this kind (although it could handle more than
 it does now, and should at least ensure that hard failure cannot occur).
 (See GEOS tickets [https://trac.osgeo.org/geos/ticket/1047 1047] and
 [https://trac.osgeo.org/geos/ticket/1042 1042])

 GEOS may be improved, but there may be limits to how many cases it will
 handle.  So PostGIS could implement some work-arounds
  and checks to make the semantics of spatial predicates on
 GeometryCollections more clear and more robust.

 The following cases can be handled with relatively simple code:

 * GCs containing a single non-GC element can be "unwrapped" to convert to
 just that element
 * GCs containing a set of LineStrings or Points can be converted into a
 Multi-geometry
 * GCs containing a set of Polygons which form a VALID MultiPolygon can be
 converted to a MultiPolygon. This requires a potentially-expensive
 validity check, but at least provides functionality

 The following cases cannot be handled easily. They should report a
 appropriate, informative error:

 * GCs containing mixed-dimension elements
 * GCs containing Polygons which form an invalid MultiPolygon

-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/4749>
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.