polygon clipping errors about d3-geo-polygon HOT 15 CLOSED

Can you reproduce the inversion from the screenshot alone? Or would it help if I tried to create a reduced test case?

from d3-geo-polygon.

It's just a question of fiddling with the mouse and then printing projection.rotate()…

A bad case:

projection = d3.geoAirocean().rotate([88, -37.8, -73.2])

https://observablehq.com/d/7c5b4f1ff5a76024

from d3-geo-polygon.

And

projection.rotate([-70.2, -47, -121.6])

creates an inversion of land and ocean

from d3-geo-polygon.

Another inversion: https://observablehq.com/d/303582dda96b0649

from d3-geo-polygon.

I've updated the notebook to only show the offending polygon (and added the ability to step through all polygons).

from d3-geo-polygon.

from d3-geo-polygon.

I've fixed the problematic point in https://unpkg.com/[email protected]/
(see visionscarto/world-atlas@590dbeb), and it fixes the inversion problem.

from d3-geo-polygon.

Looks like I finally nailed that bug. There is a case where we would rejoin with a line if the segment's first and last points were coincident. But the test for coincidence used a very tolerant pointEqual, and two points seperated by 1e-6 were considered equal, and they were rejoined directly, creating this "bleeding". Fixed at a08a09e

Test here: https://observablehq.com/d/7c5b4f1ff5a76024

(EDIT - Dec. 2019: the bug is still here — looks like I forgot to merge the change)

from d3-geo-polygon.

We still get some inversions on the example, but I'm having a hard time isolating them.

from d3-geo-polygon.

What's your process and intuition to narrow them down?

from d3-geo-polygon.

To find the problematic rotations I have no method, I just rotate the airocean globe until I see a flash of black (if such a thing exists). If I'm lucky to find one, I can just type projection.rotate() in a cell to read the values.

To find the faulty code, my method in this case is a bit like what you did in the notebook: I remove as much "matter" as I can from the polygons, and try to get to (ideally) a faulty triangle or a polygon with very few edges.

Then I write two test cases in node, one with the faulty rotation, the other with a different rotation, which is ideally very close to the faulty one, but does not break.

After that, I start to edit the src code, adding console.warn() where I suspect there might be a difference, and run the two test cases side by side. The numbers change a bit, but I'm looking for places where the structure is different. In the case of a08a09e, I ended up at this specific line of code, and saw that the pointEqual test was suddenly saying true and triggered the bug.

from d3-geo-polygon.

What assumptions can be made about the inversions so far? E.g.:

• Are they limited to certain types of projections?
• Are they guaranteed to be caused only by a faulty geometry? What kind of faults (e.g. overlaps/intersections)?
• Will the inversion only be triggered by lines that get cropped by the projection's sphere?

from d3-geo-polygon.

from d3-geo-polygon.

Not sure if related or relevant: compareIntersection appears to apply some fuzz via epsilon.

Related issue: #3

from d3-geo-polygon.

Closing for now, as bleeding issues are solved. If we can find an inversion we'll open a new issue.

from d3-geo-polygon.