Process report not accounting for calibrated elevation

I am a newbie using Pro. After the image processing finished for my first map, I noticed that the elevation was far off from the real elevation and that all values were negative. So I used Calibration to adjust the elevation to a ‘known’ elevation. That fixed the values on the screen, but the Process Report did not account for the calibration. The colors in the process report elevation model look fine, but all values in the color scale below the model are negative.

How can I make the Process Report show the correct (calibrated) values for the color scale?

Thanks,
Kjartan

Unless your using a RTK drone your elevations will be off.

Example: If you at a location that is say 425’ elevation and you fly a Phantom 4 @ 100’, the image will show the elevation of 100’ but if you had a RTK drone it would show 525’ elevation (the correct elevation).

Setting a Calibration elevation adds the corrected elevation to the Map, as you seen.

1 Like

Hi GregO,

I just used Mavic Pro.
I had expected the process report to show the same elevations as the map… Shouldn’t it?

Thanks,
Kjartan

Let me get some clarification, are you setting the Map Calibration and then running the report and it not showing the Calibrated Elevation? If this is the case then we can ask DD to look into it.

I fly RTK now days and it’s been awhile since I’ve processed a map and used the calibration. I will find one and look on my map and see what it does.

Yes, that is exactly what I did and the report elevation differs from map Calibrated elevation. So, yes hopefully DD or someone can explain why?

1 Like

… I just realized that the report says Absolute Altitude… should it not be Relative Altitude… and how can I change that?

1 Like

@KHV The progress report will only display information it gathers through the processing of the map. Changes to the map that technically do not go through our processing pipeline (such as calibration elevation) will not display in the processing report. Right now users cannot add other information to the processing report but if you have any suggestions of what you would like to see we’re all ears!

I’ve had the same issue as @KHV (and, I suspect, many others), and it’s due to the issue that the GPS uses the WGS84 ellipsoid model to calculate sea level (and therefore altitude), rather than the Geoid model. The Geoid model provides the correct sea level (and therefore the correct altitude), but its difference relative to the ellipsoid varies with location, so you have to apply a specific correction for your location (here in the Carolinas, it’s about 100 feet). You can do that with DD’s elevation calibration tool, but the problem is what Kaitlin describes above: since that calibration happens downstream of the processing, it won’t show on an accuracy report, and it’ll still look like you’re 100 feet off. BTW, @GregO, this is not an RTK issue - at least using the CORS stations in NC and SC as RTK correction sources - because those stations correct the GPS location for the variables of the GPS itself, not for the shape of the earth (ellipsoid-vs-geoid). So there are two potential solutions: 1) get a position correction that includes the ellipsoid-to-geoid correction; or 2) DD’s accuracy report moves downstream so that it captures the elevation calibration. A PPK source (rather than RTK) like EZ-Surv by Effigis provides solution 1. Do any of you on this thread know of a way to get that solution via RTK?
BTW, I’d like to thank both @Kaitlin and @Adam for their insights and help on this issue.

1 Like

Actually most drones use the barometer related to sea level for the elevations that are entered into the EXIF data. Neither Ellipsoid (WGS84 is not an Ellipsoid, EGM96 is) or Geoid have anything to do with sea level, that’s where the barometer comes in. Only RTK drones tag the images with GPS data.
Even though the Accuracy Report (which isn’t worth a whole lot on its own) doesn’t report adjustments, the exportable data does.

1 Like