search

mapbox / vector-tile-spec

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

Adopt explicit MultiPoint, MultiLineString, and MultiPolygon types #77

Open jfirebaugh opened 8 years ago

jfirebaugh commented 8 years ago

This is the "change for a future release" tail of https://github.com/mapbox/vector-tile-spec/issues/30.

Currently, it's not possible to encode a MultiPoint geometry with a single point in a way that is distinguishable from a Point geometry. Thus VTs cannot round-trip GeoJSON or other formats in which a singleton MultiPoint is valid. The same is true for singleton MultiLineString and MultiPolygon.

If the spec adopted explicit MultiPoint, MultiLineString, and MultiPolygon types, it would resolve this compatibility issue.

jfirebaugh commented 8 years ago

The other corner case here that vector tiles cannot handle are Multi* geometries with zero members.

sfkeller commented 8 years ago

As already communicated to @flippmoke I strongly support this issue and would also remind that this issue refers the standardized notion of MultiPolygon as defined in OGC SF (see also #78 ). Such explixit types make almost no difference for the encoder/creator and the format but it's a big relief for decoders/receivers which have GIS formats in mind.

Sumbera commented 7 years ago

I came to the similar issue accidentally for decoding multi polygons with holes https://github.com/mapbox/geojson-vt/issues/79. Please consider also to use more explicit way for indicating interior/exterior rings in multi polygons (that is without an overhead of calculating area first to get this trivial information).

e-n-f commented 6 years ago

I propose that this be represented as an optional boolean message in the feature, like

                optional bool multi_geometry = 6;

which will be ignored by existing software but will give new information to new software that wants to make this distinction.

joto commented 6 years ago

optional bool multi_geometry = 6; is a very inefficient encoding for what is essentially a bit, blowing it up to two bytes.

How about adding a new field that is essentially a copy of the existing GeomType but has enum values for all the single and multi variants?

And yes, it is slightly less backwards-compatible, but cleaner and smaller, which is, thinking long-term here, better.

e-n-f commented 6 years ago

I would rather not include the information at all than do something incompatible, since we mostly do OK without it now. Maybe we could only add the flag in the rare case where a feature is tagged as Multi in the source data but has only one point, segment, or ring.