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 ?
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.
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.
