Opened 3 years ago
Closed 2 years ago
#4932 closed defect (fixed)
Possible Bug with geography ST_Intersects / ST_Distance
Reported by: | robe | Owned by: | pramsey |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 3.3.0 |
Component: | postgis | Version: | master |
Keywords: | Cc: |
Description (last modified by )
Nek on PostGIS noted the documentation for geography ST_Intersects is wrong.
https://postgis.net/docs/ST_Intersects.html
In the docs it says this should return true
SELECT ST_Intersects( 'SRID=4326;LINESTRING(-43.23456 72.4567,-43.23456 72.4568)'::geography, 'SRID=4326;POINT(-43.23456 72.4567772)'::geography );
But it returns false. I just checked on my PostGIS 3.2 build and it indeed returns false.
However ST_Distance returns 0
SELECT ST_Distance( 'SRID=4326;LINESTRING(-43.23456 72.4567,-43.23456 72.4568)'::geography, 'SRID=4326;POINT(-43.23456 72.4567772)'::geography );
Even _ST_DistanceTree returns 0
SELECT _ST_DistanceTree( 'SRID=4326;LINESTRING(-43.23456 72.4567,-43.23456 72.4568)'::geography, 'SRID=4326;POINT(-43.23456 72.4567772)'::geography );
However _ST_DistanceUncached returns a small number, so perhaps that is what ST_Intersects is using
SELECT _ST_DistanceUncached( 'SRID=4326;LINESTRING(-43.23456 72.4567,-43.23456 72.4568)'::geography, 'SRID=4326;POINT(-43.23456 72.4567772)'::geography );
returns - 1.4148932702941524e-09
same answer with PostGIS 3.1.2
Change History (7)
comment:1 by , 3 years ago
Description: | modified (diff) |
---|
comment:2 by , 3 years ago
comment:4 by , 3 years ago
Milestone: | PostGIS 3.1.4 → PostGIS 3.2.0 |
---|
high precision math re-write sounds too dangerous for a micro release.
comment:7 by , 2 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
I'm loath to back-port this as it will alter behaviour in places (things that had one result will now have another). The actual measurement differences are very small, but that won't matter to people who have one query that returns 30 items and a new one that returns 29 with a patch level update.
I'm sure it's a tolerance issue in the geographic calculation, but I have wrung out all "knob twiddling" solutions and what's left is a re-write that uses some higher-precision math ala GEOS to stamp out the inconsistencies in the core pt/seg computations on the sphere.