Adjusting from ellipsoidal to orthometric heights

General Help
1

Hello,

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.

Thank you for any suggestions

1 Like
2

The pointcloud can be adjusted pretty easily in CloudCompare, with DSM you could use the raster calculator in QGis.

1 Like
3

I do both. When adjusting the photos I use this free tool which does an x/y lookup for each one and applies the offset:

https://www.seilergeodrones.com/geophoto-latest

1 Like
4

Good tips, thank you.

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.

1 Like
5

In cloudcompare you can make DSM/dtm and “ortophoto” from a pointcloud.

So you could adjust the cloud and then extract what you need.

1 Like
6

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.

1 Like
7

@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!

1 Like
8

I guess it depends :smiley:
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.

1 Like
9

as always… Hi from Munich - not exactly far away. Well, it depends… :wink:

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!

1 Like
10

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

1 Like
11

Servus! Dario from Bavaria :slight_smile:
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.

12

thanks for the clarification! Makes perfect sense. I will try

to subsample your pointcloud according to your ellipsoid-orthometric-height-correction-grid and z-translate each subset respectively.

and will let you know if it works :slight_smile:

13

thanks! But I fear I needed it translated subsampled into subsets first etc.
So I meanwhile tried the following, coming from good old 2017 here:

but frankly am a bloody Conda/PDAL beginner…

I tried:

pdal translate input.las output.las reprojection
–filters.reprojection.in_srs=“EPSG:4326+4326”
–filters.reprojection.out_srs=“EPSG:4326+3855”

but was not getting any response.
Whilst from Convert between Orthometric and Ellipsoidal Elevations using GDAL – Spatial Thoughts
I learned that

Since the release of GDAL3/PROJ6, this EPSG syntax is no longer supported.

and dear hobu (Howard Butler) giving advice to:

use filters.projpipeline for complete control

I’m working on that, but haven’t make it work yet. So support is still much appreciated.

14

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:

$ projinfo -s "EPSG:4979" -t "EPSG:9518" -o PROJ -k operation

Candidate operations found: 2
-------------------------------------
Operation No. 1:

unknown id, WGS 84 to EGM2008 height (1), 1 m, World.

PROJ string:
+proj=pipeline
  +step +proj=axisswap +order=2,1
  +step +proj=unitconvert +xy_in=deg +xy_out=rad
  +step +inv +proj=vgridshift +grids=us_nga_egm08_25.tif +multiplier=1
  +step +proj=unitconvert +xy_in=rad +xy_out=deg
  +step +proj=axisswap +order=2,1

-------------------------------------
Operation No. 2:

unknown id, Inverse of Transformation from EGM2008 height to WGS 84 (ballpark vertical transformation, without ellipsoid height to vertical height correction), unknown accuracy, World, has ballpark transformation

PROJ string:
+proj=noop
15

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.