CesiumGS/3d-tiles

Implicit tiling doesn't support transforming subtiles/content from local coordinate systems

elfprince13 opened this issue · 3 comments

Currently there is no equivalent to specifying transform on a tileset when using implicit tiling. The discussion in #587 and #633 hint at some ingredients that could allow this.

Unfortunately #633 appears to be limited to support of "well known" CRSes, which aren't sufficient for tile-local model coordinate systems:

`TILESET_CRS_GEOCENTRIC`|<ul><li>Type: `STRING`</li></ul>|The geocentric coordinate reference system (CRS) of the tileset. Known values include, but are not limited to:<ul><li>`"EPSG:4978"` - WGS 84</li><li>`"EPSG:7656"` - WGS 84 (G730)</li><li>`"EPSG:7658"` - WGS 84 (G873)</li><li>`"EPSG:7660"` - WGS 84 (G1150)</li><li>`"EPSG:7662"` - WGS 84 (G1674)</li><li>`"EPSG:7664"` - WGS 84 (G1762)</li><li>`"EPSG:9753"` - WGS 84 (G2139)</li></ul>`region` bounding volumes are assumed to use the same reference ellipsoid as the geocentric coordinate reference system specified here.<br><br>For more details on coordinate reference systems in 3D Tiles, see [Coordinate Reference System (CRS)](../../#coordinate-reference-system-crs).

Moreover, this semantic still cannot be reliably used with implicit tiling unless the 3DTILES_metadata extension is listed under extensionsRequired, which conflicts with the instructions in the current documentation:

## Optional vs. Required
This extension is optional, meaning it should be placed in the tileset JSON `extensionsUsed` list, but not in the `extensionsRequired` list.

It seems as though what is required here is just a metadata semantic corresponding to the existing transform property in explicitly subdivided tilesets, and which when used renders the 3DTILES_metadata extension mandatory.

It seems as though what is required here is just a metadata semantic corresponding to the existing transform property in explicitly subdivided tilesets

I believe this already exists: TILE_TRANSFORM (scroll to the bottom of the list).

I would also recommend looking at the draft-1.1 branch which is where the 3D Tiles 1.1 spec lives. Most of the 3D Tiles Next extensions have been promoted to core.

Aha, my bad - not sure how I missed that - I definitely searched for transform in a few places.

And it still seems like using TILE_TRANSFORM with 3DTILES_metadata requires pushing 3DTILES_metadata into extensionsRequired, as otherwise some clients might display in the wrong location? Is this a correct interpretation of the spec?

Yeah, I think you're right about extensionsRequired. Though not really a concern with 3D Tiles 1.1 since the extension was promoted to core.

Also I should point out that CesiumJS doesn't actually support the TILE_TRANSFORM semantic but it should be easy to add.