TopologyException: side location conflict on valid geometries with touches

[tjay]

Hi,

the TopologyException raised by intersects (see postgis#5390) that was fixed with geos 3.12 still exists when using touches

~$ geosop -v -a "POLYGON((335645.7810000004 5677846.65,335648.6579999998 5677845.801999999,335650.8630842535 5677845.143617179,335650.77673334075 5677844.7250704905,335642.90299999993 5677847.498,335645.7810000004 5677846.65))" -b "POLYGON((335642.903 5677847.498,335642.894 5677847.459,335645.92 5677846.69,335647.378 5677852.523,335644.403 5677853.285,335644.374 5677853.293,335642.903 5677847.498))" intersects
Input A: WKT literal
Read 1 geometries, 6 vertices  -- 146 usec
Input B: WKT literal
Read 1 geometries, 7 vertices  -- 19 usec
[ 1] intersects: A[1] Polygon( 6 ) B[1] Polygon( 7 ) -> bool  --  72 usec
true
Ran 1 intersects ops ( 13 vertices)  -- 72 usec    (GEOS 3.12.1)
~$ 
~$ geosop -v -a "POLYGON((335645.7810000004 5677846.65,335648.6579999998 5677845.801999999,335650.8630842535 5677845.143617179,335650.77673334075 5677844.7250704905,335642.90299999993 5677847.498,335645.7810000004 5677846.65))" -b "POLYGON((335642.903 5677847.498,335642.894 5677847.459,335645.92 5677846.69,335647.378 5677852.523,335644.403 5677853.285,335644.374 5677853.293,335642.903 5677847.498))" touches
Input A: WKT literal
Read 1 geometries, 6 vertices  -- 141 usec
Input B: WKT literal
Read 1 geometries, 7 vertices  -- 19 usec
Run-time exception: TopologyException: side location conflict at 335642.90299999999 5677847.4979999997. This can occur if the input geometry is invalid.
~$ echo $?
1

[dr-jts]

Thanks for raising this again. This makes sense, since the reason intersects worked on this case in 3.12 is that it used a different algorithm than the one used for the general predicate case.

I confirm this is an issue in JTS as well.

A new RelateNG algorithm is in the works which will hopefully solve this problem. I'll test and report back here soon.

[dr-jts]

The new RelateNG algorithm (in progress, in JTS) correctly executes this case. So this will be fixed once that code is released and ported to GEOS.