You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a summary issue fo bug reports about OverlayNG failure cases.
The cases always (?) involve nearly-coincident linework (either in a single input or between inputs). The result of overlay operations is obviously incorrect (i.e. it is drastically different from the expected result).
An Area-Check heuristic was added in #812, but this does not handle all cases. Any fix should be tested to see if it handles the cases resolved by that fix (shapely/shapely#1216, GEOS-1144.
add an Envelope-Check heuristic sanity check (analogous to the heuristic area check). This will not catch all cases, however.
use a Area-Only Intersection check, utilizing the IntersectionArea approach. This should be (almost?) fully robust, at the cost of decreased performance
Add supplementary vertex location checks for linework with topology determined by geometry edge intersection. This should allow detecting invalid topology graphs.
The text was updated successfully, but these errors were encountered:
dr-jts
changed the title
OverlayNG produces wildly incorrect results in some situations
OverlayNG produces obviously incorrect results in some situations
Aug 21, 2023
There is one more issue with OverlayNG area heuristic check: #951 - mentioning it here for visibility just in case it is related.
dr-jts
changed the title
OverlayNG produces obviously incorrect results in some situations
Summary: OverlayNG produces obviously incorrect results in some situations
Oct 5, 2024
dr-jts
changed the title
Summary: OverlayNG produces obviously incorrect results in some situations
Summary: OverlayNG producing obviously incorrect results
Oct 5, 2024
dr-jts
changed the title
Summary: OverlayNG producing obviously incorrect results
Summary: OverlayNG failures
Oct 5, 2024
This is a summary issue fo bug reports about OverlayNG failure cases.
The cases always (?) involve nearly-coincident linework (either in a single input or between inputs). The result of overlay operations is obviously incorrect (i.e. it is drastically different from the expected result).
Options for fixing
An Area-Check heuristic was added in #812, but this does not handle all cases. Any fix should be tested to see if it handles the cases resolved by that fix (shapely/shapely#1216, GEOS-1144.
IntersectionArea
approach. This should be (almost?) fully robust, at the cost of decreased performanceThe text was updated successfully, but these errors were encountered: