@mdc9001 Some additional context is in the linked thread, e.g. at Cesium point tile rendering with deckgl - #6 by mghildiy , including the asset ID and what I assume to be the result that was generated and downloaded from ion.
I uploaded that data (as 3D Tiles) on my account and had a look, using “Adjust tileset location”: The data seems to be floating waaay above the ellipsoid, and also does not seem to be rotated properly (even if it was at the ground at this point). Also, the center (i.e. the coordinate axes that are displayed in the location editor) seem to be far away from the actual data.
Some observations:
- The tileset does not have a root transform
- It contains oriented bounding boxes
- The center of the root bounding box is somewhere at (longitude, latitude, height) = (70, 0.1, 400000) or so (I’d have to check the exact numbers - in any case, it was something that doesn’t make sense…)
- The tileset refers to PNTS files
For me this suggests that a certain geographical position is encoded in the actual POSITION attribute of the PNTS files. And while it’s theoretically possible to define a root.transform that basically “cancels out” these wrong positions, it feels like a quirky workaround. As you said: Preferably, the data inside the PNTS should be relative to a local origin.
But I’m not sure whether there is an easy way to achieve that. Maybe there is some sort of LAS tool that allows assigning a certain CRS that can be picked up by ion, or even “preprocessing” the LAS so that it is at the local origin…? (I could probably hand-craft a tool for that, based on some local LAS library that I’ve been pondering with, but maybe there is a canonical approach for that…)