Hi,
I updated elevation data and added more accurate lidar data to the terrain. However, it seems that OSM buildings are linked to the default terrain and floating (see image attached). How can I clamp the OSM buildings to the new terrain?
There’s no way to clamp Cesium OSM Buildings to the surface on the fly. The best you can do is adjust the tileset’s transform so that the buildings are on terrain in the area you care about.
Because those height errors look quite large, it’s possible that those floating buildings are not caused by “more accurate” lidar data, but rather by incorrect accounting for the difference between ellipsoidal and mean sea level heights in your lidar data. How was your lidar tileset created?
Kevin
Hi Kevin,
I downloaded elevation data from GeoScience Australia with following parameters:
PROJ_DESC=MGA (Map Grid of Australia) / GDA2020 / meters
PROJ_DATUM=GDA 2020 (AUSTRALIAN GEODETIC 2020)
PROJ_UNITS=meters
EPSG_CODE=EPSG:7855
BBOX AREA=192 sq km
LOAD TIME=0.05 s
FILE_CREATION_TIME=5/5/2023 3:59:19 PM
FILE_MODIFIED_TIME=5/5/2023 3:54:43 PM
GDAL_NO_DATA_VALUE=-32767
NUM COLUMNS=16000
NUM ROWS=12000
NUM BANDS=1
PIXEL WIDTH=1 meters
PIXEL HEIGHT=1 meters
MIN ELEVATION=536.556 m
MAX ELEVATION=845.916 m
ELEVATION UNITS=METERS
BIT DEPTH=32
SAMPLE TYPE=32-bit Floating Point
PCS_CITATION=GDA2020 / MGA zone 55
GT_CITATION=PCS Name = GDA2020 / MGA zone 55
PHOTOMETRIC=Greyscale (Min is Black)
SAMPLE_FORMAT=Floating Point
ROWS_PER_STRIP=1
COMPRESSION=None
PIXEL_SCALE=( 1, 1, 1.0 )
TIEPOINTS=( 0.00, 0.00, 0.00 ) → ( 687000.500, 6097999.500, 0.000 )
MODEL_TYPE=Projection Coordinate System
RASTER_TYPE=Pixel is Point
GeoTIFF::ProjLinearUnitsGeoKey=9001
GeoTIFF::ProjectedCSTypeGeoKey=7855
GeoTIFF::GeographicTypeGeoKey=7844
GeoTIFF::GeogSemiMajorAxisGeoKey=6378137
GeoTIFF::GeogSemiMinorAxisGeoKey=6356752.3
GeoTIFF::GeogEllipsoidGeoKey=7019
Unfortunately none of those parameters clearly state the height reference. EPSG:7855 is a 2D CRS, so that doesn’t help. Similarly, GDA2020 tells us a lot about the horizontal coordinate system, but nothing about the vertical one.
But it’s very likely that such data from GA is referenced to the Australian Height Datum (AHD), which is not an ellipsoidal surface but rather closer to a mean sea level surface. Did you then process this terrain with Cesium ion? If so, you need to be sure to select MSL (not WGS84) when tiling it.
ah… Ok, I will try to integrate elevation data with MSL (EGM96) and let you know about the results. Because previously I used option Auto Detect.
I’ve tried to integrate the elevation using MSL, but no luck. The result is pretty similar to previous one. Also, I mentioned that the difference in elevation everywhere is different: somewhere there is a small gap, in other places there is big distance (I highlighted by red).
Ok, I’d give it one more try with Cesium ion configured to use WGS84 this time, since we’re only guessing at the source data’s actual height reference. Different terrain will of course have different heights, so some discrepancies are unavoidable. You’ll still have places where the buildings are floating or buried slightly, but I’d expect it to sit better than I see in your screenshot. If that doesn’t help, there is unfortunately no solution at the moment.
Thank you for information. I’ve tried to create the new terrain using WGS84 and I’ve got the same result. However, it seems like I found the issue. I checked the border of my terrain and Cesium and found the gap (see image attached). I think it is a problem of different vdatum. For example, WGS84 and EGM96, or EGM2008. What kind of vdatum is used by Cesium terrain?
WGS84 and MSL are tens of meters different in Australia, so “same result” is very surprising. Are you sure?
But yes, vertical datum is exactly the problem I’ve been pointing to. Cesium ion can either use the WGS84 ellipsoid, or if you choose MSL, I believe it uses EGM2008.
I did some kind of a research, here are the results:
the initial elevation data from GeoScience Australia has MGA (Map Grid of Australia) with GDA 2020 Datum. I converted it to following projection: Geographic (Lat/Lon) with WGS84 datum.
Then, I tried to upload this converted elevation to Cesium Ion with different parameters, like WGS84 and MSL.
This is result with WGS84:
As you can see, there is a gap between Cesium Terrain of the whole Earth and new elevation data. Also, the buildings are floating on pretty much high altitude.
Here is the result of elevation data uploaded as MSL:
No gap between two layers of elevation, however, the buildings are still a bit floating.
I think it’s happening just due to the poor elevation data from default Cesium Ion terrain. In case, if it is impossible to update the OSM buildings from the new terrain, is it possible to do something like that in the future?
This is just a horizontal shift, because you’re projecting between two horizontal datums. Also, many (most?) tools will implement this particular shift as an identity transform, so it won’t actually change anything.
So it looks like the heights are closer when treated as MSL, but still not quite right. You could be right that the terrain data is just particularly bad in that area.
Adjusting building heights at runtime is likely to be quite expensive in terms of performance, so I’m not sure if we’ll ever go down that road. Regenerating Cesium OSM Buildings with a different terrain reference is relatively easy (significant processing time aside), but we don’t currently offer a way for users to do that themselves. I think that ultimately the right answer here - even though it’s not a general solution - is to incorporate the improved terrain data from GA into Cesium World Terrain. This is definitely something we’d like to do, but I unfortunately can’t offer an ETA for it.
Kevin
1 Like