Cases where ST_Overlaps(ST_Difference(a,b),b) = TRUE

[dannytoone]

POSTGIS="3.4.1 ca035b9" [EXTENSION] PGSQL="160" GEOS="3.12.1-CAPI-1.18.1" PROJ="9.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=https://cdn.proj.org USER_WRITABLE_DIRECTORY=/Users/DToone2/Library/Application Support/proj DATABASE_PATH=/Applications/Postgres.app/Contents/Versions/16/share/proj/proj.db" LIBXML="2.11.7" LIBJSON="0.17" LIBPROTOBUF="1.4.1" WAGYU="0.5.0 (Internal)"

I'm having a tough time thinking through the relational geometry of this, and I can't help but think this is a bug. If b is cut out from a, then the result should intersect with b along the shared boundary, but it shouldn't overlap. A resulting overlap would indicate that the ST_Difference was not complete. I've recently found several cases where ST_Overlaps(ST_Difference(a,b),b) = TRUE, and I thought I'd file a bug report to make sure.

[dannytoone]

pg_dump of table with 25 rows that meet bug conditiojn

[mdavis]

This can be due to these things:

1. (most likely) The results of overlay operations (such a difference) are subject to numerical rounding, which means that the results might not exactly match the input linework. This can cause spatial predicates to be inconsistent with expected results

2. (very rare) a bug in the overlay algorithm sometimes causes outputs to be very different from what is expected. This would show up as a large difference in area from the expected value.

The bottom line is that the results you are seeing are likely the unavoidable result of representing geometry using floating-point numbers, and thus are not a bug.