Warning - error importing Georeferenced data (Point Clouds, DEMs, ...) as Point Clouds, STMs or 3SMs in Descartes

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? 

Regards, 

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. 

What is the actual problem? Elevations are distorted randomly or it is some global offset?
Defect number?

Hi Oto,

The issue is that elevations are assumed to be relative to ellipsoid (which is usually not the case), and that reprojection may introduce differences relative to original data.

As you stated in your answer, if you keep geoid then you will see a large offset.
If you project you will have delta as illustrated in my former Email.

Reference ID is "Help Ticket 1107277" 

Best Regards

Hi vincent Thanks for your explanation. To clarify, the Microstation environment is reading Z values as relative to an ellipsoid, rather than an absolute z value? 

This is strange as I have not been able to replicate the same errors. I have access to TopoDOT and TerraScan, both of which have independent point cloud engines running inside Context Capture Editor & I have not been able to identify a difference when completing the steps in your original post. Logically I am assuming that it will only be affecting point clouds loaded into the Bentley point cloud engine, can you confirm if this is the case?

As this is a major defect, is it likely that a hot-fix will be released soon so Z values as read as absolute? 

Regards, 

Jason.

Hi vincent Thanks for your explanation. To clarify, the Microstation environment is reading Z values as relative to an ellipsoid, rather than an absolute z value? 

This is strange as I have not been able to replicate the same errors. I have access to TopoDOT and TerraScan, both of which have independent point cloud engines running inside Context Capture Editor & I have not been able to identify a difference when completing the steps in your original post. Logically I am assuming that it will only be affecting point clouds loaded into the Bentley point cloud engine, can you confirm if this is the case?

As this is a major defect, is it likely that a hot-fix will be released soon so Z values as read as absolute? 

Regards, 

Jason.

Hi Jason,

Happy to read this, I did not used TopoDOT / TerraScan, what I have checked is that the issue happens when both the Point Cloud data and the hosting DGN have a defined GCS, on 2 sample datasets (SRTM and more accurate LiDAR).

Results may vary upon datasets/locations. 

I can't speak for qualification of the issue, workaround is either to work from a non-georeferenced DGN or to strip GCS from Point Cloud/Raster DEM then import.
If you are impacted then I would recommend to log a Service Ticket (reference "Help Ticket 1107277")

Hi Vincent, 

Ok, thanks for your guidance. 

Regards, 

Jason.