Improper leading slash for non-b3dm tile

[lilleyse]

I ran into a tileset that has a tile url with a leading slash that is not caught correctly by detectBrokenUrlWorkaround. The problem is the first tile that is encountered is a b3dm tile with a correct url while the tile with the broken url is deeper down the tree. It looks something like:

{
    "content" : {
        "url" : "tile.b3dm"
    },
    "children" : [
        {
            "content" : {
                "url" : "/external.json"
            }
        }
    ]
}

I wonder if we should always apply the workaround instead of trying to detect it... unless that causes a problem in some other way.

@tfili do you have any ideas?

CC https://github.com/AnalyticalGraphicsInc/cesium/pull/6125

[mramato]

I think we should tell tiler authors to fix their broken tilesets and remove the workaround completely. The workaround was always supposed to temporary anyway. Long term, the validator should be able to catch this error.

[tfili]

I'm with @mramato on this one. Putting in hacks to fix bad tilesets would then make viewers that follow the spec inconsistent. It's the same issue that exists with KML. There is the spec and then there is what Google Earth supports. GE enabled bad behavior, so now implementing a good KML is near impossible. There is no docs on the hacks, so its just a big game of whack-a-mole.

[lilleyse]

I agree with you guys, I'm just noting a bug in our current workaround.

[tfili]

The current workaround was only for a very specific set of b3dm paths. It was intentionally made extremely narrow.

[lilleyse]

Alright sounds good. Yeah tooling (like validator or upgrade scripts) is the better way for handling this problem. I'll close for now.

Moved to https://github.com/AnalyticalGraphicsInc/3d-tiles-tools/issues/141.