Opened 7 years ago

Closed 3 years ago

#725 closed task (duplicate)

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

Reported by: Mike Taves Owned by: sirsigurd
Priority: minor Milestone: 3.8.0
Component: Default Version: 3.1.0
Severity: Unassigned Keywords:
Cc: fedoseev.sergey@…

Description

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:

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.

Change History (12)

comment:1 by strk, 7 years ago

See how this discrepance created a problem in #752

comment:2 by strk, 7 years ago

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

comment:3 by strk, 7 years ago

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.

comment:4 by strk, 7 years ago

Version: svn-trunk3.1.0

comment:5 by sirsigurd, 7 years ago

Cc: fedoseev.sergey@… added

in reply to:  3 comment:6 by sirsigurd, 7 years ago

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

comment:7 by strk, 7 years ago

Milestone: GEOS Future3.6.0

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.

comment:8 by sirsigurd, 7 years ago

Owner: changed from geos-devel@… to sirsigurd
Status: newassigned

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

comment:9 by strk, 6 years ago

Milestone: 3.6.03.7.0

Ticket retargeted after milestone closed

comment:10 by robe, 5 years ago

Milestone: 3.7.03.8.0

comment:11 by komzpa, 3 years ago

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.

comment:12 by komzpa, 3 years ago

Resolution: duplicate
Status: assignedclosed

duplicate #755

Note: See TracTickets for help on using tickets.