ST_Crosses returns incorrect answer when dealing with geometry collection

[cuteDen-ECNU]

Consider the following statement:

SELECT ST_Crosses(g1, g2), ST_Crosses(g1, g3)
FROM (SELECT 
ST_GeomFromText('GEOMETRYCOLLECTION (POINT (7 1), LINESTRING (6 5, 6 4))') As g1,
ST_GeomFromText('POLYGON ((7 1, 1 3, 3 9, 7 1))') As g2,
ST_GeomFromText('POLYGON ((1 3, 3 9, 7 1, 1 3))') As g3
) As sub;
-- actual {true, false}; expected {false, false}

It is noticed that g2 and g3 present the same polygon with different order, while ST_Crosses(g1, g2) and ST_Crosses(g1, g3) give different results, which seems like a bug.

The result of ST_Crosses(g1, g2) is expected to be false because there is no interior intersection, according to the definition:

ST_Crosses(A, B) ⇔ (dim( Int(A) ⋂ Int(B) ) < max( dim( Int(A) ), dim( Int(B) ) )) ∧ (A ⋂ B ≠ A) ∧ (A ⋂ B ≠ B)

It can be reproduced by:

bin/geosop -a "GEOMETRYCOLLECTION (POINT (7 1), LINESTRING (6 5, 6 4))" -b "POLYGON ((7 1, 1 3,  3 9,  7 1))" crosses
# actual{true}; expected{false}

Version is the latest in github:

 POSTGIS="3.5.0dev 3.4.0rc1-839-g61bc019eb" [EXTENSION] PGSQL="170" GEOS="3.13.0dev-CAPI-1.18.0" PROJ="8.2.1 NETWORK_ENABLED=OFF URL_
ENDPOINT=https://cdn.proj.org USER_WRITABLE_DIRECTORY=/tmp/proj DATABASE_PATH=/usr/share/proj/proj.db" LIBXML="2.9.13" (core procs fr
om "3.5.0dev 3.4.0rc1-750-g89fb96385" need upgrade)

[dr-jts]

The IM matrix computed by relate is very wrong as well (e.g. it says that dim(Int n Int) = 2):

bin/geosop -a "GEOMETRYCOLLECTION (POINT (7 1), LINESTRING (6 5, 6 4))" -b "POLYGON ((7 1, 1 3,  3 9,  7 1))" relate 
212FF0212

[JamesParrott]

I can recreate this, but it's very sensitive to the floating-point value of the first point (7, 1), and the bug does not occur when the line string is replaced by a point.

root@523c8b976142:/tmp/geos/build# geosop -a "GEOMETRYCOLLECTION (POINT (6.9999999999999999 1), LINESTRING (6 5, 6 4))" -b
 "POLYGON ((7 1, 1 3,  3 9,  7 1))" crosses
true
root@523c8b976142:/tmp/geos/build# geosop -a "GEOMETRYCOLLECTION (POINT (6.999999999999999 1), LINESTRING (6 5, 6 4))" -b
"POLYGON ((7 1, 1 3,  3 9,  7 1))" crosses
false
root@523c8b976142:/tmp/geos/build# geosop -a "GEOMETRYCOLLECTION (POINT (7 1), POINT (60 5))" -b "POLYGON ((7 1, 1 3,  3 9
,  7 1))" crosses
false

[dr-jts]

This isn't a precision problem. It's an issue with the current relate algorithm not handling mixed-dimension GeometryCollections correctly. Likely it involves an incorrect evaluation of endpoints as boundary points.

[cuteDen-ECNU]

Another trigger case seems to have the same root cause:

bin/geosop -a 'GEOMETRYCOLLECTION (POINT (2 2), LINESTRING (0 0, 1 1))' -b 'LINESTRING ( 2 2, 3 3)' relate
# 1F10F0102

It says that dim(Int n Int) = 1, which is the same as dim(b).
Meanwhile, POINT(2 2) is the start-point of b.