Question: Are subtile urls supposed to implicitly use the parent tileset query parameters? about 3d-tiles HOT 7 CLOSED

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.

from 3d-tiles.

@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.

from 3d-tiles.

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.

from 3d-tiles.

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!

from 3d-tiles.

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.

from 3d-tiles.

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.

from 3d-tiles.

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?

from 3d-tiles.