Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tileset.json should specify tileset version or id #50

Closed
mramato opened this issue Dec 11, 2015 · 2 comments
Closed

tileset.json should specify tileset version or id #50

mramato opened this issue Dec 11, 2015 · 2 comments

Comments

@mramato
Copy link

mramato commented Dec 11, 2015

Since most 3D Tiles tilesets are generated once and then served as static files, it's good practice to provide an aggressive caching policy in order to avoid unnecessary server hits. This is similar to how we serve Cesium's world terrain, for which we set a cache policy of one year. The problem with this approach is that if I want to update an existing tileset, browsers that already have older versions of the tiles won't request new ones (for a year at least).

This is a common problem in the industry and is solved via query parameters. We can add a property to the root tiles.json file whose value gets appended as a query string to every tile request. tiles.json would then be served with a less aggressive caching policy (1 hour) and the browsers would automatically detect when it changes causing new copies of the previously cached tiles to be fetched as needed.

As an example, in STK Terrain Server's layer.json, there is a version property that indicates the version of the tileset (not the version of the spec). Requests are then made by Cesium with the ?version=<value> query parameter as I described above. We could use a version property in tileset.json as well, since it has semantics that allow developers to tell what version of a dataset a client is using, or we could simply add an id property that require it to be a GUID string so that it's always unique uniquely identify the tileset.

I'm not partial to either approach, as long as the spec enforces one of them. (or optionally determine a complete different way to solve the caching problem).

@mramato
Copy link
Author

mramato commented Dec 15, 2015

To clarify, from a specification perspective I think the only thing we need to do is have a way to uniquely identify a specific version of a specific tileset. The actual implementation can decide how to apply that information to fit each use cases caching needs.

@pjcozzi
Copy link
Contributor

pjcozzi commented Dec 18, 2015

Adding a top-level asset object property like glTF would solve this, correct?

{
    "asset" : {
        "version" : "0.0",  // 3D Tiles spec version
        "tilesetVersion" : "whatever-an-app-wants"  // Application-specific tileset version
    }
}

I'll update the spec and schema if you agree.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants