#4897 closed defect (wontfix)
Interiors of st_difference(geom_a, geom_b) and geom_b intesects
Reported by: | fiedt | Owned by: | pramsey |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 3.1.2 |
Component: | postgis | Version: | 3.0.x |
Keywords: | Cc: |
Description
Hi,
i have an unexpected result of st_difference as it intersects the second input geometry according to st_relate.
WITH my_geoms AS ( -- first geometry SELECT 1 AS id, st_geomfromtext('MULTIPOLYGON(((596365.1172897 5963971.50783237,596356.365586281 5963985.76622559,596393.339074884 5963985.76622559,596388.520721316 5963963.93613391,596365.1172897 5963971.50783237)))') AS geom UNION -- second geometry SELECT 2 AS id, st_geomfromtext('MULTIPOLYGON(((596368.067302089 5963988.71623797,596368.657304566 5963965.21447261,596337.190505754 5963970.32782742,596337.878841978 5963989.30624045,596368.067302089 5963988.71623797)))') AS geom), diff_geom AS ( -- geometry in the exterior of second geometry SELECT 3 AS id, st_difference(t1.geom, t2.geom) AS geom FROM my_geoms t1, my_geoms t2 WHERE t1.id = 1 AND t2.id = 2) -- i expect only the first geometry 'relates' here (interiors intersect) ... SELECT * FROM my_geoms, diff_geom WHERE st_relate(diff_geom.geom, my_geoms.geom, '2********'); -- ... but two rows returned
The result is as expected, if …
- i use st_snaptogrid(…) even with a tiny gridsize like 0.00000001
- round coordinates to integers
My config:
SELECT postgis_full_version();
POSTGIS="3.0.3 3.0.3" [EXTENSION] PGSQL="130" GEOS="3.8.1-CAPI-1.13.3" PROJ="7.1.1" LIBXML="2.9.9" LIBJSON="0.12" LIBPROTOBUF="1.2.1" WAGYU="0.4.3 (Internal)"
Thanks in advance.
Change History (4)
follow-up: 4 comment:1 by , 4 years ago
comment:2 by , 4 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:4 by , 4 years ago
Replying to mdavis:
This is not a bug, it is expected behaviour given the limitations of finite-precision floating-point arithmetic.
This comes up a lot. For a more detailed explanation see the JTS FAQ. It would be good to add this to the PostGIS FAQ too.
Thank you very much for your explanation. I wasn't aware of the inconsistencies. Sorry for any inconvenience.
This is not a bug, it is expected behaviour given the limitations of finite-precision floating-point arithmetic.
This comes up a lot. For a more detailed explanation see the JTS FAQ. It would be good to add this to the PostGIS FAQ too.