Opened 7 years ago

Closed 7 years ago

#3678 closed defect (wontfix)

Invalid geometry in a table returns conflicting ST_Intersects results

Reported by: Mike Taves Owned by: pramsey
Priority: medium Milestone: PostGIS 2.3.2
Component: postgis Version: 2.3.x
Keywords: Cc:


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


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.

Change History (2)

comment:1 by Mike Taves, 7 years ago

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.

comment:2 by pramsey, 7 years ago

Resolution: wontfix
Status: newclosed

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.

Note: See TracTickets for help on using tickets.