Intersection robustness failure

[dbaston]

An intersection operation with floating precision fails between the valid inputs below. Extracted from r-spatial/sf#794

Edit: removed WKT dump

[dbaston]

Actually, here is an attached XML from TestBuilder. GitHub made me change the extension to .txt.
300.txt

[dr-jts]

Those geometries are riddled with classic robustness-failure issues. Lots of nearly coincident points, and at least one place where the boundary of a geometry has a "narrow Z" pattern. So not surprising that they fail on overlay.

Because of the linework pathologies (in particular the narrow Z), likely the snapping heuristic fails as well. And reducing precision is likely to introduce invalidity (i.e. due to the Z collapsing).

As always, snap-rounding would probably solve these problems.

[dr-jts]

Update: snap-rounding overlay does allow this intersection operation to complete successfully.

First, here's an image of the highly "unclean" linework on the border of the two input polygons (note: this is using the TestBuilder Reveal Topology mode - in actuality the gaps/overlaps are on the order of 1e-8 and hence almost invisible)

Executing the intersection using snap-rounding overlay with a grid size of 1e-5 gives the output shown below (black lines). The output is a MultiLineString (which contains gaps, as expected given the overlaps along the boundary).

[gvsharma]

interesting , no response from anyone?

[dr-jts]

This was fixed by the introduction of OverlayNG in #599.