Implied transform from tile identifiers (e.g. level, x, y)?

[jerstlouis]

With implicit tiling, is it possible to imply a transform based on a tile's identifiers so as to be able to define the geometry of the content in a local coordinate system? This would avoid the need for transforms, while both allowing the proper precision of a local coordinate system, and having the geometry showing upright when e.g. loading it in 3D model editor to inspect it.

For example, in a 2D TileMatrixSet:

• up would point away from the center of the Earth,
• right would be East, and
• forward would be North

(the x-z plane is tangent to the surface of the Earth), and local 0,0,0 is in the center of the tile at the height of the ellipsoid.

This is the approach proposed in the new additional dimension annex of the revision of the 2D TileMatrixSet & TileSet metadata specification, so it would be great if that is compatible.

[lilleyse]

This is an interesting idea.

On top of easier editing and inspection we've found that geometry defined in a local coordinate system has better compression characteristics from an early test with EXT_meshopt_compression.

This feels cleaner than storing the ENU -> global transform in the glTF. The implicit transform could also define the mapping from glTF coordinates to ENU coordinates, and I think the mapping you described makes sense though it is awkward with glTF which is +y up, -x right, +z forward.

Other comments:

• The implicit transform would not be the same as the tile transform, since the implicit transform applies to the content and not the implicit bounding volume or child tiles. Maybe we add a new concept called content transform?
• I think we could take the content transform idea further to help define the coordinate conversion behavior between glTF an 3D Tiles. By default the content transform would be the matrix that converts the glTF coordinate system to 3D Tiles. When implicit transforms are used the matrix would be the glTF -> ENU -> global transform. The main takeaway is that glTF content could stay +y up as opposed to what I suggested in Add a property to specify the CRS of the tileset #504.
• Would the implicit transform only apply to certain bounding volumes types, e.g. region and S2 that are geographic in nature?
• Would this behavior be enforced or would it be an option? 3D Tiles is arguably too flexible about the ways in which data can be positioned and should tileset authors be encouraged to go in this direction of local coordinates + implicit transform?

CC @donmccurdy @IanLilleyT

[jerstlouis]

@lilleyse

On top of easier editing and inspection we've found that geometry defined in a local coordinate system has better compression characteristics from an early test with EXT_meshopt_compression.

For sure, in our E3D format we quantize local 32-bit floating point coordinates into 16-bit signed integer mapping to the mesh bounding box. (See verticesQ / 0x2018)

it is awkward with glTF which is +y up, -x right, +z forward.

About the glTF axis, the exact mapping does not matter so much, we just apply a rotation to the top-level node to re-orient things nicely.

The implicit transform would not be the same as the tile transform, since the implicit transform applies to the content and not the implicit bounding volume or child tiles. Maybe we add a new concept called content transform?

That sounds like re-introducing confusing concepts. With this idea, the transform of the model's local origin is based on the tile coordinates/identifiers, period. The only other "transform" or "bounding volume" concepts coming into play is the regular glTF node transforms and hierarchy, and any bounding volume information you can derive from those. The child tiles at the next level have their own implied transforms based on their own tile identifiers.

Would the implicit transform only apply to certain bounding volumes types, e.g. region and S2 that are geographic in nature?

I think it makes sense for any types of implicit tilesets, as the tileset / tile / content transform really is over-complicating things in this case, in my opinion. glTF already has node hierarchies and transform, so all you need is mapping the glTF's origin to implicit tiling system absolute coordinates -- that should be a simple single mapping based on the tile identifier.

Would this behavior be enforced or would it be an option? 3D Tiles is arguably too flexible about the ways in which data can be positioned and should tileset authors be encouraged to go in this direction of local coordinates + implicit transform?

I think the glTF node transforms + the ability to select a particular tiling scheme already gives all the needed flexibility.

See https://maps.ecere.com/ogcapi/collections/SanDiegoCDB:Buildings/3DTiles/tileset.json for an implementation of this as a 3D Tiles tileset (and the ISG2 engineering report for additional details).

.b3dm, .glb and .e3d should be available at https://maps.ecere.com/ogcapi/collections/SanDiegoCDB:Buildings/tiles/GNOSISGlobalGrid/{tileMatrix}/{tileRow}/{tileCol}.{ext}

(https://maps.ecere.com/ogcapi/collections/SanDiegoCDB:Buildings/tiles/GNOSISGlobalGrid for the OGC API - Tiles end-point)

(NOTE: I will check to make sure our current deployment is still working as it should).

[donmccurdy]

Would this behavior be enforced or would it be an option? 3D Tiles is arguably too flexible about the ways in which data can be positioned and should tileset authors be encouraged to go in this direction of local coordinates + implicit transform?

I think the glTF node transforms + the ability to select a particular tiling scheme already gives all the needed flexibility.

I think we're saying the same thing here, but just to check. glTF vertex data should not be expected to match any particular coordinate system — with quantization it will have some arbitrary scaling factor, with an inverse scaling factor applied somewhere in the glTF node hierarchy. So for compression/quantization, it doesn't ultimately matter whether the glTF file uses a local coordinate system or not.

---

Coming back to #504, it is an interesting point that the glTF content could be defined to be in the coordinate system of the tile rather than the tileset. Either seems reasonable but it would be great if we could choose just one. I do think that too much flexibility is the larger danger here than too little.

[jerstlouis]

with quantization it will have some arbitrary scaling factor, with an inverse scaling factor applied somewhere in the glTF node hierarchy.

Coming back to #504, it is an interesting point that the glTF content could be defined to be in the coordinate system of the tile rather than the tileset.

My proposal (and our implementation) is that a glTF root node coordinate system always has its 0,0,0 at the center of the tile which has an implicit extent from its identifiers, and that its orientation also be relative to the tangent to the Earth surface at that center.

This allows random access to tiles at any resolution without first needing to walk through parent tilesets.
All a client needs to know is which implicit tiling system is in use, and one can directly retrieve the glTF.
No tilesets metadata or separate transform required -- real simple.

The OGC TileMatrixSets, WMTS, OGC API - Tiles all work this way, e.g. you have a PNG for a particular tile and it is only geo-referenced based on the tile identifier where you retrieved it from. Same for Mapbox Vector Tiles. If the format supports some kind of geo-referencing (e.g. GeoTIFF), then that geo-referencing should be consistent with the position.

I believe the exact same approach works just as well in 3D, and makes things a whole lot simpler.