-
Notifications
You must be signed in to change notification settings - Fork 211
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
Support GeometryCollection? #110
Comments
I am against this as I do not think we should be matching geojson exactly as part of the specification. I think it would add layers of complexity for encoders and decoders as well that I do not feel is necessary. I do think it could save some memory by grouping items with the same properties together, however, I do not think this is necessarily worth it. |
I am also not much in favor of GeometryCollection, and especially not if they can be nested as well. From a practical and technical point of view, there is just no sane way to deal with them in rendering. In OSM, we have the type=site relation, and a few other more obscure obsolete relation types like type=collection, which are essentially the equivalent of GeometryCollection, as they may contain both nodes, ways and other relations, meaning they could potentially have unlimited nesting via the relations members. Every now and then, a question pops up about rendering these. My personal answer is always the same: a "collection" type relation is fine as an administrative tool, to group stuff, and to be able to hyperlink through the collection on the openstreetmap website, going from one member to another. But rendering?: NO! How are you ever going to create a valid geometry or styling for unlimited nested structures? |
Not having support for GeometryCollection in MapBox has caused me some headaches. It's a standard part of GeoJSON, and should be supported as such. Worth noting is that the GeoJSON standard does state that GeometryCollections should NOT be nested....so support of a single level of GeometryCollection should be a reasonable thing to implement. See: https://tools.ietf.org/html/rfc7946#section-3.1.8 |
Any follow-up or progress on this issue of lacking GeometryCollection support. Many useful datasets have such collection and it would be useful to have this support. |
For feature parity with GeoJSON; otherwise it is probably more trouble than it is worth.
It would be a new
GeomType
with a corresponding newgeometry
-like message which contains an array of messages with aGeomType
and ageometry
(any of which could also be a nested GeometryCollection).The text was updated successfully, but these errors were encountered: