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
I have found another edge case while dividing up OpenStreetMap country boundaries into QuadTiles.
I have attached the geojson in the "genericTestCase" format that @bluenote10 put together.
I am intersecting a polygon of Spain's border, which has an enclave cut out for Gibraltar, with a square tile. The Gibraltar hole is completely contained within the square tile, so should be a straight forward intersection.
This is what I expect:
This is what I get. Note the internal hole is coloured red, as it is now a part of the multipolygon
Thanks for confirming this is a bug. I have a workaround I am using at the moment. For polygons which have interior holes, I am now running intersect manually on each of the rings of the polygon. I then combine the results by using Diff to subtract the interior rings from the outer ring. This is working well, except for an issue where Diff doesn't seem to set the orientation of holes properly. I have raised a separate issue for this (#129) and am manually correcting the orientation for interior rings.
I have found another edge case while dividing up OpenStreetMap country boundaries into QuadTiles.
I have attached the geojson in the "genericTestCase" format that @bluenote10 put together.
I am intersecting a polygon of Spain's border, which has an enclave cut out for Gibraltar, with a square tile. The Gibraltar hole is completely contained within the square tile, so should be a straight forward intersection.
This is what I expect:
This is what I get. Note the internal hole is coloured red, as it is now a part of the multipolygon
Here are is the generic test case geojson:
issue128.geojson.txt
And here is the actual geojson result I get from the intersection:
actual-output.geojson.txt
Perhaps the winding order of the interior ring is reversing?
I am using the master branch of this repo, and I have also applied the #125 pull request too.
@bluenote10 If you get a chance, would you mind running this through your Rust implementation to see how it handles it?
The text was updated successfully, but these errors were encountered: