attribution, name, tilejson, version, description #37
Conversation
| "name": "Earthsea v2" | ||
| } | ||
| ``` | ||
|
|
||
| ## 3.11 `scheme` | ||
| ## 3.12 `template` | ||
| ## 3.13 `tilejson` |
There was a problem hiding this comment.
@GretaCB in the previous version we mention the tilejson value being semver, but our new 3.0 spec only defines major.minor and no patch. Should we rephrase this?
There was a problem hiding this comment.
@mapsam Good eye. I'm thinking we should change this and make it super specific when to bump minor and when to bump major. For example, fixing insignificant typos/spelling errors wouldnt need any kind of version bump. But if a change affects implementation in anyway (like the spelling of a tilejson property), that would require a major bump.
There was a problem hiding this comment.
Nice - I agree. We also mention when major.minor in the CONTRIBUTING.md which we wrote recently, which appears to nicely match your example.
| "tilejson": "3.0" | ||
| } | ||
| ``` | ||
|
|
||
| ## 3.14 `tiles` | ||
| ## 3.15 `vector_layers` | ||
| ## 3.16 `version` |
There was a problem hiding this comment.
A few notes/questions for the version field:
- added a link to semver.org
- updated the first sentence to include "... representing the vector tiles themselves." to be more explicit. Thoughts?
- Added example text (in bold) to the following sentence: "When changes across tiles are introduced, such as polygon or linestring geometry updates, the minor version MUST change."
- Question: The final sentence discussing major versions is confusing to me... "Implementations MUST NOT use tiles with different major versions." what does this actually mean? Can we provide an example to make it more clear?
There was a problem hiding this comment.
"Implementations MUST NOT use tiles with different major versions." what does this actually mean? Can we provide an example to make it more clear?
Same. Perhaps it's saying, any implementation must ensure its tilejson major version is consistent. If updating tilejson major version, it must apply to all uses of tilejson throughout the system.
...?
There was a problem hiding this comment.
updated the first sentence to include "... representing the vector tiles themselves." to be more explicit. Thoughts?
From what I understand, the version field here is referring to the tilejson version, not the vector-tile version.
There was a problem hiding this comment.
Oh pardon, the tilejson field is referring to the tilejson version.
The version field is referring to the vector-tile version. Therefore, your addition sounds great. I think also adding something like:
A semver.org style version number of the tiles
Also, can we assume it's always vector-tiles?
There was a problem hiding this comment.
Also, can we assume it's always vector-tiles?
Good point, I don't think we can. In fact now that I re-read my added example text "such as polygon or linestring geometry updates" I'm wondering if this isn't actually true, and is more related to breaking changes of the underlying data. At least for vector tiles, this would be something like "changing the name of layerA to layer1" which would break downstream tools referencing the data. I'm not exactly sure how you'd version raster data though.
There was a problem hiding this comment.
Updated the "major" example to layer name changes, and just say "tiles" instead of "vector tiles" since these could be raster tiles.
| @@ -39,28 +39,76 @@ Implementations MUST treat unknown keys as if they weren't present. However, imp | |||
|
|
|||
| ## 3.1 `attribution` | |||
|
|
|||
| REQUIRED|OPTIONAL (description of dependents/dependencies) | |||
| OPTIONAL. Default: null. | |||
There was a problem hiding this comment.
“Default” is … If you are consuming TileJSON and this field does not exist, you should assume the value is
X”
@mapsam what are your thoughts on making this explicit somewhere? Perhaps part of Structure?
There was a problem hiding this comment.
👍 Just added
Implementations MUST treat invalid values for keys as if they weren’t present. If the the field is an optional field and the value is invalid, the default value MAY be applied.
MAY could be a SHOULD or a MUST
There was a problem hiding this comment.
Since these fields are Optional, going to stick with MAY
MAY This word, or the adjective "OPTIONAL", mean that an item is
truly optional. ...
There was a problem hiding this comment.
Awesome - thanks @GretaCB 👍
|
Per discussion with @GretaCB - merging this into 3.0 base so we can sync up some other branches! |
Starting to add some default language from the previous specification for
attribution,name,tilejson,version, anddescription. Planning to leave questions inline for discussions!cc @GretaCB