Geographic Information Systems Asked by Peter Stace on August 8, 2021
The following PostGIS query involving ST_Relate
gives FFFFFF102
as its result:
SELECT ST_Relate(
ST_GeomFromText('POLYGON EMPTY'),
ST_GeomFromText('MULTILINESTRING((0 0,0 1),(0 1,1 1,1 0,0 0))'),
1);
I would have expected it to give FFFFFF1F2
instead. My reasoning for expecting that result:
I’m passing in 1
as the boundary node rule parameter, which corresponds to the OGC/MOD2 rule. My understanding of the MOD2 rule is that a node will be considered as part of the boundary of a collection geometry if and only if it appears in the boundary of child geometries an odd number of times. In this case, 0 0
is part of the boundary of both children in the MULTILINESTRING
collection, as is 0 1
(i.e. they appear an even number of times, so shouldn’t be part of the boundary).
The 8th digit in the intersection matrix code indicates the dimension of the intersection of the exterior of the first geometry and the interior of the second geometry. The first geometry is empty, so its exterior is the entire plane. And assuming my understanding above is correct, then the boundary of the second geometry should be empty. So therefore there should be no intersection (i.e. the 8th digit should be F
).
This is using PostGIS version POSTGIS="3.1.0 5e2af69"
. I have seen the same behaviour in GEOS version 3.8.0
as well.
Can anyone help me understand why I’m getting FFFFFF102
rather than FFFFFF1F2
?
This reveals a bug in the JTS/GEOS Relate algorithm. As noted, it was not correctly computing the DE-9IM E/B entry for the case of an empty geometry and a closed linear geometry with no boundary.
This is fixed by JTS 671, and will be fixed in GEOS soon.
Correct answer by dr_jts on August 8, 2021
Get help from others!
Recent Questions
Recent Answers
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP