You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're starting to see a lot of tilejson with a vector_layers key. We should document this for standardization and so that the meaning the keys are documented.
I recently got stung by this when trying to use tessera which uses tilelive to serve up a tmstyle. If you have no vector_layers key in the TileJSON, then the resultant image is blank.
ping on this. I could also do a PR if there's agreement and understanding on what the schema is (though if @anandthakker already has something written, I'd prefer that)
I'm currently implementing the TileJSON spec for an MVT server and would also like to see an agreed upon spec for the vector_layers key. I came up with the following proposal based on what is required by the MVT Layer Specification and some additional fields I see beneficial for displaying layers. A few things to note:
id and name are redundant. The MVT spec requires a layer have a name value, but as @gmaclennan pointed out, the id value is already being used by mapbox-gl. Ideally the spec would only use name as that's required for MVT Layers.
The fields key as proposed has been renamed to feature_tags. The MVT spec uses tags for feature metadata, and since the values are for "features" not the layer, I think the "feature_" prefix is more explicit.
Here's the spec I'm proposing:
{
// REQUIRED. The MVT encoding version.
"version": 2,
// REQUIRED. The extent of the vector layer.
"extent": 4096,
// REQUIRED. The name of the layer
// "name" and "id" are identical since mapbox has already implemented the id in mapbox-gl
"id": "buildings",
// REQUIRED. The name of the layer.
// "name" and "id" are identical since mapbox has already implemented the id in mapbox-gl
"name": "buildings",
// OPTIONAL. Default: []
// an array of feature tags that MAY be included on each feature
"feature_tags": ["class", "name_en", "etc"]
// OPTIONAL. Default: null
// possible values include: "point", "line", "polygon", "unknown"
"geometry_type": "polygon"
// OPTIONAL. Default: 0. >= 0, <= 22.
// An integer specifying the minimum zoom level.
"minzoom": 0,
// OPTIONAL. Default: 22. >= 0, <= 22.
// An integer specifying the maximum zoom level. MUST be >= minzoom.
"maxzoom": 11
}
version and extent are specific to MVT, not vector tiles. If we were to specify format it should go a level higher in the json
This brings up an interesting point. The spec needs to be polymorphic to support the various vector formats. I have drafted a new proposal at the end of the comment with this in mind.
I assume the json object you are describing is put in an array for the vector_layers property? This needs to be explicit
Correct. I was assuming context as the issue is about the vector_layers property, but it should be explicit.
👎 to having a duplicate name and id properties
I agree, which is why I suggested name but as @gmaclennan pointed out mapbox is already using the id field. We could always use id and then for MVT implementations put the name into the id field. It will probably be important to document how various formats should leverage this spec.
null must be a possible geometry_type or leaving it undefined violates the possible values
what's the difference between null geometry_type and unknown?
I was referencing the MVT spec, but let's expand the available values. WKB has 18 geometry types, but I'm not sure what geometry types are supported across all vector formats. Any input on this?
Here's an additional proposal we can pick apart:
"vector_layers":[
{
// REQUIRED. The "id" or "name" of the layer
"id": "buildings",
// REQUIRED. The vector tile type.
"type": "mvt",
// OPTIONAL. Default: null
The details specific to the vector layer "type". The following example is for MVT.
"details": {
// REQUIRED. The MVT encoding version.
"version": 2,
// REQUIRED. The extent of the vector layer.
"extent": 4096,
// OPTIONAL. Default: []
// an array of feature tags that MAY be included on each feature
"feature_tags": ["class", "name_en", "etc"]
},
// OPTIONAL. Default: null
// possible values include: "point", "line", "polygon", "unknown", ... [additional values under review].
"geometry_type": "polygon"
// OPTIONAL. Default: 0. >= 0, <= 22.
// An integer specifying the minimum zoom level.
"minzoom": 0,
// OPTIONAL. Default: 22. >= 0, <= 22.
// An integer specifying the maximum zoom level. MUST be >= minzoom.
"maxzoom": 11
}
]
Activity
anandthakker commentedon Oct 9, 2015
Bumping this. Happy to put in a PR if yall agree/confirm that this should happen.
Assuming yes, my understanding is that the schema for
vector_layers
would look something like:And the
fields
object maps field names to descriptions.amandasaurus commentedon Mar 21, 2016
I recently got stung by this when trying to use tessera which uses tilelive to serve up a tmstyle. If you have no
vector_layers
key in the TileJSON, then the resultant image is blank.It would be helpful if the spec included this.
pnorman commentedon Jul 15, 2016
ping on this. I could also do a PR if there's agreement and understanding on what the schema is (though if @anandthakker already has something written, I'd prefer that)
anandthakker commentedon Jul 15, 2016
@pnorman Nothing written, alas. Still willing to do it, but my queue is somewhat longer today than it was when I last commented here.
gmaclennan commentedon Sep 19, 2016
It seems like the only property that mapbox-gl-js currently uses is the
id
. https://github.com/mapbox/mapbox-gl-js/blob/93c3b030726ff4d22dd9fbd24ce19c27c3f19093/js/style/style.js#L80-L112Reviewing the source it looks like if that field is not present, and does not map to the layerId in the vector tile, then nothing will render.
ARolek commentedon Sep 30, 2016
I'm currently implementing the TileJSON spec for an MVT server and would also like to see an agreed upon spec for the
vector_layers
key. I came up with the following proposal based on what is required by the MVT Layer Specification and some additional fields I see beneficial for displaying layers. A few things to note:id
andname
are redundant. The MVT spec requires a layer have aname
value, but as @gmaclennan pointed out, theid
value is already being used by mapbox-gl. Ideally the spec would only usename
as that's required for MVT Layers.fields
key as proposed has been renamed tofeature_tags
. The MVT spec usestags
for feature metadata, and since the values are for "features" not the layer, I think the "feature_" prefix is more explicit.Here's the spec I'm proposing:
Looking forward to the discussion.
pnorman commentedon Oct 5, 2016
ARolek commentedon Oct 5, 2016
vector_layers
property, but it should be explicit.name
but as @gmaclennan pointed out mapbox is already using theid
field. We could always useid
and then for MVT implementations put thename
into theid
field. It will probably be important to document how various formats should leverage this spec.null
or [ ]. The geometry values I included were from section 4.3.4 - Geometry Types of the MVT Specification. TheUNKNOWN
type is used for experimental types.Here's an additional proposal we can pick apart:
26 remaining items