GEOS allows relate ops on GeometryCollection, while JTS and PostGIS do not

[Mike Taves]

GEOS currently allows relate ops on GEOMETRYCOLLECTION geometries, e.g. with Shapely:

from shapely.wkt import loads
g1 = loads('GEOMETRYCOLLECTION(POINT(1 2),POINT(3 4))')
g2 = loads('GEOMETRYCOLLECTION(POINT(3 4),POINT(1 2))')
print(g1.equals(g2))  # True
print(g1.relate(g2))  # 0FFFFFFF2

or with R

library(rgeos)
g1 <- readWKT("GEOMETRYCOLLECTION(POINT(1 2),LINESTRING(3 4, 5 6))")
g2 <- readWKT("GEOMETRYCOLLECTION(LINESTRING(3 4, 5 6),POINT(1 2))")
g3 <- readWKT("GEOMETRYCOLLECTION(LINESTRING(3 4, 5 6),POINT(1 1))")
gEquals(g1, g2)  # [1] TRUE
gRelate(g1, g2)  # [1] "1FFF0FFF2"
gRelate(g1, g3)  # [1] "1F0F0F0F2"

PostGIS and JTS do not allow these operations, see email threads:

• ​http://lists.osgeo.org/pipermail/postgis-devel/2015-April/024827.html
• ​http://lists.osgeo.org/pipermail/postgis-devel/2015-April/024829.html

In particular, the rationale for the restriction in JTS from Martin Davis:

It's because GeometryCollection have no inherent topology. In other words, geometry components can overlap. To compute relationships with a geometry with overlapping components the components have to be merged to form a topologically valid arrangement. This is more complex and more computationally expensive than the rest of the relate algorithm. So basically it just didn't get done. (It would also introduce potential robustness issues, which I was hoping to avoid in the relate code.

A few relationships (eg intersects and disjoint) could be computed more easily, so they could have special case code added for them more easily.

This task is to assess the situation for GEOS, whether a similar restriction should be set for relate ops, or any other changes. Note that I haven't found a case that returns a bad result, but I haven't looked hard.

[strk]

See how this discrepance created a problem in #752

[strk]

And Paul found this 2009 thread about ​https://lists.osgeo.org/pipermail/geos-devel/2009-January/003880.html which later resulted in r2252

[strk]

So looking at history it seems this lack of exception throwing was due to a misunderstanding between Paul and Martin. Martin was suggesting to remove the check for _UnaryUnion_ while the checks were removed by Paul for all predicates instead.

I suggest to put the checks back in place.

[sirsigurd]

Replying to strk:

I suggest to put the checks back in place.

I don't think it's a good idea because of these reasons:

1. it breaks backward compatibility
2. the reason to have this restriction is that it's hard to implement operations efficiently for collections, not because these operations on collections are invalid
3. it's seems that there is a simple fix (but probably inefficient) that I suggested in #752: if operation is performed on collection, then just use their UnaryUnion, because union doesn't return collections with overlapping components

[strk]

Alright, while the robustness issues are likely still there, let's try this path for 3.6.0. Willing to work on a patch ? It should include testcases.

[sirsigurd]

OK, I'll try to fix it next week.

[strk]

Ticket retargeted after milestone closed

[komzpa]

PostGIS allows these operations starting with 3.0 passing whatever GEOS answer on these as an answer. Supporting disjoint and lucky overlapping geometrycollections is better than not at all, as it requires fancy workarounds that way.

[komzpa]

duplicate #755