In recent my jobs pointcloud and orthophoto looks good, however the DEM (either DSM and DTM) have the right shape, but the absolute height is wrong, showing negative values that makes no sense, as can be seen on the next figures:
Processed on Lightning ODM v2.5.4
OBS1: not all photos have geotag information, missing for 15 in a set of 700.
OBS1: composed from 14 flights, 250m average flight height (from each take off location).
Processed on Lightning ODM v2.5.4
OBS1: not all photos have geotag information, missing 3 in a set of 119 photos.
OBS2: flight height = 120m.
The next one is right, was done a few months ago in WebODM for linux with docker (ODM 2.4.9), some bug resulted in the report preview being purple, but the model is acurate:
When a geo.txt is used but not all photos have geotag information, i.e., at least one of the photos are not listed in the geo.txt, the resulting DEM is incorrect, offseted from what it should be.
The next image is the DTM resulted from the same data (#4) in the previous post, however the last line of the geo.txt was deleted, resulting in one photo without geotag information. Check the height difference in the scale.
The flight height was 250m above ground level, from the picture we can see the lowest point on ground is at -250m, so I suspect ODM considered flight altitude = 0m.
I’m processing on Lightning against v2.5.5 and I had to modify the geo.txt to change from EPSG:4326, which it didn’t allow with a missing entry, to EPSG:32723 (which looks to be the most appropriate EPSG code for the data).
It errored out with the missing geodata for the last image (DSC04155.JPG)
===== Done, human-readable information to follow... =====
[ERROR] Uh oh! Processing stopped because of strange values in the reconstruction. This is often a sign that the input data has some issues or the software cannot deal with it. Have you followed best practices for data acquisition? See https://docs.opendronemap.org/flying.html
With the full geodata and the above processing settings, this dataset processes perfectly fine, as you’ve observed.
It looks like this might be a bug/limitation of how incomplete geodata (when provided via geo.txt) is handled in the processing pipeline at the moment.
Is this a terribly common occurrence in your data collection methodology?
Do you have any means to adjust your procedures to prevent this from happening for the time being?
If not, I can only suggest maybe trying to drop any images that lack geolocation data from the reconstruction entirely, or adjust the height values using something like QGIS Raster Calculator after the fact to correct it.
Thanks for the help, I have no background in topography and have been using EPSG:4326 for all tasks in WebODM, both local and Lightning, and never got an error regarding that, as a matter of fact I have processed this dataset yesterday with Lightning v 2.5.5, with and without missing geodata for the last photo using EPSG:4326, both tasks completed the processing pipeline without any errors or warnings, however there is the bugged absolute values in the DEM of the 1-photo-missing-geotag case.
Anyway, you are correct about the Coordinate Reference System, EPSG:32723 looks to be the most appropriate for the data.
Just now I have tried processing the missing case again using EPSG:32723 and got the same error you reported. But, once again I was able to process using EPSG:4326, with the DEM bug.
At the moment, as you sugested I am using both workaround you have suggested, drop any photo that lack geolocation; or, after processing, adjust it using Raster Calculator in QGIS, it’s just a simple offset. Not a problem, easy to do.
Just for curiosity: at the moment, the real problem for me, not related to ODM, is that my (not so good) PPK system, for some unknow reason, is not logging the trigger feedback for some photos, so after some flights sometimes I have more photos than recorded events in the PPK log… identifying the photos that were not recorded in a dataset with high sobreposition and short temporal separation is a pain in the ass…
Terrible… not related to ArduPilot. Modified camera outputs a 1-wire logical signal (high pulse) straight to PPK receiver’s logical port. Signal goes directly to PPK receiver, not processed by ardupilot.
