Extension for automatic ENU registration

[Marco13]

The underlying topic is very broad, and we are aware of some of the questions that users have. Some of these questions come up pretty frequently, and apply to differerent use-cases and steps in the toolchains.

For the client-side, the goal is often to ~“just place some content at a specific location”, or (slightly more specific) to ~“modify the position of a tileset”. (Some links in a recent thread). But similar questions apply to earlier steps: People have some “raw/input” data (point clouds, CAD data, GeoJSON, GeoTIFF…). That data may or may not define a CRS in one form or another. And they want to convert this data to use a different CRS (or no CRS at all…). (There are many threads about this - not listing them here explicitly…)

@andreasplesch

Some users expect that this manual placement would occur automatically, either by consideration of the boundingVolume coordinates (region in latlong radians, box in ECEF meters) since that property appears to be the only one with a potential geospatial significance (other than rarely used metadata semantics). Or with a dedicated CRS property giving the projection. But this is not the case. Instead it is necessary to compute an appropriate transform matrix and add it to the tileset.json which is rather inconvenient or hard without tools.

The idea of using some extension may be viable. But there are several things that may warrant further discussion.

On the one hand, I see the relevance of the bounding box. The computation of the bounding box that is required in the tileset JSON can be challenging. (It’s not really “difficult” - the main point is that there is no sufficient tooling support). On the other hand, I don’t see why this information should be “associated” with the bounding volume in any way.

Maybe I misunderstood that point. But imagine that you have “some 3D model” (like or a single glTF file). And this should be placed at a certain position on the globe. I think that instead of using a bounding volume, you could just define the cartographic position of where the coordinate system origin (0,0,0) of that object should be. Brainstorming: On the level of the tileset JSON, this could roughly be something like

      "3DTILES_geolocation_DRAFT": {
        "longitudeDeg": -80,
        "latitudeDeg": 40,
        "height": 10
      }

that could replace the tile.transform (meaning that the transform matrix would just be computed from that information, using functions like the Transforms.eastNorthUpToFixedFrame in CesiumJS).

But… the potential benefit of that, compared to an actual transform, would be relatively low: The transform can trivially be computed from that information. So this may rather be a matter of tooling (more on that below).

@andreasplesch

RTC_CENTER can be substituted by a additional translation transform at the glTF level, or the tile level.

But this is not the transform which would be needed for a ENU to ECEF transform since such involves also rotation to the ellipsoid/geoid tangential plane at the reference point, in addition to the translation.

The RTC_CENTER was originally designed in order to avoid a very low-level, technical issue, which is described in Precisions, Precisions | DME Component Libraries for .NET 2025 r1 . And this is indeed not sufficient for “arbitrary placement”. (I think it’s good that this can become obsolete with glTF. Let’s pretend CESIUM_RTC just didn’t exist ) Using the glTF node matrix is much more versatile.

But still, the question of “where exactly should the geo-placement happen?” is not totally trivial to answer.

I did write a few thoughts and fragments of information, about the options and their pros/cons. For example, in 3DTileset rotation - #2 by Marco13 or From I3dm to EXT_mesh_gpu_instancing? - #11 by Marco13 . And the task to somehow “consolidate” that information and present it in a more approachable form is on my TODO list (albeit with relatively low priority…).

@andreasplesch

The probably common use case would be:
Content authors have glTF tiles (of say pipelines in city) with ENU, local coordinates. They want to geospatially register the tiles, and then use 3d tiles. They do not want to manually (and perhaps incorrectly) compute ECEF coordinates. They do not care about the curvature of the earth (since it is small model). The extension would enable construction of simple tileset json files which then can be used along side other geospatial content (with cesium or other viewers).

This comes back to the point of “tooling” above:

The use-case that you described is pretty common. And I’ve needed that functionality quite often: Given a glTF file, I wanted a tileset.json that just refers to that glTF (and maybe places it at some position on the globe). Therefore, the 3d-tiles-tools offers the createTilesetJson command, which does exactly that.

There are many functionalities that could be offered, and that fall into a similar category. For example, Extend tileset creation function to assign multiple positions · Issue #130 · CesiumGS/3d-tiles-tools · GitHub , or Consider a command to re-compute bounding volumes · Issue #106 · CesiumGS/3d-tiles-tools · GitHub , and maybe Consider convenience functions to create instanced models · Issue #84 · CesiumGS/3d-tiles-tools · GitHub .

Another one would be a function to “reset” the location/rotation of a whole tileset. This would mean to “pull out” the RTC_CENTER of all B3DMs, and maybe reset their orientation , with the goal to eventually create a tileset that is located at the origin, is oriented Z-up in ECEF, and that can then be placed on arbitrary points of the globe, by setting the modelMatrix, at runtime. Things like that would involve some guesses and heuristics, but could be useful in order to make the “placement of the tileset on the globe” easier for clients.

However, before tackling something like that, there should be a clear(er) idea about the goals, scope, and granularities of these functionalities.