Retry with boost::geometry::intersection if fast_clip fails #597
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.
As per #594 and #574/#580, Maplibre GL Native objects to the 0-width borders around tile margins that
fast_clip
can create.This PR falls back to
boost::geometry::intersection
when we're in a situation where self-intersections persist. We don't usemake_valid
(i.e. the custom correct code) at all in this case, just plain vanillaboost::geometry::correct
. I've tested it with the original problem regions of Venice and Copenhagen, and with the additional problem areas of Athens and Shetland, and it appears to work reliably.Performance is downgraded but less than I expected:
Given that this retains most of the performance gain while reliably producing correct geometries, I'm inclined to merge this. We can look at options for other clipping algorithms in the future.
There is one remaining issue where South Uist can disappear at z5, but I think this is a simplify problem rather than a clipping problem - simplify is creating a 0-width connection between the two islands.