- I changed the title to reflect my real problem (was “Relation between Z error and dem offsets?”)
- made a few edits in the text for clarity purpose
After a long 2 years hiatus I’m back doing photogrammetry and using WebODM. I quickly got reacquainted with WebODM and I’m doing some testing to prepare some upcoming photogrammetry missions. My previous (4 years ago) ones were done with a DJI Phantom 4 Advanced (P4A), but now the pilot I’m working with has a Mavic 2 pro (M2P). So I’m back doing some testing because our project needs very robust xyz data (i.e. xyz precision and accuracy are more important than orthophoto quality). Results from the P4A were very good, especially since 2019.
The question I have is the following: is there a relationship between the Z error as reported in the report and the dem values? Asked differently: does the Z axis (as reported in the report) corresponds to the altitude? I understand that X and Y do not align with east and north directions, but Z?
My question comes from a dataset that I’m using for testing adn where the DSM values are off. The dataset was constructed as follows:
- 9 GCP determined on the ground and used in the reconstruction (with ~6 images tagged for each)
- electronic shutter for the M2P but the drone stops to take the pictures (no motion)
- WebODM with the main options: feature and PC quality high, no resizing of pictures, resolution 4.0, max-concurrency 12, dsm output
I’m puzzled by some results:
Here is an extract of the report.pdf, with the GCP errors:
An example of xy agreement on the orthophoto is visible here (GCP called T04 is GCP-2 in the report):
I’m happy with that, given the error I make when clicking in the GCPEditorPro interface is probably 1 or 2 pixels (by the way, the new version of GCPEditorPro is absolutely amazing, in particular since the addition of the filter by distance!).
And now here is a screenshot from QGIS where I used the ‘terrain profile’ extension to plot the difference between the dem value (from WebODM) at the GCP coordinates and the corresponding GCP altitude (from GPS). I.e. 9 values corresponding to
[email protected] - altitude_of_GCP
The dem values are consistently higher than the GCP altitudes: the offset MEAN is 14cm, and the offset RANGE is 9cm. And this is not in agreement with the table above where the 9 z errors are dispersed around zero (both positive and negative values), their absolute value is never larger than 5.2cm, and their average is ~2cm.
[EDIT] I forgot to add that if I shift globally the dem (by the MEAN value of its offset % GCP altitudes), I end up with z errors more in line with the report. In details, this is the profile that I then obtain:
And the basic statistics of this corrected DEM (at GCP coordinates) is: MEAN=0, RANGE=9cm, STD_DEV=2.35cm. In agreement with mean, sigma and RMS values at GCP from the report:
Any idea about what’s going on?
Images, gcp_file and output files (task_output and report) are available here: yulpa Drive
My browser is Firefox 108 on Ubuntu Linux
WebODM installed via docker under Ubuntu 22.04