DSM values are offset vs GCP altitudes

[denisot]

[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

[pierotofy]

Thanks for sharing the dataset and posting the relevant information!

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)

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.

[denisot]

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?

[denisot]

Hello.
I was wondering if you had time to look into that?
It’s not that it is a real stopper, I can still align the pointcloud on the GCP in CloudCompare, extract the DSM and obtain about the same accuracy but I would prefer not having to go through these additional steps.

Thanks anyway.
Cheers.
Denis

[ThorZ]

@denisot

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!).

I also faced similar issues and did some investigations. The problem is the GCP report usually shows really small errors, but when surveying the point on DSM, we can find some larger errors. My theory is that the GCP accuracy is calculated by the difference between the triangulation of image markers and GCP coordinates. Since the model alignment is based on the triangulation of image markers and the GCP coordinates, the calculated GCP errors would usually be small. But this doesn’t mean the triangulated points would be on the model surface. When I put the triangulated points along with the sparse point cloud, I can sometimes observe the triangulated points higher or lower than their neighbors. Probably the GCPs are not used to refine the camera parameters, therefore the reconstructed camera parameters might not be 100% accommodated with the image markers.