Sorting out DJI's bad GPS Altitude tagging

[HeritageNI]

Hi all,
I thought my workflow for getting more accurate pre-processed elevation data out of the EXIF meta-data might be useful for some on here. Improvements welcome of course. This is currently what works best for me.

OBJECTIVE
For non-survey grade projects without using pre-sampled Ground Control Points, to get as accurate as possible elevation data prior to processing in Photoscan Pro. In other words to get the most accurate map/model/orthomossaic/DEM etc as possible without using RTK GPS.

PROBLEM
The usual metadata tag that is used by these applications is the ‘GPSaltitude’ tag. Currently DJI populate this from the aircraft's GPS unit. The altitude recorded here is grossly inaccurate. We need to fix this as far as we can.

BASIC WORKFLOW

• Establish and record the altitude above mean sea level of your take-off point.
• Back in the office we need to process the meta-data from all the photos taken poking a more accurate figure into the GPSaltitude tag.

Thankfully DJI do record another tag called RelativeAltitude which populates the tag based on the height above your take-off point using the aircrafts barometer.

We want to add this RelativeAltitude value to the calibrated barometer reading we took from our phone/device at take-off to come up with an altitude above sea level figure for each photograph.

Then we want to write this combined value into the GPSaltitude tag that Photoscan Pro can use.

PREREQUISITES
•   Go here and get the free Exiftool command line tool from Phil Harvey http://www.sno.phy.queensu.ca/~phil/exiftool/
•   For ease of use and file management  I use a GUI version layer on top of this called exiftoolGUI.exe. Get it from here: http://u88.n24.queensu.ca/exiftool/forum/index.php/topic,2750.0.html
•   I use the Exiftool AND the exiftoolGUI. You can just use the command-line tool if you are confident and familiar with using it. I like the easiest way out though!
•   Download a barometer app for your phone/device. One that can be calibrated. As barometers are based on air pressure it needs calibrated around the time of take-off with some known weather station in your area to allow for the variance introduced by weather conditions. 

WORKFLOW
1.   Record this AMSL altitude reading from the Barometer app at your take-off point at the time of photo aquisition.
2.   Back in the office MAKE A COPY of the photos you want to process in a separate folder. THIS IS A MUST. If you cock the EXIF meta data up you cannot get it back!
3.   In the ExiftoolGUI navigate to the folder that contains the COPIES of your photos.
4.   At the bottom of the central pane there is a button labelled ‘Exiftool direct’…click it
5.   In the command text box paste this text...

Code: [Select]

-n -GPSAltitudeRef=0 -tagsFromFile @ -RelativeAltitude>GPSAltitude *.*and press enter. A small info box shows the status of the process. This copies the RelativeAltitude value into the GPSAltitude tag for all the photos in the folder
6.   Now we want to add the AMSL value that we took from our phone/device at take-off. Delete any previous text from the command text box.
7.   Take the previously recorded AMSL altitude from the phone/device and DIVIDE IT BY 2. Not sure why this has to be done (I may not have exactly the right syntax to use the full value…anyway this way it works!)
8.   Paste this text in the command text box...

Code: [Select]

-n -tagsFromFile @ -GPSAltitude+=ALT *.*BUT replace the ‘ALT’ with your 'divided by 2 value' and press enter.

DONE

Always check and compare the metadata with the original files to make sure it did what you wanted it to do. Analyse the pop-up status info box for any errors.

Now you can process in Photoscan Pro as usual.


Any suggestions welcome of course...its just what works for me.

[ARF]

Hi,

I find it easier to just process as is and then apply a height shift and coordinate shift to the exported ortho and dem in GIS software.

Although as a surveyor we normally process with high accuracy photo control.

[oxfordblue]

To avoid having to divide the take-off point elevation by 2, you can change the second command to:

Code: [Select]

-"GPSAltitude+=ALT"
Originally, the program was checking the name of the image (as per the *.* command) and applying the calculation.
This resulted in the altitude value being added twice as the images were being processed twice.

[HeritageNI]

The best way to do this is by Python scripts below. The 2 scripts in this post can be saved then run from the Tools/Run Script... menu item. works a treat.

Forum Altitude Fix Scripts

[ak]

Thanks very much for posting this workflow. I think you are mistaken on one point however.

This is an old post but hopefully someone will respond if the below does not add up.

By correcting your relative elevation values with a home point barometric elevation value I believe you are potentially introducing rather than doing anything to eliminate barometric elevation variance into your resulting absolute elevation values.

Barometric variation may cause an absolute elevation value to read higher or lower than is true but should not affect the relative accuracy (given that pressure conditions are regionally stable). For a simplified example if the actual elevation is 100m and your barometer reads 200m and then you walk uphill 50m your barometer will read that pretty accurately and give you an elevation of ~250m.

Since the DJI barometer is giving you a relative elevation value (above your control/home point elevation) you should correct it with the best available elevation value for your home point. A good quality calibrated barometric elevation reading may meet this qualification however I would check as to what data it is using to calibrate you may not be getting a value any better than the consumer grade GPS elevation that you are trying to bypass with this whole process (although at least it would be a consistent variance across the dataset since it comes from one reading).

For example at the below link for an iphone app you can see that there are a variety of ways that this particular app may be calibrated.
https://www.ios-altimeter.com/

Suggested sources for best elevation values: a good GNSS reading at the home point, GIS layers such as: National Elevation Dataset or a local Lidar dataset

Note: there are the scripts as mentioned above however this workflow seems like potentially a better option for projects that involve multiple home points

[Pkroks]

This may be the wrong place, but I am having an issue with data I have processed, an issue I have never come across before but it may be exactly related to the DJI method of recording GPS and altitude.

I have processed an area flown with a DJI Phantom 4 Pro.

The GCPS were captured and recorded. Their values have been used for processing.

The final output model seems to be off uniformly approximately 10m.

For example -

GCP7 - elevation is 1238m
The actual elevation of the output model at the GCP7 location is 1228m.

GCP8 is 1241m
The actual elevation of the output model at the GCP8 location is 1231m.

I am unsure how there is this variation across the site, I have never experienced this before? How do I correct the error?

[sjn]

Thanks IrishSights