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
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).
The text was updated successfully, but these errors were encountered:
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.
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 aversion
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 anid
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).
The text was updated successfully, but these errors were encountered: