If you are dealing with Georeferenced data to build elevation models, then please read this article to prevent errors in Elevations
Best Regards
Hi vincent . Can you confirm if this only effects commands where a STM, 3SM or TM terrain are extracted, rather than there being an error on import? E.g. If we have produced a georeferenced 3XM/3SM in context capture and imported into a georeferenced DGN file there will not be a "less detectable" elevation error?
Regards,
Jason.
Hi Jason,
Only Terrain Reality Meshes computed in OpenRoads/Descartes are affected, Reality Meshes computed in ContextCapture are not.But DEMs/pointCouds exported from Contextcapture would (if they are georeferenced and consumed in a georeferenced file.
Vincent RAULT [Bentley]
For me changing GCS from ellipsoid to geoid helps to prevent elevation mismatch.
I have also noticed this behaviour and fix by changing from ellipsoid to geoid. vincent is the offset you have observed related to this offset, or have you noticed other offsets unrelated to a GCS ellipsoid to geoid offset?
What I am trying to understand is if we have a point cloud exported from context capture and then imported into a georeferenced dgn, are we only likely to see a reasonably large ellipsoid/geoid offset (as we work in UK coordinate systems) or might there actually be a small error - for example 30cm that would likely to be undetected unless the point cloud/DEM was again verified against control or we complete your proposed work around?
Jason
The ellipsoid to geoid reprojection does induce differences with original data:The elevations are distorted, up to 1 m delta on 5cm accurate LiDAR, -12 / +12 m on SRTM 1 arc second SRTM in datasets I checked.
Example of delta with 5 cm accurate LiDAR:
If the context is to provide environment for renderings, then it might be acceptable, but if the context is to create a surface for computations, this might not be acceptable.