Implement alternative handling of polygons with holes #700
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.
I'd like to propose an updated solution to handling non-simple polygons that does not require the "polish" function. Here is my reasoning behind this:
The polishing function was used to remove duplicate coordinates that were sometimes added. I found that these were probably "holes", because every time a polygon had such a duplicate coordinate, there was an entry in
_holes
when the polygon was logged withpolygonizer.getGeometry()
injstsValidate()
(nowjstsSimplify()
). The screenshot shows the geometry with a hole at the top and the OL coordinates at the bottom:So in order to remove the holes, now
getExteriorRing()
is called for each polygon. To reproduce a polygon with a hole, draw a geometry like this:Screencast.from.17.11.2023.11.09.13.webm
For a similar reason I removed the "getInteriorRing" stuff from
jstsAddPolygon()
. However, holes were still present in the polygons and had to be removed as described above. Everything still worked fine without the code, though, so I left it like that.Finally,
getGreatestPolygon()
also works if there is only one polygon so I removed theif
.@lehecht Could you please have a good look at this and check if this still handles all the cases that you tested? You spent much more time with this than I did so you probably know all the edge cases. It's entirely possible that my implementation does not handle some cases that your version handles correctly.
References #634