TransWikia.com

Is this ST_Relate result expected?

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?

One Answer

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

Add your own answers!

Ask a Question

Get help from others!

© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP