Question: Are subtile urls supposed to implicitly use the parent tileset query parameters?

[gkjohnson]

Hello! I'm looking at Google's 3d tiles and I'm trying to understand the "sessionid" behavior that seems to be something implicit and unstated in the 3d tiles spec. It seems that when using googles tiles you load the root tile and then all subesquent tiles require a session id query parameter which is only specified in the first child tileset of the original tileset root.

Is it the case that all child requests are supposed to implicitly inherit this session id query parameter? Otherwise the loading the data doesn't work. I don't see anything in the google tiles documentation about how to otherwise get a session id or in the 3d tiles spec about this kind query parameter inheritance.

Thank you!

[lilleyse]

@gkjohnson Thanks for bringing this up. There does seem to be a disconnect between the spec and some of the runtimes.

3D Tiles has a normative reference to RFC3986. According to Section 5.2: Relative Resolution query parameters in the base uri are not inherited in the resolved uri. /~https://github.com/uriparser/uriparser for example follows that behavior.

Meanwhile...

• Cesium Native uses the function Uri::resolve and explicitly sets useBaseQuery to true here
• CesiumJS uses the function Resource.prototype.getDerivedResource here and while preserveQueryParameters flag defaults to false it doesn't seem to be working as intended.

[gkjohnson]

Great thanks for the info. So to clarify - is it the case that this necessary behavior should be documented in the spec? Or has the Google Photorealistic Tiles API been designed too heavily with Cesium-specific implementation quirks in mind? Should Google change it's tile sets instead, for example, and provide a "createSession" endpoint the way some of their other APIs do?

Currently to load Googles tiles in our 3d tiles loader we have to traverse the roots children until we find a session id in a query parameter which we save and use for all subsequent requests. It would be nice to know what the correct behavior is per the spec before refactoring things to support something like inherited queries.

[gkjohnson]

Sorry to ping again @lilleyse - is there any update here? I'd like to figure out how to handle this correctly while I'm already in working on the codebase for the tiles project. Thanks!

[lilleyse]

Sorry for the delay, there's a few tradeoffs to weigh here.

My current thinking is that 3D Tiles should continue to follow RFC3986 and derived requests should not inherit query parameters. That includes tiles and external resources from glTF. CesiumJS and Cesium Native would need to be fixed and the Google tiles would need to take a different approach. In the meantime, I think you're doing now is ok - special handling for sessionid but not refactoring to support inherited queries. That said, that recommendation could change based on other discussion that happens here.

[gkjohnson]

Great thanks that's along the lines of what I was looking for. I'll be interested to hear if there wind up being any updates on this but I'll keep everything as-is for now.

[gkjohnson]

I see here that it's now documented in the Google Tiles documentation to explicitly include the session and key:

You should attach any parameters that appear in the tileset URI, together with your API key, when you construct the subsequent tile requests. The 3D Tiles API provides the following two parameters:

session
...
key
...

Is it correct to assume that this requirement will remain for Google Tiles only and it should be considered bespoke for this specific tile set?

[lilleyse]

Is it correct to assume that this requirement will remain for Google Tiles only and it should be considered bespoke for this specific tile set?

@gkjohnson yes - that sounds reasonable.