Invalid geometry in a table returns conflicting ST_Intersects results

[Mike Taves]

In the example shown below, ST_Intersects returns both true and false for the same invalid LINESTRING on multiple rows of a table:

DROP TABLE IF EXISTS invalid;

CREATE TEMP TABLE invalid(id serial primary key, geom geometry);
INSERT INTO invalid(geom)
SELECT 'LINESTRING(-85.6600021 30.7976979,-85.6600021 30.7976979)' FROM generate_series(1, 3);

SELECT id, ST_Intersects('LINESTRING(-85.6600021 30.7976979,-85.6600021 30.7976979)', geom)
FROM invalid;
 id | st_intersects
----+---------------
  1 | f
  2 | t
  3 | t
(3 rows)

Spatial predicates from both JTS and GEOS have no love for invalid geometries, and this should normally be false, as they are essentially regarded to be disjoint (FFFFFFFF2). All rows are true with ST_Disjoint.

This issue comes from ​the wild.

[Mike Taves]

I should note that I get the same results for the example with ST_Intersects with PostGIS 1.5 and 2.3, so this isn't a new one.

[pramsey]

I'm afraid this one has to be closed. Computational geometry algorithms can either pay the overhead of cleaning up inputs at every invocation, or expect some kind of minimal structural rules to be in place before the data arrive (validity). We opt for the latter approach, and the reason we tell people "you should make sure your geometry is valid" is precisely because algorithms will get wrong answers with invalid inputs.