Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

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

comment:1 by mdavis, 4 years ago

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.

comment:2 by mdavis, 4 years ago

Resolution: wontfix
Status: newclosed

comment:3 by mdavis, 4 years ago

This has been added as a FAQ to the PostGIS doc.

in reply to:  1 comment:4 by fiedt, 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.

Note: See TracTickets for help on using tickets.