Mapbox json field

[systemed]

As documented in #77, mapbox/mbtiles-spec#43, mapbox/mbtiles-spec#46 and mapbox/mbtiles-spec#47, some Mapbox clients require a mysterious json entry in the metadata table which contains further metadata about the tileset.

@ericfischer has done a sterling job of unofficially documenting it in this PR.

I will admit to not being too fond of this - it seems, effectively, to be a bit of a hack (storing json in a sqlite field) in lieu of properly revising the mbtiles spec, and some of it (minzoom/maxzoom levels) is duplicating data contained elsewhere in the .mbtiles file. But we are where we are, and the question is how tilemaker should handle it.

At present the approach is to allow users to manually write the json field out in a metadata hash in their tilemaker .json config, which will then be passed through into the tileset.

In theory (as suggested by @sfkeller in #77) we could probably autogenerate the Mapbox json field, given that we know most of the content. Any such function should be optional as no other client needs this data. So I guess the questions are:

• Is the current functionality good enough?
• Are there people who would genuinely find an autogenerated vector_layers field useful?
• Will it be obsoleted by any revised mbtiles spec?
• What interface do we implement in tilemaker, and how do we do it efficiently? (In particular, the MVT format does not impose consistent typing on attributes, and tilemaker follows suit; whereas the vector_layers field requires consistent typing for any field across a tileset.)

cc @pnorman

[sfkeller]

Just my 2 cents as background from a MVT readers point-of-view:

This vector_layers info in fact is something similar to a "Capabilities" document and/or aka schema description. IMHO this mbtiles related spec. issue is related to TileJSON spec. AFAIK TileJSON spec. was first, and that's maybe the reason why it's JSON in mbtiles too.

In both cases (mbtiles file, TileJSON service) the layer and fields info MUST be known by an MVT reader before he reads tiles (in my case, he has e.g. to create layers and fields before hand).

It's IMHO open to the discussion, if such a vector_layers info acts as a view, which means that the receiver has to read only those layers/fields that are mentioned in the vector_layers (even if the data contains more).

Proposal: In case there is a configuration entry, it's behaving like now. In case this configuration entry is empty, the vector_layers field is autogenerated from tilemaker input (for convenience).

[pnorman]

I will admit to not being too fond of this

👍

[sfkeller]

I'm not against a better solution than a JSON value in the metadata table.
To me it's enough ...

• that we agree on the need for such an information since it's mandatory for many readers (except purely visualization oriented JS ones).
• And that the mbtiles spec. (and the TileJSON spec. as well) get aligned and updated.

[systemed]

Now supported.