Tighten up spec when content.url is another tileset

[pjcozzi]

Lessons learned from CesiumGS/cesium#3237

A tile with content.url pointing to an external tileset (another tile.json):

• Cannot have any children.
• Is semantically the same as the external tileset's root tile so root.geometricError === tile.geometricError and root.box === tile.content.box (or equals tile.box if tile.content.box is undefined).
• Cannot be used to create cycles, for example, by pointing to the same tiles.json containing the tile or by pointing to another tiles.json that then points back to the tiles.json containing the tile.

@e-andersson any other corner cases we should add to the spec?

[e-andersson]

None that I can think of at the moment. Perhaps it should be noted somewhere that the geometric error of a tile with tiles.json content should be the same as that of its tiles.json root? Or should it be flexible?

[pjcozzi]

Semantically, I think we see the external tiles.json root tile as the same as the parent tile so I agree both tiles should have the same geometric error. I made a note above.

[pjcozzi]

Actually, does this buy us anything in the implementation? We would also want to make the same claim about the box/content.box property. Instead, it might be better to have a <= relationship for the case when a tile has content that is a tiles.json, but also has children. In this case, it is as if the external tiles.json is a peer of the children.

[e-andersson]

A <= relationship might make sense for additive refinement, but maybe not for replacement refinement where all children of a tile must be ready in order to replace that tile. So in the case where a tiles.json tile's root is a peer to the tile's children, the tile, root and children would all have the same geometric error, wouldn't they?
Implementation-wise, it just buys us the convenience of not having to calculate/check SSE for both the tiles.json tile and its root tile separately. As you said, if the external tiles.json root tile and the parent tile were semantically the same, I think it would make sense, but the case of children peers (semantically confusing) complicates things.

Shall we treat all root tiles as <= with regards to geometricError and box / content.box or can we prescribe == for tiles using replacement refinement?

[e-andersson]

I'm growing a bit skeptical of allowing children to a tiles.json tile. It makes the implementation more complex/confusing, and doesn't enable any structure that wouldn't be possible without it (right?).

If we want to support it, there will be some unintuitive relations between the tiles involved that are probably not warrented by any use-cases (the use-cases I thought about earlier, would be just as well supported by a no-children specification, I've realized).

[pjcozzi]

I'm growing a bit skeptical of allowing children to a tiles.json tile. It makes the implementation more complex/confusing, and doesn't enable any structure that wouldn't be possible without it (right?).

OK, let's not allow it. I updated the wording at the top of this issue.

We can always relax it in a later version of the spec if there is a real need, but I agree with your point that it doesn't enable any new structures.

[pjcozzi]

Shall we treat all root tiles as <= with regards to geometricError and box / content.box or can we prescribe == for tiles using replacement refinement?

Given that we are not allowing a tile to point to a tiles.json and have children, let's say that the tile and tiles.json root are semantically the same so their geometricError is the same and root.box must equal tile.content.box (or tile.box if tile.content.box is undefined).

If you agree, I'll update the top comment of this issue. Then I'll close this and update the spec once the implementation in CesiumGS/cesium#3237 is complete in case we run into anything else.

[e-andersson]

Sounds good!

[pjcozzi]

Great, updated above: #42 (comment)