first of all, I want to clarify that I used ChatGPT only to help me write this post in English, because of the language barrier. Anyway I have fully understood and verified all the technical details reported below.
Workflow I followed
Drone flight: DJI Matrice 4E RTK connected to HxGNSmartnet NTRIP.
Image metadata: Extracted with ExifTool. The tags XMP:AbsoluteAltitude and GPSAltitude report consistent ellipsoidal heights (≈167 m).
Conversion: Using ConveRgo (government software) with official IGM ITALGEO05 geoid:
Input: ellipsoidal heights.
Output: orthometric heights H(ITALGEO05).
Result: converted heights around 124 m, which match the expected values in my area.
geo.txt creation: I generated a geo.txt file containing filename, longitude, latitude, and H(ITALGEO2005) for each image.
WebODM processing:
Uploaded images together with the geo.txt.
No GCPs provided, as the aim is a full-RTK survey.
Independent Leica checkpoints (ESRI:3003 + IGM05) were used only for validation.
Problem
The reconstruction is accurate in planimetry.
However, the resulting model is systematically 0.7 m lower than the independent Leica checkpoints.
The offset persists even after checking all conversions and ensuring both drone altitudes and checkpoints are in the same vertical reference.
Question
Is there a bug or limitation in ODM in how it handles altitudes provided via geo.txt?
Could I be missing a configuration related to vertical datum interpretation?
Has anyone reproduced a similar ~0.7 m vertical bias when running a full-RTK workflow and checking against independent ground checkpoints?
I don’t know, it doesn’t seem to be my case. Moreover, the geodetic elevation at takeoff is about 79.7 meters, and given the flight height of 45 m it would be 124.7 - 45 = 79.7. Aside from decimals, the altitude recorded by the drone and then converted seems consistent. The second point on the west embankment is the GCP, which should be 79.5. From this and other points I deduced that the model seems to be shifted in Z by -0.7 m.
if you run pdal info on the odm_georeferencing.laz file, what’s it say? I’m having similar hard time trying to get a custom site proj4 reference where I’ve got a post-processing in an elliptical system, but continually get offsets. One of the steps might be including a vertical adjustment.
Thanks to everyone who took the time to reply and offer suggestions. Over the last few days I have been running more tests to better understand what is happening, and something quite clear has emerged. When I process image sets that contain oblique photos, the reconstruction aligns correctly in Z, with no sign of the ~0.7 m bias that I originally reported. The offset only appears when I use slightly off nadir (-85) imagery.
With oblique datasets the stronger geometry seems to provide enough constraints in the vertical direction so that the final heights are consistent with my checkpoints. With nadir-only datasets, instead, the weaker geometry does not fully constrain Z, and the systematic offset remains.
As you can see, when using the oblique function in Pilot 2 an excessive number of photos are taken (996 compared to about 400), so I will try some tests to get the same result with a manual flight plan, for example: a nadir flight with 60/60 overlap and a second pass at −45° with 80/70 overlap.
