Potential Bug in ST_Crosses.

[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 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)

Here is the visual:

Version:

The result of "pragma version;" is [('v0.9.2', '3c695d7ba9')]

I used "FORCE INSTALL spatial FROM 'http://nightly-extensions.duckdb.org/';" in the Python client.

[cuteDen-ECNU]

Hi, Max! It was confirmed as a libgeos bug.

[Maxxen]

Alright, thanks! I suspected that, will make sure to update GEOS again soon!