Tile expiration

[pjcozzi]

To support some types of dynamic tilesets that may change on the server, consider adding a per-time expiration time stamp (explicit date/time) or duration (in seconds), which indicate when a tile and its sub-tree become invalid and should be re-requested.

[pjcozzi]

@lilleyse what do you think about this new per-tile expire object property?

Use expire.date:

{
  "expire": {
    "date" : "2012-04-30T12:02Z" // Julian date like CZML, https://github.com/AnalyticalGraphicsInc/czml-writer/wiki/CZML-Structure
  },
  "boundingVolume": {
    // ...
  },
  "geometricError": 43.88464075650763,
  "refine" : "add",
  "content": {
    "boundingVolume": {
      // ...
    },
    "url": "2/0/0.b3dm"
  },
  "children": [...]
}

Or use expire.duration:

{
  "expire": {
    "duration" : 30 // seconds  from when the tile is downloaded (not requested, not first rendered, not generated, etc.)
  },
  "boundingVolume": {
    // ...
  },
  "geometricError": 43.88464075650763,
  "refine" : "add",
  "content": {
    "boundingVolume": {
      // ...
    },
    "url": "2/0/0.b3dm"
  },
  "children": [...]
}

expire can have either a date sub-property or a duration sub-property (if both are provided, the soonest one is used). The runtime can convert it to an expiration date, and then request a new tile (and eventually sub-tree) when it expires. The runtime can still show the expired tile while it waits for the new tile request. If the request doesn't come back, e.g., because that tile is no longer part of the tileset, then the expired tile should be unloaded (and, of course, unloaded when the request is successful).

For future work for the Cesium implementation, we could also proactively unload expired tiles in our cache that are not visible, but I'll make this a roadmap item.

From the server's perspective, date allows the use case for a static file server to serve a tileset with a know expiration date; where as duration allows a dynamic server to generate a tile that is valid for a particular amount of time.

[lilleyse]

Just so I'm clear, does expire mean refreshing the whole subtree, or just the content of a single tile? Is this a property worth adding to the expire block?

[pjcozzi]

I would expire the tile and its sub-tree. I don't have a use case for expiring just the tile, but it can be added in a backwards-compatible way if good use cases arise.

[pjcozzi]

For the spec:

• Just the content.url is requested again (it may, of course, point to an external tileset). The newly downloaded tile/tileset may still have spatial coherence with its parent.

[pjcozzi]

For the spec:

• Time expiration should be in the tile (header / feature json) so it can change from request to request.

[pjcozzi]

Cesium implementation: CesiumGS/cesium#4136

[pjcozzi]

For the spec:

• When is client required to stop rendering old content, 3D Tiles - Support tile expiration cesium#4136 (comment)

[pjcozzi]

Video: https://youtu.be/JlPLRtFzn5g

[pjcozzi]

@lilleyse is it reasonable for you to do this spec work? Is the implementation solid enough? Would this be pretty quick? I have lots of notes for the spec throughout this issue.

[lilleyse]

The implementation isn't super solid, I want to rethink the approach. I can write the spec for this.

[pjcozzi]

Let's hold for now, and updated the spec and implementation at the same time.

[pjcozzi]

Pull request: #217

Nonetheless, let's push post 1.0 for scope.

[lilleyse]

Tile expiration be could stored in metadata as a semantic, and the application can re-request content at runtime.

Unlikely to make it into the core spec.