STK-Terrain shifts

Hi All,

I noticed some differences between elevations contained in STK Word Terrain tiles and other DTM (both SRTM and DTMs created by our company).

For example, over Hanoi most of the elevations are negative (about [-10…-20]). This is not the case in SRTM, in our own DTM and in Google Earth were elevations are positive (about [10…20]).

I would like to understand why there are such differences.

I’m wondering if this may be caused by STK-Terrain using a specific geoid ?

Thanks in advance,

BR,

Fred.

Hi Fred,
I can only speak to the elevations from SRTM here, but those elevation reported by the STK World Terrain are relative to the WGS84 ellipsoid, whereas the source SRTM data is relative to mean sea level. While processing a tileset using AGI’s terrain processing library, the SRTM datasource heights that are relative to mean sea level are converted to the WGS84 ellipsoid when building a quantized-mesh terrain tile. For SRTM data, we use the EGM96 geoid as the height reference (see https://lta.cr.usgs.gov/SRTM1Arc). In sampling the EGM96 model around Hanoi, I see the geoid offset from the ellipsoid is around -28m. I believe GoogleEarth is reporting elevations relative to Mean Sea Level, which explains why you are seeing positive numbers reported there.

Alex

Hi Alex,

thanks for your answer.

I’m now adjusting my Roof absolute elevations with the EGM96 local value (sampled from the 0.25° grid found here http://www.agisoft.com/downloads/geoids/),

and my buildings are more close to the ground (image1 = without geoid, image2 = with).

As I extrude buildings from roof to ground using their height, and as our DTM (used to compute the height, height = roof - dtm) is not identical to the STK DTM, buildings don’t fit exactly the ground.

In order to make them fit the ground, I have tried to add a skirt (ie extending bottom of the building under the ground). Now buildings seem to fit the ground, but a new problem appreaed : when I move the view, the intersection of the buildings with the ground change as illustrated on images 3&4.

Any idea about to fix that ?

Regards,

Fred.

image3.png

image4.png

The last problem was solved by adding

viewer.scene.globe.depthTestAgainstTerrain = true;

Fred.