DSM values are offset vs GCP altitudes

[EDIT]:

  • 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

Hello.

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

Cheers
denis

2 Likes

Thanks for sharing the dataset and posting the relevant information! :pray:

I’ve started looking into this and it does seem strange indeed. What I found so far is that the points from the point cloud (from which the DSM is eventually computed) are indeed higher in elevation, I suspect this is the result of bundle adjustment because when triangulating individual GCPs (from which statistics are computed) the elevation is lower, e.g. for T01b I got:

(-51.39244304886016, 101.90296883795236, 240.09297796245664) --> Measured
[-55.06977545  99.97969023 240.03118935] --> Triangulated
[-3.6773324  -1.92327861 -0.06178862] --> Difference (error)

image

This is the approximate location of T01b in the sparse point cloud instead, showing a much higher value in Z (other neighboring points are also off by more than what I would expect).

I haven’t been able to draw a conclusion, hopefully I’ll have some time in the upcoming weeks to look at this more closely.

2 Likes

Thanks for looking into that.
Just in case, I use the SRS 25831. IT did cause me some troubles in the past, IIRC. Could it be related?

1 Like