Consider making a top-level tileset.json the required entry point

[mramato]

Currently, any JSON file anywhere in the hierarchy can be the entry point of a tileset, there is also no requirement for it to be named tileset.json. This makes it impossible to write a generic loader because it requires whomever created the tileset to identify which JSON file to use.

Requiring a tileset.json at the top level of the hierarchy to always be the entry point fixes this problem and shouldn't negatively impact any use cases I can think of. In fact, the way the spec is worded, I always thought this was already the case (because we use the term top-level in a few places.

This is somewhat related to #89, since you want to be able to read a .3dtiles database without any external knowledge, but I thought it warranted it's own issue since it has come up a few times in my attempt to read tilesets generated by someone other than myself.

[pierotofy]

I always thought tileset.json was required to be the entry point as well.

[lilleyse]

Requiring tileset.json at the top level seems too strict to me. Many toolchains will want to store a version number or other information in the file name. This would also make it difficult to debug external tilesets on their own, since the name would need to be changed to tileset.json in order to load.

For #89 could this be solved from a tooling perspective? In tilesetToDatabse either a json file or folder name could be supplied (like in Cesium). The .3dtiles format would just need to mark what the root is.

If even the root json isn't know, it should be possible to determine the root by reading each json and looking at its external tilesets. This wouldn't work with cyclical dependencies or multiple roots, but those situations don't seem likely.

[mramato]

Requiring tileset.json at the top level seems too strict to me.

I vehemently disagree. Without a well-defined entry point it's impossible to read an arbitrary tileset without external knowledge not included in the tileset itself. That's a design flaw.

Many toolchains will want to store a version number or other information in the file name.

I don't understand the use case for this. Why you would store the version in the filename when the version is in the file itself? There could easily be a mismatch.

This would also make it difficult to debug external tilesets on their own, since the name would need to be changed to tileset.json in order to load.

There's nothing stopping a client from reading an arbitrary json file as the root for debugging purposes, so I don't think this point is valid. Another option would be to enforce external tileset to have a tileset.json root as well; but I don't think that's necessary.

For #89 could this be solved from a tooling perspective? In tilesetToDatabse either a json file or folder name could be supplied (like in Cesium). The .3dtiles format would just need to mark what the root is.

We could certainly push it to the .3dtiles level and require the root to be marked there, but that seems like a sub-par solution since it means that non-DB based tileset would still be impossible to read generically. Also, the .3dtiles file is not in any way part of the spec yet, so we're not really solving the core problem.

If even the root json isn't know, it should be possible to determine the root by reading each json and looking at its external tilesets. This wouldn't work with cyclical dependencies or multiple roots, but those situations don't seem likely.

This sounds performance prohibitive to me, not to mention "don't seem likely" is a world away from "can't happen". Also, making clients read through an entire directory of files in a tileset in order to try and figure out the root is an undue burden, especially considering your first use case was avoiding having to read tileset.json to get the version number.

Obviously I have strong opinions here, but having a well defined entry point is critical for being able to generically ready 3D Tiles tilesets.

[lilleyse]

My experience so far has been that tileset authors tend not to name the root file tileset.json even though that is the convention throughout the spec and examples. The version in the filename is just an example of what I've noticed, not a recommendation.

If the technical issues pile up too much, I'm ok with strictly naming it tileset.json. Supporting loading arbitrary json files in the client while being strict from the spec side seems like a pretty good compromise. I'm curious what others think.

[mramato]

I just uncovered another problem related to this. I have a web service that serves a tileset, let's assume the url to the root is foo.com/bar. When I try to load this into Cesium, it forces the url to be foo.com/bar/tileset.json. So in Cesium, it's already impossible to load urls that do not end in .json with anything other than tileset.json.

Either Cesium has a bug and needs to be updated to never append tileset.json or the spec needs to be updated to make tileset.json the entry point.

[lilleyse]

Yeah, in Cesium it will tack on tileset.json if you pass in a directory. You can still pass in arbitrary .json files though.

[mramato]

Yeah, in Cesium it will tack on tileset.json if you pass in a directory. You can still pass in arbitrary .json files though.

That's kinda my point. There is no "directory" concept for urls. A url that doesn't end in .json may actually return you the tileset.json content and Cesium's globbing of tileset.json breaks it and makes it impossible to load these types of urls in Cesium. Cesium's implementations forces your url to end in .json or be tileset.json, which is very un-web-like.

[lilleyse]

I'm wondering how these rules might apply for requesting tile contents, since they are relative to the tileset.json.

In the case of a url like localhost:8080/assets/355, this could either imply that a tileset.json exists within the 355 "directory", or that 355 IS the tileset.json. Depending on which convention is chosen, the url for tile.b3dm could be either of these two:

• localhost:8080/assets/355/tile.b3dm
• localhost:8080/assets/tile.b3dm

I'm thinking the first is probably the more common convention.

[lilleyse]

Actually I suppose case 2 wouldn't be allowed since the entry point has to be tileset.json, and referencing a file of a different name wouldn't make sense.

[pjcozzi]

@lilleyse are you still concerned with explicitly requiring tileset.json?

[lilleyse]

No, I think it will be fine. Tileset writers will just need to become aware of this condition over time.

[pjcozzi]

Sounds good.

[elfprince13]

Count me as a strong vote against requiring tileset.json to be the file name. Being able to serve dynamic content then requires weird tricks with Apache and mod_rewrite, excluding a large class of users who don't necessarily have permissions to fiddle with their server configs.
If you're concerned with checking if a URL is a directory or a file, you should really just look for a trailing slash (or deprecate that behavior entirely).

I'm not sure what @mramato means by a "generic loader", but the root of a tree is whatever the end user says it is. It doesn't matter if there are "parent tiles" somewhere in the ether if the user didn't want to load them.

[pjcozzi]

@lilleyse is this something we should do for 1.0? I do not want to make the requirement in haste.

[elfprince13]

I think @KermMartian and I would like to reiterate our opposition to the behavior requested in the initial comment for this issue.

[mramato]

Despite being the person who created this issue, I'm okay with not requiring a top-level tileset.json given that we update Cesium's implementation (and toolchain) to always require a full path to the entry point. Cesium currently adds "tileset.json" to urls that do not end in json, making it impossible to load many urls.

We will also need to enforce something at the .3dtiles sqlite level so that the entry-point to the tileset is known, but this can be done post 1.0. Tools like tilesetTodb would also require we take the entrypoint file path instead of the directory path.

[elfprince13]

I'm definitely in favor of always requiring a full path to the entry point.

[ggetz]

Resolved in #301