Support Website Contact Support Blog

Negative Altitude Values

 I have collected aerial imagery using a DJI Phantom 4 and within the Properties of the images the altitude is displayed correctly, however, when I load them in to Pix4DMapper all of the altitudes are given negative values.

Can anyone shed light on why this is happening and a possible solution?

Hi Eldred,

The images that are saved on the drone’s SD card are geotagged by DJI. Regarding the Lat./Log. coordinates, the drone’s GPS saves reliable information in the image EXIF. There is no problem from that side. However regarding the altitude there might be some inaccuracies depending on the location when you are mapping.

According the latest news on our side that refer to the firmware v. and v1.7.0060 for the Inspire I and Phantom 3 Pro respectively, DJI now measures the absolute elevation above sea level using EGM 96 as the reference. This also applies to the Phantom 4’s firmware. DJI used to record the elevation above ground level but this is no longer the case. However the vertical coordinate is still not fully reliable. Indeed, we made testing in our office here and we found that the vertical coordinate is off by several meters that can reach an error of 100 meters. Some users noticed the same.

Note that this is just an offset meaning that the within the model, the accuracy is not affected, only the absolute location.
DJI released on April 7th new drone firmware, but as far as we know, the issue remains.

Therefore our developers suspect something wrong in the DJI EXIF regarding the vertical coordinates. As a consequence, we always recommend to process with ground control points (GCPs) in order to fix these uncertainties.
About using GCPs:

If you do have GCPs, you could get for instance 5 points from a Web Map Service server over your area (e.g. Daft Logic):

  1. Make sure to define the appropriate GCP coordinate system. The Daft Logic website takes the coordinates from Google Maps which refers to the mean sea level (MSL) egm96 to estimate the vertical coordinate.
  2. On the menu bar, click Project > GCP/MTP Manager… > GCP Coordinate System > Edit… > choose WGS 84.
  3. Then click Advanced Coordinate System > select MSL egm96.
  4. Then insert/import the points according:
  5. In the field Type make sure to set Ground Control Point, and manually enter the coordinates you took from the website.
  6. Then on the menu bar, click Process > Reoptimize.

Regarding the negative values, it happened that the field referring to the altitude above sea level is actually called “Below Sea Level”, which might be confusing. They probably made a mistake with the reference name which seems to happen time to time.
There is a DJI forum post related to this issue:

A consequence is that when Pix4Dmapper reads the geolocation contained in the EXIF, the software is misled and interpret “below” as a negative value. Our suggestions using points to fix the vertical coordinate as mentioned above will probably solve this problem.


I’ve experienced this too, and just posted my solution on a related forum post. Here’s what I said, hopefully it will help point in the right direction:

I ran into the same problem with my Phantom 4. DJI is recording into EXIF the GPS altitude, relative to the ellipsoid, which is very rarely accurate or useful for photogrammetry or surveying. I had photos showing up as below sea level as well, and inaccurate (ellipsoid-referenced) elevations throughout my study area. Thankfully, the barometer information is still present in jpeg metadata, but you have to make some tweaks to bring it out. Here’s how I did it, though there are likely other ways (note: some basic coding is involved):

I used exiftool:

This (freeware) application can be run from the command line, though I did it within R using “system()” to call exiftool.exe, though the same syntax should work. If you go the R route, exiftool.exe should be in your working directory.

You can view all the metadata tags with a command like system(“exiftool DJI_0807.JPG”)

You’ll see several tags, though the relevant ones are GPSAltitude, RelativeAltitude, and GPSAltitudeRef. GPSAltitude is referenced to the ellipsoid; you’ll want to replace this with RelativeAltitude, which is determined by barometer readings between the launch point and UAV position. You also might need to change GPSAltitudeRef to make it above sea level. This can all be done with the following line of code:

system(“exiftool -n -GPSAltitudeRef=0 -tagsFromFile @ -RelativeAltitude>GPSAltitude DJI_0807.JPG”)

NOTE: this will change the altitude to ‘above sea level’ whether it is or isn’t, so if you’re flying in the Dead Sea or somewhere like that, you’ll have to do it differently.

This will substitute RelativeAltitude for GPSAltitude, and in my experience Pix4D and other EXIF readers interpreted this correctly. It’s also possible to run this recursively on folders full of files, for example if for the final argument you use “photos/” (i.e., a folder) instead of “DJI_0807.JPG” (i.e., a file).

I recommend looking over the exiftool documentation if you have problems. Hope this helps someone!


Hey Jeff,

We have a DJI Phantom 3 Pro and are experiencing similar issues.  We have downloaded the ExifTool but cannot seem to figure out how to properly use it.  Is there any part of the documentation that you would recommend really focusing on?  Or would you mind contacting us privately to help resolve our ExifTool issue?


Although the altitude is negative, the error is only related to a vertical shift (negative offset of several meters making the altitude negative). The best solution is to use ground control points (GCPs) to fix it and there are two alternatives if you do not have any. Please find more information in the articles below.

About using GCPs:
If you have issues to mark the GCPs in the rayCloud because of vertical shift:
If you do not have GCPs please refer to:

While I can’t say that my solution will work every time, it absolutely addressed my problem. Using GCPs would be the best solution, especially for SFM, though this isn’t always an option, if for example like me you fly over open water where I can neither place GCPs nor borrow some from satellite imagery, for example. In the final link provided above by Support, “Editing the Image EXIF” is what my approach tackles, though outside Pix4D software using free open-source tools. Support, you may wish to examine my solution as well, and you could possibly make our lives easier by allowing the user to select which tag is used as elevation; that said, this is the fault of DJI, not Pix4D, don’t get me wrong.

As an example, I recently flew a survey at exactly 90 m above the sea surface, which of course should also be ~90 m above sea level. Reading the EXIF tags from one of the images produces a ton of info, which I won’t reproduce in full, but notably includes the following tags referencing altitude/elevation:

Absolute Altitude : +112.19
Relative Altitude : +90.60

GPS Altitude: 112.1 m Above Sea Level

In looking at other images, the discrepancy can be much larger or much smaller, and can also include negative values. Whatever the CAUSE, it’s clear that the “Relative Altitude” is the value relevant for image analysis, and is what we want Pix4D to use; 112.19 is not correct, and would lead to poor results without GCPs.

Through experimentation, it appears that the “GPS Altitude” tag is the one that is read by Pix4D, and is also what reports the altitude if for example you look at image properties in Windows. Therefore, I used the above solution to batch process all images, with the end result of correct altitudes for use in SFM and image analysis.

So, though this solution may not solve all issues, it will certainly solve some of them. Also note that this could change at any time with updated DJI firmware, so take with a grain of salt. Support, I think you should make your developers aware of this, if they aren’t already, as it’s an entirely simple fix to a problem that several seem to be experiencing.

Steve, happy to help, if I can figure out how to contact you… maybe google my name and send me an email?

I  am having bad elevation results that sound a lot like what others have described in this thread.



I have assembled a dropbox folder for a problem I am having with elevation data. Dropbox link is

I have processed images from several different flights into a single Pix4D run, and have specified 5 GCPs after the initial run, where I discovered elevation data that was about 2x the range across the site that it should be. In my area of survey, the 4 lane highway should be about 40 meters above the sea, which is also in my survey. Instead I am seeing elevation of ~80 meters from sea level to highway. I read all the instructions on specifying GCPs, and picked two GCPs at sea level, two on the 4 lane highway, and one other at an intermediate inland point. I referenced a survey done 10 years ago, and took the elevation of those points from that survey (whose .dwg is in the dropbox folder) as the elevations of the GCPs, in meters above sea level. I generally trust the 10yr old survey. Also, I only need +/- 1 meter accuracy in elevation data. Better would be nice, but not necessary. However, the GCP process I followed did not seem to help.

My end goal is land planning view analysis, as shown in this video ( captured from SketchUp animation. Unfortunately the views are overly optimistic because the villas are 2x the height above sea level as they would be in reality.  I have put in dropbox a Word doc with several screen shots from Pix4D desktop. Perhaps these will point out something to you that I am missing.  Should I be using WGS 84, UTM Zone 12N? I see the vertical coordinate system is EGM96, which it says is ~32.8 meters above WGS 84. Does that make sense?


Any help or advice appreciated!




Hi Kelly,

We followed up and replied to your request via our ticket system :).

Had the same issue.

Realised that while the altitude data is shown as positive the EXIF data is showing below Sea level, so on import it becomes negative.

Trying to find a solution


Hi Isaac, 

I recently had a closer look at the EXIF files from a similar case and noticed that the altitude reference is set to “Below sea level”.  DJI probably made a mistake with the reference name which seems to happen from time to time. 
There is a DJI forum post related to this issue:
A consequence is that when Pix4Dmapper reads the geolocation contained in the EXIF, the software is misled and interpret “below” as a negative value. 

At the moment I would recommend you to double check if the drone/camera firmware is up to date since updating to the latest firmware version might solve the issue. Or processing with ground control points (GCPs) in order to fix these uncertainties.
About using GCPs:

You can check this, for example, with the tool exiv2.


Pix4D has provided an EXIF editor tool in their desktop software

essentially, make sure you have a confident number for the absolute take off altitude

export your exif data to file csv

open this into excel

find the correction for your first photograph, and apply the same correction to each photo altitude number

save the new column values over the top of the original column, and delete the wasted data


open EXIF data from file in Pix4D, then import the replacement data

@AP Procurement,

Another quick workaround that might be interesting is to manually change the altitude of the images directly in Pix4D software by following this procedure:

  • In the Image Properties Editor right-click in the Altitude column. This will allow you to change all the values at once with one click.
  • Enter the “corrected” altitude.
  • Run Step 1. 

As a side note, following the above workflow will change all the z-values to the same value. Some precision might be lost but you should still be able to process the project and refine the final position of the project using the GCPs without facing difficulties.  

ah Blaz - I didn’t realize that you could do this from the image properties editor directly - VERY quick

my system would only be necessary when I have combined runs from different batteries / altitude estimates (I LOVE that the DJI machines all use a rubbish vertical datum!)