Valid Quantized Mesh Header?

[malaretv]

I'm new to this stuff so apologies if this is user error or misunderstanding...

The coordinate values in the quantized mesh header seem off. The quantized-mesh spec says coordinate values should be in earth-centered fixed coordinates. Given that, I'd expect the magnitude of the center point to be a value close to the radius of the earth, but that doesn't seem to be the case.

As an example I ran dem2tintiles on the craterlake dem dataset.

The resulting header for tile 6/10/40.terrain looks like:

{
  "centerX": -13462700.917811524,
  "centerY": 5322463.153553393,
  "centerZ": 1331.456658194813,
  "minHeight": 1130.3309326171875,
  "maxHeight": 1532.5823974609375,
  "boundingSphereCenterX": -13462700.917811524,
  "boundingSphereCenterY": 5322463.153553393,
  "boundingSphereCenterZ": 1331.456658194813,
  "boundingSphereRadius": 885541.1267042665,
  "horizonOcclusionPointX": -13462700.917811524,
  "horizonOcclusionPointY": 5322463.153553393,
  "horizonOcclusionPointZ": 1532.5824073771364
}

which means the resulting magnitude for the center point is 14476633.994 which seems way off from the earth radius of 6378137

[delfrrr]

To my best knowledge it's correct coordinates https://epsg.io/map#srs=3857&x=-13462700.917811524&y=5322463.153553393&z=4&layer=streets in pseudo-merector projection https://epsg.io/3857 In this coordinates X ranges from -PiR to PiR which, with R=6378137 gives us -20026376.39 -20048966.10

@malaretv I hope it will help!

I'd also appreciate if you can share (in general terms) few details about your use case: What is the industry you are in? What is the final deliverable you are trying to achieve?

This info will help us to continue developing tin-terrain.

[malaretv]

Thanks for looking into this @delfrrr

I think there may be a misreading of the quantized-mesh spec here. You're right in that the coordinates are correct EPSG:3857 values but the spec seems to call for earth-centered fixed coordinates. In case it be a misreading on my part, I double-checked with a quantized-mesh tile hosted by the Cesium team and indeed it seems that they stick by the ECEF standard for coordiantes in the header.

As an example here's a header from a random cesium terrain tile https://assets.cesium.com/1/9/759/334.terrain:

{
  "centerX": 294883.68950743496,
  "centerY": 5648821.8414020855,
  "centerZ": 2937064.818573548,
  "minHeight": 310.0301208496094,
  "maxHeight": 7213.896484375,
  "boundingSphereCenterX": 295043.9647348084,
  "boundingSphereCenterY": 5652134.914954952,
  "boundingSphereCenterZ": 2938768.298853457,
  "boundingSphereRadius": 26199.36482914565,
  "horizonOcclusionPointX": 0.04629291133738319,
  "horizonOcclusionPointY": 0.8867917011670025,
  "horizonOcclusionPointZ": 0.46263216824528125
}

As would be expected for earth-centered fixed coordinates:

sqrt ( centerX ^ 2 + centerY ^ 2 + centerZ ^ 2) = 6373577.828405427

which is within a few km of the earth radius

As for our use-case... The industry is aerospace and the final deliverable is looking to move our lunar map terrain from using the old cesium heightmap format to quantized-mesh tiles. It's outside of the scope of this issue (and likely this project) but ultimately will require adapting tin-terrain to work on the lunar ellipsoid.

Thanks again for your time @delfrrr and hopefully the above is helpful!

[delfrrr]

@malaretv yes you are right, spec requires earth centred coords; we do not support it yet and we created custom provider for Cesium to render our tiles https://github.com/heremaps/quantized-mesh-viewer/blob/master/src/map/surface-provider.js

I see that for the Moon you'd prefer earth centred over pseudo mercator 😂

If you have experience with C++ please consider contribution of earth centred coords in tin-terrain; otherwise I will add feature to our backlog but cannot provide estimation.

[fester]

Fixed by #54