-
Notifications
You must be signed in to change notification settings - Fork 354
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unexpected result for intersection of Geometrycollection with polygon? #1059
Comments
Well, that depends on the semantics of handling overlay of GeometryCollections. At the moment it uses "union semantics" - the overlay result is the result of unioning the inputs first. Given this, the result makes sense. The alternative is "collection semantics", where the result is the collection of the overlay applied to each collection element separately. If this behaviour is desired it's fairly easy to build externally. Which one is preferable is likely a matter of preference (or use case). It's worth noting that the in-progress support for GeometryCollections and spatial predicates will also use union semantics. |
OK, I expected the "collection semantics", but it will indeed be a matter of preference/use case you are thinking about. At first sight, I think it is even easier to apply "union semantics" if "collection semantics" would be the default as you just need to call union() on the input collection(s) while for the other way around you need to write a loop and collect everything again? For consistency, it does sound logical that the same semantics are used for overlays and spatial predicates, whatever is used. |
The intersection of a geometrycollection with 4 polygons with a Polygon that overlaps with all four polygons in the collection results in one Polygon. Is this correct?
Issue created based on a slightly more complicated case posted on stackoverflow.
The text was updated successfully, but these errors were encountered: