Extension for automatic ENU registration

[andreasplesch]

Thank you much for the comprehensive response which addresses indeed the general issue I tried to raise. There is definitely more to discuss and think about but I do think the concept of shifting the geospatial placement of glTF content (since now preferred) into an extension (and into the client implementation of such) could be quite valuable.

@Marco13

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.

Agreed. The boundingVolume (center) is just the main (and probably only) place where a geolocation center could live outside of a metadata semantic or extension property. It is cleaner and more versatile as you suggest to instead have such extension properties. For example, there are probably many cases where the center of the bounding volume does not naturally correspond to the origin of the ENU, local CRS.

@Marco13

Therefore, the 3d-tiles-tools offers the createTilesetJson command, which does exactly that.

Yes, that is the equivalent tool which I was not aware of. This is cool and really helpful. There are some additional benefits of making this functionality declarative, in an extension:

• users do not have to know or use the tool or think too much about how this is done since it is now internal to the viewer implementation.
• implementations can approach this in the way they prefer, for example if there is already similar functionality outside of 3d tiles support.

I think focusing a potential extension on just one, limited, well defined target function is possible and would be the most effective. It should be small.

@Marco13

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

This issue does apply but I did not understand why merging after creating Tilesetjsons for single glTFs is not a good option.

It may be insightful to use

Placing multiple models using geographic coordinates

Hello, I’m not quite sure if this is thread should be in the 3D Tiles or CesiumJS category, please move it if you think CesiumJS is more fitting. In our project we currently have a hard time to place multiple glTF models with geographic coordinates. Everything is fine when we have tileset with only one model, since we then use a transform which represents both the tileset’s and the buildings center. But we can not figure out the right way to place a model relative to a tileset’s center, which…

as an example to study if in this case such an extension would be helpful. Just an idea.

My background is that we are considering implementing (partial) 3d tiles support for X3D which has geospatial capabilities including GeoLocation (very similar) and glTF loading.