Fix IncrementalDelaunayTriangulator to ensure triangulation boundary is convex #1004
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds logic to
IncrementalDelaunayTriangulator
to ensure that the triangulation boundary is always convex (as per specification). This is required because the "frame" created to contain the triangulation construction is not infinitely distant from the input points. This has been causing robustness failures in cases where a site lies very close to the convex hull of the input.The logic required is additional checks when determining whether to flip an edge to maintain the Delaunay condition :
The reason this code was not included in the original development of
IncrementalDelaunayTriangulator
is that it is not mentioned in most descriptions of the algorithm. The logic is described in this blog post, and also appears in the triangle code (lines 8592-8614).This is a more robust solution than the frame size increase in #931.
Fixes #1002.
Fixes #477.
Also fixes various issues reported for ConcaveHull ( libgeos/geos#719, libgeos/geos#946)