search

mapbox / vector-tile-spec

Mapbox Vector Tile specification
https://www.mapbox.com/vector-tiles/specification/
Other
890 stars 209 forks source link

Support GeometryCollection? #110

Open e-n-f opened 6 years ago

e-n-f commented 6 years ago

For feature parity with GeoJSON; otherwise it is probably more trouble than it is worth.

It would be a new GeomType with a corresponding new geometry-like message which contains an array of messages with a GeomType and a geometry (any of which could also be a nested GeometryCollection).

flippmoke commented 6 years ago

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.

mboeringa commented 6 years ago

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?

chaeron commented 5 years ago

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

prasanjitdash commented 2 years ago

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.