500' Elevation Variation Recorded for Takeoff from the Same Spot

For the same spot, the takeoff elevation recorded from missions over a 2 week period showed a 500’ variation. This was seen over the period from 10/26/2017 to 11/9/2017 on a DJI Phantom 4 Pro drone. Thus all of the altitudes recorded for all of the missions over this period will show the same 500’ variation.

I have read that DJI estimates the altitude of the P4P from its on-board barometer and my observations are consistent with this. The graph below of the takeoff elevation vs the local barometer reading shows that they are strongly correlated. The actual elevation is 1000’ so the DJI P4P drone is close much of the time.

The barometer range of 0.48" Hg in the graph above is equivalent to a 453’ elevation change and this is in the same ballpark as the 496’ elevation change recorded in the photos.

If the recorded altitude is barometer based, then the P4P should fly very level as the barometric pressure typically varies very little over a 10 min mission. This should lead to very accurate relative elevation measurements in high-quality regions of the map (those with the best overlaps) and my 2D map results are consistent with this; I can see the 1/5" drop per foot carefully built into my driveway over a 124’ distance as shown in the 2 segments below:

Unfortunately the severe variation in the absolute altitude can cause serious problems when trying to add more photos later on in order to improve the map quality. Obviously GCP’s could fix this problem but there is a much simpler first-order fix: Simply add an offset to all measured altitudes so that the start location elevation is always the same. This can be done to the photos before processing but it could be done more easily in DroneDeploy while processing the pictures.

So my ask of the DroneDeploy developers is:
Could you please add an elevation offset option to the form where photos are uploaded and echo its value back on the results form?

Two ways to calculate the offset are:

  1. Offset = Actual Elevation of Takeoff Point - Barometer-based Altitude recorded in the first photo at the takeoff location
    Or after the photos are processed into maps:
  2. Offset = Actual Elevation of Takeoff Point - Measured Elevation of Takeoff Point on 2D map
    Obviously the second way requires double processing of the photos but should be more accurate.

Without correction, adding pictures taken with a significant delay after your primary set may degrade rather than improve the Map quality. At the very least, compare the value of the GPSAltitude in the first photo at the takeoff location for the 2 sets of photos. To check the GPSAltitude you can right-click on the picture, select Properties > Details and scroll down to find GPSAltitude. Or use the exiftool by Phil Harvey.

Remember every time the local barometer reading changes, the recorded elevation of the takeoff location (and all other locations) will change. Each +/-0.01" Hg change in barometer reading causes a -/+10’ change in the recorded takeoff elevation. And most locations see a 1" Hg change over the course of a year. This is a 1000’ variation so beware. My P4P has already recorded a 496’ variation in just a 2 week period!

But maybe other drones are different and do not record an altitude estimated from an on-board barometer. What does your drone do? It would be great to hear about drones that do this better.

We’ll be making some changes soon which use MSL instead of AGL which should address this discrepancy.

Please, what do MSL and AGL stand for? I am new to drones and all its terminology.

Hi @SolarBarn,

MSL is Mean Sea Level and AGL is Above Ground Level.


From what I can tell, the P4P is not recording ANY GPS related altitude information. So changing from AGL to MSL, which can modulate GPS altitude measurements, will not be appropriate for the P4P since it is recording a barometrically derived altitude. Thus the recorded variations will remain unchanged since they are due to atmospheric barometric pressure changes and not GPS related issues.

So can the DroneDeploy development team please add the capability of inputting an elevation offset before uploading pictures for processing?

This way I can eliminate the 500’ elevation variation in the start location (and all other locations because they depend upon the start elevation) and successfully add pictures to improve my maps quality.

The plan is to be using the gps based altitude.

I like your plan very much! But the P4P does not record a GPS based altitude. This drone is the highest quality, lowest cost drone available.

So can the DroneDeploy development team please add the capability of inputting an elevation offset before uploading pictures for processing?

It worked! I have fixed the 500’ absolute elevation error in photos taken by my DJI Phantom 4 Pro drone…

To do this I did a binary read/replace/write to add an offset to the drone-dji:AbsoluteAltitude entry in the Exif data of all the photos for a mission. Correcting the absolute altitude in a few hundred photos (1.6 GB) required a few minutes using a simple 20-line Python program.

The offset was computed in the second way outlined above:
Offset = Actual Elevation of Calibration Point - Measured Elevation of Calibration Point on 2D Map from processing of original, unmodified photos.

After correcting the absolute altitude entries, I processed the modified photos to generate new maps which show really excellent absolute and relative elevation accuracy for 100’s of feet around the calibration point.

Note that when generating maps, DroneDeploy currently uses the drone-dji:AbsoluteAltitude entry stored in the Exif data and not the GPSAltitude entry (though they hold the same values). I wasted considerable time trying to use the GPSAltitude entries. Changing them had no effect on the map elevations. Also note that this could change in the future and may be different for other drones.

This method can be a cheaper and faster way than using GCP’s to improve the absolute elevation accuracy around a calibration point. Its weakness is that, unlike GCP’s, it provide no correction of X,Y location errors. But these are 1/10th to 1/100th as large.

Now even when the weather pushes around the absolute altitude data by 100’s of feet, I have a way of largely correcting this so that I can add pictures taken days or weeks later to improve the map quality. And now I always get to look at real elevation values on my maps. Soooo much nicer.

It would make it very easy for others to correct a systematic offset error in the absolute elevation of their maps if the DroneDeploy developers could add an elevation offset on the page where pictures are uploaded. This has three benefits:

  1. Users and clients get to see more accurate absolute elevations on their maps. And it leaves intact the relative accuracy of elevations. In many of my cases, the accuracy is 10 to 100 times better.
  2. It allows a way to ensure that the elevation baseline is the same for pictures later added to improve the map quality. This way the added pictures are more likely to improve rather than degrade map quality.
  3. It does not involve the use of GCP’s. GCP’s are a much better choice but also have more overhead. This method is like creating your own GCP for elevation improvement after the fact. You just pick a point you want to use for your elevation baseline, measure it on your map to create an offset (= known elevation - measure elevation) and input this when you upload your pictures to get a new map with much better absolute elevation values.

One last note: The offset needs to be in meters not feet, at least for pictures taken with the DJI Phantom 4 Pro drone and possibly for many others.

What are others seeing for the absolute elevation variation in your maps of the same location taken on different dates?

Hi @SolarBarn

When the drone is turned on it takes a GPS snapshot of it’s home location. This is then used in case the RTH needs to be initiated during the mission. Once the drone has taken off it uses the GPS as well as barometric pressure to understand its relative altitude to the home location.

As Chase indicated we are moving towards using the GPS based altitude so that you can reference MSL within the map rather than AGL without using GCPs. That being said the relative altitude which will be referenced in the future will potentially be around 10m off. So GCPs will still be your best bet for any type of civil engineering or survey type of job.

I’m glad you were able to figure out a solution to your issue. We will be working on a solution for this issue moving forward. Please let us know if you have any questions moving forward.


The P4P seems to use GPS only for horizontal positioning. If it used even a bit of GPS for altitude control, then I would not be seeing 500’ change in the elevation of the takeoff point (and all the altitude data recorded in the pictures) which mostly tracks the barometric pressure.

My observations make what you say about using GPS as well as barometric pressure for altitude calculations seem doubtful. But I know very little about drones and DJI’s P4P design details. Heck, I have only been looking at drones for a month. So I have lots to learn.

I see you want to move toward using the GPS-based altitude but how are you going to get the GPS altitude from the pictures taken by a P4P drone? I do not see it recorded in the Exif data of the pictures. There is a GPSAltitude entry but it is just a copy of the DJI AbsoluteAltitude entry which seems based strongly, if not entirely, on the barometer so it contains 500’ variations. Does DJI’s SDK allow you to control what is recorded in the Exif data of a picture? If so and you start recording the GPS altitude, then the pictures are going to pick up all its random altitude variation unless you do some kind of averaging of just the GPS altitude readings across the mission. This may considerably degrade picture processing to generate maps compared to what is done now. Currently I am seeing altitude data on calm days that is flat within +/-10 cm across 17 acres. This starts to get in the ballpark of what an RTK-equipped drone can achieve.

A hybrid system is possible which would eliminate much of the barometer-based altitude variation that can occur between missions. This could be done by letting the drone sit on the ground for a bit in order to average out most of the GPS altitude noise, then subtracting from this the barometer-based altitude reading while on the ground to create an offset. Then the mission is flown using only the barometer-based altitude to keep the drone level, while the offset is added to the barometer-based altitude before being stored in a picture. This essentially records the Ground GPS Altitude + Barometer-based Altitude - the Barometer-based Altitude at Ground. Since the difference in the barometer-based altitudes is not very sensitive to the absolute altitude over a range of 1000’s of feet, this may work reasonably well. I do have a concern that a scale factor as well as an offset may be required to adjust the barometer-based altitude in order to get the best result. I am now researching this.

The DJI engineers were clever when they chose the barometer to control the P4P altitude. It probably provides 10 times better accuracy than GPS for level flying and recorded altitude. It is lousy for absolute elevation accuracy, which I know, and have fixed. Please do not hurt my baby (current P4P drone + wonderful DroneDeploy + my easy fix for the elevation variation). I am so thrilled that the combination can work so well together. Of course if someone were to give me an RTK-equipped drone, then I would be even happier. And then I can have my cake and eat it too; cm-level accuracy for x,y,z with no GCP’s.


Hi Terry,

First, thanks for the detailed investigation and for posting on the forum - really interesting observations!

Currently we base the elevation for processing on the “RelativeAltitude” field in the exif data, which is based on the difference in barometric pressure from the takeoff location (so changing takeoff location will affect the “elevation” of each image for a subsequent flight). As mentioned by others in this thread, we are planning on moving towards using the “GPSAltitude” field instead, to try and achieve the MSL elevation for all maps as default. We are also planning on adding the ability for users to specify a “zero point” to reset the model elevation, which is hopefully close to what you were requesting.

I would like to dig in deeper to the elevation discrepancies you have documented to fully understand the situation - could you PM me the map ids (or even names) so I can dig through some of the data on my end as well?




Thanks for your informative reply.

First let me try to make clearer what I have previously said:

The large variations I have been seeing in the absolute elevation printed out for a DD Location Annotation are for missions flown on different dates. They are not within one mission. I am finding that the map from one mission has very realistic values for the relative elevations of the hard surfaces in my maps (buildings, concrete, brick and other surfaces with significant texture). The values I have checked appear to have 2-cm level accuracy. These mission were flown on calm days with no weather change occurring. The barometric pressure was probably constant to better than 0.001" Hg during the mission. This corresponds to less than 1’ of elevation variation. Thus the P4P should have flown very level and recorded RelativeAltitude values with small variation and this is what it did. My Nov3Big map is an example. In it the RelativeAltitude is 90.90=/-0.1 m or flat to within 10 cm or 4".

So while I understand the RelativeAltitude field in the Exif data is used for processing the pictures into maps, the AbsoluteAltitude field is also used when printing out the Elevation part of a DD Location annotation. Thus when I change the AbsoluteAltitude field by adding a fixed offset to this field in all the pictures of a mission, the reported Elevation changes.

As I am sure you understand for the P4P, the GPSAltitude field is simply a copy of the AbsoluteAltitude field and does not contain GPS information. So I am not following how the use of this field is going to help achieve MSL elevation for all maps. Are you going to change what is recorded in this field so that it contains the actual GPS altitude data which can have 10 m inaccuracy? Some where I am getting lost.

Yes, the Zero Point you mention is what I want. Will this do exactly what I am doing by adding an offset to all the pictures’ AbsoluteAltitude field? My zero point is on a concrete patio and is set to 1000’ (based upon Google maps and topo maps and GPS readings).

So if you followed my explanation above, then you can see there are no elevation discrepancies. The elevation reported on a map is simply a reflection of the barometric pressure. Since the barometric pressure can vary by over 1" Hg in a year, the elevation can change by 1000’. Obviously you are only going to see this much variation if you happened to fly missions on the days with the lowest and highest barometric pressure. On the other hand, the relative elevations on a map are immune to this 1000’ variation.

Now that I have a better comprehension of how DD processes picture, it makes me believe that I should not worry about adding pictures from later missions using the same take off location. Since all maps are generated using the RelativeAltitude field, a 1000’ difference in the absolute altitude should not have an impact, right? And the map quality should improve. If this is true, then the only detail left in my mind is what AbsoluteAltitude will be used when printing out the value of the elevation in a DD Location Annotation? Is it that of the original map? Then the pictures for these are the ones I should change in order to see a real elevation value.


Hi Terry,

I meant could you PM the ids of a couple of maps that have an altitude discrepancy from one map to the next so I can check out the details of the exifdata for example images from each one.




I tried to put the information you are looking for in my post below.

In Bldg3DMapping the elevation measured with DD Location Annotation is 999’ at my takeoff point while in Copy of Bldg3DMapping it is at 695’. And in Nov1Grid it is at 1025.6’.

These cover 331’ of the 496’ I have seen. The other missions do not include the takeoff point in the map so I have to go back thru my 1200 pictures to find the ones which show the higher elevation of the takeoff point which would bring the variation of up 496’. I often do not include the first photo of a mission when I upload the photos because I am worried about degrading the map quality. So you may not find it in the 3 missions I called out above.

But you should get the idea from these 3 missions and you can measure them yourself. The takeoff point is where the only Location Annotation is located in the Bldg3DMapping missions.

You can also generate your own data with a P4P drone and smartphone Barometer App (I suggest Barometer Plus in the PlayStore). Just put the P4P in a fixed location and record the barometer reading when you snap a picture. Then plot the AbsoluteAltitude from the picture vs the Barometer reading from the App. You will see that it moves around with the barometer. You need to do this at a time when the Barometer is changing by more than 0.1" over a few hours. This will give over a 100’ change in the recorded AbsoluteAltitude in the Exif data. And I know from my experience, once the AbsoluteAltitude value changes, the elevation reported in the Location Annotation will also change.

Below is a graph I generated today over an 8 hour period when the weather was changing a bit. I saw a 0.151" Hg pressure change which the P4P thought changed the AbsoluteAltitude by 132’. All the while the P4P sat at a fixed location with constant elevation. Many P4P users may never see this magnitude of change in the AbsoluteAltitude as they probably fly on days with calm weather when the barometric pressure is nominal (around 30" Hg and sea-level and 29" Hg at my 1000’ elevation). Only missions flown when there is a significant difference in the barometric pressure will show an elevation variation larger that what you would expect from a GPS measured altitude. So most pilots probably chalk up the variation as not significant. And pilots flying with GCP’s will probably not see any of this issue.


thanks again for all the detailed investigation and info! this is hugely helpful in planning our updates to the map flight altitude I mentioned previously. we’ll keep you updated on progress with the user-defined elevation that you suggested as hopefully that provides enough flexibility for your workflow.


I did another test of how the AbsoluteAltitude impacts DD results. For this test, I uploaded the same set of pictures twice; the first set was at 386.26 m (1267.25’) in absolute altitude while the second set was set to be at 505.58 m (1658.72’) in absolute altitude or 391.47’ higher. Compared to processing the first set alone, the results are much worse. Even though the two cases have exactly the same RelativeAltitude data, the results for the second case with offset, duplicate pictures have holes in the 2D map and a tilt in the cross-section shown for a Length Annotation. Also the elevation reported for the second case is 391.47’ higher, matching the offset of the two sets of pictures.

Some comparisons of the results are shown below:

2D Map Result with First Set Alone:

2D Map Result for Duplicate Set with Second Set Offset 391.47’ in Absolute Altitude. The map has holes.

Cross-Section thru Building for First Set Alone Matches Real Data:

Cross-Section thru Building for Duplicate Set with Second Set Offset 391.47’ in Absolute Altitude. Now the cross-section has a tilt and values that are too high by 391.47’ = offset of second set of pictures.

Thus it appears to be important to have correct values for the AbsoluteAltitude recorded in pictures. Even if the RelativeAltitude data is the same, the resulting maps will not be accurate and may have holes if the AbsoluteAltitude data is off.

So when adding pictures taken later, when the barometric pressure could be different, it is critical to ensure that the relative AbsoluteAltitude data of the pictures being added is accurate. In other words, any difference in this data should be due to a real difference in altitude and not due to a random variation introduced by a different barometric pressure. This can be achieved by (1) making a 2D map with the second set alone, (2) measuring the elevation of the takeoff point and (3) adding an offset = Measured Elevation of Takeoff Point in First Set of Pictures - Measured Elevation of Takeoff Point in Second Set of Pictures to the AbsoluteAltitude data in all the pictures of the second set of pictures before processing the pictures together.

Are you aware of this? Are any DD users aware of this?

I will be doing additional research to investigate what happens when I add a set of pictures to itself with no offset. Hopefully this will result in the same out come as processing a single set of the pictures.

On another note, you do not want to know what I discovered about the P4P with respect to its AbsoluteAltitude data. But I will tell you anyway. If the P4P sets at a fixed location while the barometric pressure changes, the recorded value of the AbsoluteAltitude data remains the same within a 1’ range even though the barometric pressure changes enough to cause the altitude to change by 25’. On the other hand, if you move the P4P to different elevations, then the changes in the barometric pressure do show up in the AbsoluteAltitude data. Apparently this is yet another level of cleverness that the DJI engineers poured into the P4P in order to maintain a stable altitude. Think about it, say the P4P is hovering or flying at a fixed altitude as registered by the IMU and the barometric pressure changes. Should the P4P change altitude? Ideally not. And it does not since the IMU, seeing no change in the vertical position (which would require a vertical acceleration it can detect), tells the AbsoluteAltitude calculation to reset its reference altitude to the new barometric altitude. Presto, the P4P stays at the same altitude and the recorded AbsoluteAltitude remains the same. Spooky. Maybe there are even more secrets to be uncovered but this is what I have found so far.


All drones do this, not just the Phantom.
GPS is useless for accuracy in altitude, but GPS altitude is recorded in the Exif info for each image.
This pic shows why: Phantom 4 pro - Above & Beyond Photography
I’m pretty sure my drone was not flying at minus 18 metres above sea level.