For some maps I would like to fly without GCP’s, which means I will need to try and adjust from ellipsoidal to orthometric height.
Does everyone just do this after the photogrammetry stage with QGIS/GDAL? Are there any advantages to somehow adjusting the elevation data in the image tags prior to photogrammetry?
When adjusting, do most people just use a constant value? Does anyone use a geoid grid file for large projects?
For conventional surveying/mapping our survey software just lets us select the correct geoid file, which is HT2-2010. But I don’t actually understand what happens behind the scenes and how I might implement a consistent process with RTK drone mapping.
I hadn’t checked out raster calculator yet and looks like that is a functionally of QGIS that I will needing to implement for various things.
I ignored GeoPhoto because for some reason I believed I would not be able to use it with my required geoid model. I will be testing this as soon as I can get it installed on my work machine.
Could the developers add an option/parameter to ODM which is equal to the correction offset from ellipsoid to orthometric height?
Let’s say the offset for Project Area XY is -50m. This value just needs to be added to the Z-data in point cloud/DSM/DTM. This way one would not need to post-process the elevation data.
@david, to my understanding this wouldn’t be exactly solve Luc’s case assuming the shift is barely ever the same throughout an AOI. But please correct me if I’m wrong.
@APOS80, when you say:
pointcloud can be adjusted pretty easily in CloudCompare
would you mind sharing a short how to?
Working on a dataset in EPSG-32635 with ellipsoid elevation values I managed to convert a DSM using gdal to orthometric values. When trying the same with CloudCompare for the pointcloud I’m pretty much just scratching my head.
Thank you in advance!
I guess it depends
I’m living and working in Austria, so the following only applies here and I do not know how other countries handle this topic.
So for Austria, the local federal office for surveying publishes a nationwide grid with the offset value to convert ellispoidal to orthometric heights. The pixel size of this grid is approx. 450x450m. So as long as you are within one pixel, correction values are consistant. Even the difference to neighboring pixels (<3cm) is negligible concerning photogrammetric surveying.
as always… Hi from Munich - not exactly far away. Well, it depends…
I see… in that case you’re perfectly right.
In my case, the AOI is a few dozen sqkm and we needed to stay in a relatively precise range for elevation values. I used the same grid approach for the DSM though. And I’d do it again on the cloud. If I knew how…
As we haven’t seen @APOS80 here today, would you @david know the cloud compare workflow he mentioned? Or PDAL?
Thanks!
With PDAL it is as simple as applying a transformation filter with only the translation in the Z coordinate (tz) in the transformation matrix: filters.transformation — pdal.io
Servus! Dario from Bavaria
Sadly, I only know the CloudCompare-workflow for a constant correction value as I described.
You can apply a Z-offset to your pointcloud with the tool “Apply Transformation”.
Switch to “Axis, Angle”, leave everything blank/zero and only insert the Translation value for Z.
You may be able to subsample your pointcloud according to your ellipsoid-orthometric-height-correction-grid and z-translate each subset respectively. Its’s just a guess, haven’t tried it myself.
Also make sure you don’t apply a global shift/scale when importing your pointcloud into CloudCompare, it may complicate things during your workflow.
Sorry, I thought you wanted to apply a constant offset.
I’m not sure about the syntax on the command line. I generally define inputs, filters and outputs in a PDAL pipeline and use: pdal pipeline the_pipeline.json
Regarding the ellipsoidal heights i have no doubts, but are you sure that your horizontal coordinates are geographic and not projected?
In that case, the original system must be EPSG:4979 (WGS84 geographic 3D).
The “geographic WGS84 horizontal + EGM2008 height” compound system is EPSG:9518.
For the vertical transformation to take place, you must make sure that the vertical grid us_nga_egm08_25.tif is downloaded in the $PROJ_DATA directory.
I suppose filters.reprojection should work fine with the correct EPSG codes, but if you wanted to know the proper PROJ pipeline (for example if you needed to un-project horizontally, transform vertically, and then project horizontally again) to be used with the filters.projpipeline, you could refer to it with something like: