data

[mapsam]

Adds the data section to 3.0

cc @GretaCB

[mapsam]

@GretaCB do you think it'd be worth adding a bit of extra context to this section? It's a bit unclear what data is used for, so some examples might be helpful.

[GretaCB]

@mapsam Definitely agree examples are needed. I'm unsure of current usecases of this field, due to improvements in tiling over the years. Curious if anyone else has thoughts on how this field is currently being used so that we can add some relevant examples.

cc @kkaefer @yhahn @stevage

[yhahn]

This used to be used for client-side overlays (displaying pins on a map after it's been loaded).

There are very few implementations AFAIK that support this, nor is the expected behavior around this key well defined. I'd be in favor of removing this property in a new version of the spec.

[stevage]

Huh. What's the relationship between this prop and https://github.com/mapbox/utfgrid-spec which does something pretty similar?

[stevage]

Oh now I remember. the "grids" property is for UTFgrid, which is sort of a rasterisation of the data for client-side interaction, "data" is a vector representation of all the data.

I don't think I have ever used it. It seems really marginal compared to these more likely requirements:

• a reference to a URL to download the entire (non-tiled) raw datasets from which these (presumably raster) tiles have been generated.
• a list of alternative URL schemes that give representations of the same data in different formats (such as .pbf, .geojson, .topojson). For instance, Tilezen was available in those three formats.

The "data" property as it stands is extremely limited: it has to be GeoJSON and it has to be tiled.

I'd recommend against including it.

[mapsam]

Thanks @stevage & @yhahn for the info! We'll add some clarifying notes to the 3.0 release, and plan on removing/deprecating in 4.0.