Difference operation resulted with a wrong geometry as a result of a precision limitation

[yanivnavon]

Difference between two geometries results with a wrong geometry as sometimes systems can hold up to 6 digits after the decimal point, hence cannot hold the full number. In such cases, GEOS calculator might take two points as "does not match" each other. Originally, these points are matching each other.

Screenshot: ​http://dev.skylinesoft.com/Up/Navon/General/screenshot.png

With reference to bug #704:

1) Geometry A: POLYGON ((580 337, 580 342.1, 581.3 338.8, 581.3666666666667 338.8833333333333, 581.4166666666666 339, 581.45 339.1166666666667, 581.5166666666667 339.26666666666665, 582.4 341.9, 583.5 337.1, 580 337)) 2) Geometry B: POLYGON ((578.3 340.9, 578.4166666666666 340.9166666666667, 578.55 340.9166666666667, 585.1 341, 585 340.4, 578.9 340.4, 578.3 340.9))

3) Union A -> B = C (Multipolygon) 4) Difference C -> B

[pramsey]

As of 3.9 you might find the snap-rounded operations (difference with a tolerance) provide more predictability in terms of holding to a particularly domain grid, assuming you can stand the initial round-off stop.

[mdavis]

The snapping noding works well for this, and doesn't require rounding all the output coordinates. Perhaps we should expose that capability as well as snap-rounding.