search

mapbox / tilejson-spec

JSON format for describing map tilesets.
255 stars 52 forks source link

vector_layers #42

Closed mapsam closed 6 years ago

mapsam commented 6 years ago

This documents vector_layers as a required key in TileJSON (for sets of vector tiles). Per discussion in #14 this aims to "describe" the layers and their possible attributes while stopping short of describing geometry.

The language is adapted from the vector_layers section in the 1.3 version of the mbtiles-spec, which is the first place to describe this data structure. The key differences between this and the MBTiles specification description is the tilejson specification does not limit the values in key-value pairs of the fields attributes to be Number, String, or Boolean and simply suggests this as a space to describe the key with a string. Per discussion with @GretaCB and @ericfischer, this may warrant an update to the MBTiles specification to be less strict.

Note: we'll be opening a ticket to document possibly renaming id to name in version 4.0, as suggested by @pnorman in https://github.com/mapbox/tilejson-spec/issues/14#issuecomment-251670418

refs: https://github.com/mapbox/tilejson-spec/issues/35

mapsam commented 6 years ago

I opened a ticket in the mbtiles specification repo to suggest relaxing the requirements for String, Number, or Boolean, which we can think about once the tilejson spec 3.0 has been released: https://github.com/mapbox/mbtiles-spec/issues/53

pnorman commented 6 years ago

Note: we'll be opening a ticket to document possibly renaming id to name in version 4.0, as suggested by @pnorman in #14 (comment)

If we want to call it name, let's do it now, rather than require a semver major change to do it.

mapsam commented 6 years ago

Thanks for the comments @pnorman! A couple more responses inline here:

If we want to call it name, let's do it now, rather than require a semver major change to do it.

The goal of 3.x is to solidify the current common practice and reduce the need for architectural changes for implementations and developers. It’s not perfect, but it is what it is. 4.x can introduce downstream architectural changes and will be a more appropriate space for this.

The language identifying the required items should mirror that of the rest of the spec. I think this will be easier to do with subsections since the structure will then be the same too.

Great idea - definitely agree. I'll rework this section to have appropriate subsections.

mapsam commented 6 years ago

Subsections have been added and a note about how v4 can rename id to name.

@GretaCB ready for another review here!

GretaCB commented 6 years ago

Merging 👍