Collecting accurate elevation data and exporting contours


Under my account you will see a mission entitled “Crown Lane”. It was uploaded to the cloud on Friday evening and completed processing late on Saturday night. Whereas it did seem to take an eternity to process (over 24 hours), I’m also having a large problem with it.

Being on Business obviously provides the ability to view and export at a much higher resolution as well as upload a greater number of images, but the biggest draw of the Business account is the ability to export contours from the Elevation Toolbox. The results of this mission however are not giving me confidence they’ve been calculated correctly. Same goes for the standard elevation colours. Ground Control Points were not inserted as the data didn’t have to be relative to the outside world, just be in proportion with itself.

You will see from the aerial image that a large car park deck (painted green, grey and red) has been photographed along with a building running left to right to the south of the car park. Both the car park and the flat roof of the building are perfectly flat / horizontal.

You will see however that both the car park and the flat roof is shown in Drone Deploy to have a significant fall on it, which is clearly incorrect. In measuring across the flat car park deck, DD has calculated it to have a 2m fall across it.

And the length of the flat roofed building is shown to have a 3.5-4m fall on it

Neither of these roofs are sloped as the contours suggest and none of the surrounding ground has a fall on it either. The site is flat.

Both the roofs and the ground are flat. We do have a measured topographical survey to compare with and the DD calculations are undoubtedly wrong. Please can you advise what has caused DD to incorrectly assume the world is falling to the left?

One other thing, when measuring the width of the car park deck, it actually measures 32m in real ife and the on-screen measuring tool more or less confirms this at 31.76m. Close enough and am very impressed by this accuracy. When exporting to AutoCAD dxf file, I can’t understand why I am unable to measure accurately from the model. The width of the deck is measuring 52m or so. These are the export selections I am making.

All I need is a 2d AutoCAD file to scale and with the correct contours on it.

Many thanks in advance.


Hi James.

Unfortunately dji drones introduce this problem in the flight capturing the images. The craft actually looses a bit of altitude as it flies the track but records a constant altitude to the exif data in the images. The result is what you have there. It is not necessarily Drone Deploys fault. But it is constant and with some testing they could possibly insert some correction for it.


Hi Dave. Thanks for chipping in.

So as the drone gradually drops in level, the flat roofs are recorded to be closer to the drone and therefore are perceived to be taller than they actually are?

Because of the ridiculously low height I was surveying at, DD automatically flew the drone at 1m/s. This in turn extended the length of the flight and forced the drone to fall further. What is interesting however, is that the change in battery isn’t recorded as presumably that would have reset the drone to its originally intended height? Still, 5m drop over perhaps an 80m stretch is massive. I can’t believe the drone fell by that amount. Not 5+ metres. The image below shows a stretch of road in front of the building falling from east to west by 4.71m in DD where in fact it actually rises 0.5m from east to west on the measured topo survey.

So how do I rectify this going forward? DD is controlling the drone, if it knows DJI’s equipment is falling gradually, can it not either counter it by lifting the drone or as you say, correct the data to reflect the results it produces? This is a fundamental flaw. Or are we saying that those levels recorded with a DJI drone aren’t to be considered at all accurate unless using GCPs to correct the data? This could potentially kill it for me?

In order for DD (or other) to become a viable option for me, I need to be able to produce a semi-accurate survey of the site - providing a site area and a crude z-axis fall across the site.

Thanks again for your help.



Did you record the barometric pressure during the flight of the RTK-equiped drone? Most DJI drones use a barometer to control altitude so your results would imply that there is an error in this process. I record barometric pressure during my missions with the Barometer Plus app on my Note 8 phone. It shows barometric pressure changes as small as 0.001" Hg which is equivalent to about 1’ elevation change. I wager my DJI P4P has a similar barometer. So your results showing a 5 m or 16’ or 0.016" Hg variation in altitude should easily be detected by a P4P.

The results of my missions of the same 17 acres site flown on overcast days at 300’ altitude above takeoff point with low wind (<4 mph), at a low speed (9 mph) with 18 min duration and 9 passes of 1200’ in an E-W direction show less than 3" altitude error over a 150’ N-S distance. This should be in the worst-case direction for showing the type of error you see since the mission starts from the South and then zig-zags it way North. So a P4P can produce DD maps with very good relative elevation results. Its barometer-based altitude control can work well with only 1’ Z error in the total RMSE of 6.2’ reported by DroneDeploy. The barometer recording for this mission showed less than 0.002" change.

That being said, poor results have also occurred with 1 m elevation error over the 150’ distance. This error consistently shows a rise from South to North. And the poor results consistently happen on missions flown when the sun is out, like the mission shown by JamesC. But the barometer change was still small, in the 0.001" range.

So both outcomes are possible. I suggest JamesC re-fly the mission on an overcast day with low wind at a low speed at 300’ altitude and compare those results.

Does the P4P gradually warm on sunny days and cause a barometer drift that causes an altitude drift?



Use ground control points.


Hi @JamesC,

As @Dave mentioned this is normal behavior to have with the onboard Baro pressure sensor. The drone also uses GPS altitude. Because of this, you could see an increased accuracy within your maps on a local level by carrying out a compass calibration before the mission. Generally, you can expect to see 1-3% of the resolution within the orthomosaic. This can be seen in your linear measurement of 32m vs 31.76m. When importing the file into AutoCAD make sure that you are using the same projection as the project you are comparing the file to. GCPs would correct for this inconsistency within the map. Please let me know if you have any questions moving forward.



Hi Zach

I am very concerned that a height difference of 5m has been recorded by DD when in fact there should be nil. This issue more or less makes the elevational side of DD redundant for me, leaving just an orthomosaic export. As previously expressed, it is critical for me that I am able to carry out this initial survey without any further equipment. If I were to convince my employer to purchase further equipment to help the software correct the rise in pressure or drop in altitude of the drone, paying an additional $49 per map is out of the question.

So that I can understand Dave’s comments, are we saying the drone has literally dropped 5m out of the sky from beginning to fly a DD mission to the end? It was set to fly at 25m above the flat ground level. I took off 3m above ground level and so had the mission fly at 22m. Are we saying that over the course of the entire mission the drone ended up at just 17m above take off level?

If the theory of it dropping 5m is correct, why don’t we see a reset of height when the battery was swapped out? Surely when the mission continues it would have elevated to the actual 22m again?

Could there be anything else responsible for the inaccuracy? Does the overcast day vs sun/shadows have such a dramatic effect (thanks Terry)? I would say there were enough flat areas consistently measured wrong for me to consider the light had little impact. But then I am a novice and would want this to work if it could. Happy to try again. :slight_smile:

My company were on the cusp of placing an order for a Business account and it is extremely disappointing to learn that the software is not able to do what we understood without further equipment.

Kind regards, James.



A quick test I have done to check how well my P4P maintains altitude is to have it hover at a height above its sonar sensor range (above 30’) but low enough that I can see a tree top just behind it. Then I wait. We know it must move around horizontally due to GPS variations (3m or so) and vertically due to barometer/IMU variations/barometric variations. I can record the barometric variations so this just leaves the barometer & IMU as the source of vertical error. Last time I did this experiment over a 10 minute period, it moved down about 3’ in height.

I will do the experiment again tomorrow (weather permitting) and carefully record the results over a 20 minute period (including distance to reference tree and angle to top and to the lowest fall point of the P4P). Then with some simple trig, I can get a pretty good estimate of the drop over time. I will check the barometric pressure change during the 20 minutes and see if it could be a contributing factor. I will also try to get a direct reading of the P4P altitude with my Leica laser measure.

You could try this test yourself. I too will find it remarkable if the P4P does fall by 5m over a 15 minute period when the barometric pressure is relatively constant.



Hi guys,

The report I shared was not my data, and it was using a P4, not a P4P. The actual heights were recorded with an Emlid Reach precision gnss receiver mounted on the P4. The fellow told me that this was not unique but usual in his experience. I don’t know if the P4P’s barometer is more accurate but I’m guessing its the same hardware. I have a P4P and will be fitting an Reach module to it and will be able to add my own data then.



If I’m understanding your test, you are hovering in one location? If that is correct, I’m not sure you will get the same result as when the p4p is flying forward. Anecdotally, I have seen the p4p loose altitude in forward flight at eye level with VPS disabled to simulate being at higher altitude than VPS range. Let us know how it goes.


Thank you both for your input.

To clarify however, I am using a Mavic Pro. It was initially bought by me as a bit of fun but I soon discovered what it could do to help me in my work place and have been pushing hard to convince my company to accept it. It’s very early days but once it’s proved its worth, the company will invest in more sophisticated equipment.

The problem I have now is that in trialing the contour functionality, it has thrown up a massive problem for me and one I fear will not be resolvable without introducing GCPs. Maybe in experimenting I am able to work out its quirks and compensate for them, but that isn’t going to be possible within the period of time DD have given me to trial it and it is not going to be possible to convince my company to purchase the software if it can’t produce what we need.

Terry, that’s not a bad idea although wonder if Dave has a point and so maybe I could test this by simply flying backwards and forwards over a field for 20 minutes and triangulate its height at the beginning and the end. Is that confirmed then, in that the drone is believed to have physically dropped by a possible 5m during its flight?


Hi @JamesC,

I’ve gone ahead and had my teammate extend your trial for another 2 weeks as a courtesy so you can play around with the product a bit longer. Your trial will now end on January 23.




I did not get to redo the simple hovering experiment with my P4P today. But I did get my hot water heater working. For $1, I got a new, better surge protector to repair the blower motor. Saved me $1200. More for drones? One can hope.

I did come up with something for our drones though. I put 1/4’ contour lines (yes, that’s only 3" separation) on a 3D 17-acres model exported from DD and found good results ( be sure to Click on Map to make it full screen in order to see more details as uploading to the Forum loses some of the details):

Looks pretty busy but here are the highlights:

  1. North is up. The P4P flew W-E over the building which is 125’ long N to S. It took 4 passes to cover the building. Each pass takes 2 minutes. These passes are in the second half of the mission where, from Dave’s data, there may be less altitude sagging compared to the first half.
  2. The contours around the roof of the building are quite uniform. They show sub-inch noise and clearly show the upper roof (blue background) with a 6-pitch roof is steeper than the lower 4-pitch roofs.
  3. The contours on the flat roof (pink, on the West side, enclosed by grey railing, next to blue upper roof) show the expected slope; away from the building and away from the West-most portion of the railing. Its hard for DD to get this perfect as the 4’ tall railings shield much of the area. Missions at much lower altitude look better as expected.
  4. The contours on the circular driveway with raised center, located immediately to SW of building, show 3" drop over 12’ distance or 1/4" per foot as confirmed by on-site measurement.
  5. The contours on the 300’ curving stretch of driveway which first runs West from the North end of the building and then turns SW, generally show a 1/4" per foot slope that steepens to 1/2" per foot as it runs SW past the large tree (with solid-looking grey contours). Again these values were confirmed by on-site measurements. Those with access to DD contour data may see better results as that data may have more resolution that the 3D model which I can export.

I think this result is quite remarkable. These are 3" contours on a map from a mission flown at 300’ on an overcast day with low winds at 9 mph. If the P4P is drifting down, it does not seem to have much of an impact. I was astounded that a P4P with DroneDeploy photogrammetry could produce such a result.

I now see that I need to re-fly the mission in the opposite direction in order to put more of the potentially larger-sagging altitude portion over the building. I can also do a differential between the two maps to see if a trend is apparent.

This is not the result I get with missions flown on sunny days. For those I see a up to a 6’ rise from South to North on this portion of the map. I need to dig up that model and detail the contours for that case. I will work on this next.



Thanks @Christina. Much appreciated. I hope it is recognised by your team that I really am trying to make it work and not messing around. I honestly thought we had ironed out the issues and was about to place the order, but these new relatively important issues that have just come to light are show stoppers if we can’t find a workaround.

I’m looking at your image @SolarBarn Terry and wishing I had received similar results. What you have there I would be over the moon with. The contours running along the roof pitches are uniform and parallel with the ridge/gutter. Very very good.

This is my roof from another map. In trying to understand how to mitigate the ‘sagging effect’ Dave mentioned I unfortunately then learnt of the bowl effect. The contours are at 0.25m centres.

The roof is in fact double pitch, with the ridge being horizontal, not having a 2.25m fall on it.

Below is the wider site. I got hit hard, throwing the site’s elevation data out by several metres. Whereas it is possible the sagging affect found its way into this map, it going to be difficult to prove due to the extent of the ‘bowling affect’. The drone’s direction of flight was parallel with the ridges and which would have been covered in a couple of passes, just after a change in direction. The images would have been taken within a minute of each other.

The image below is at 1m contours.

With DD’s generosity, I am currently running the process again whilst including the GCP data this time. It’s lucky I put the GCP tiles down on the ground over the existing survey nails at the time the drone flew its mission. It will be interesting to compare the two results using the identical images.

I’m wondering whether to go back out to the car park site to take some oblique images, or is it too late? Do the oblique images need to be taken at the same time of day with the same atmospheric pressures and gps locks? Does the drone have to be at the identical height? Which height? The actual 22m it was set at or the 17m it possibly dropped to?

Failing that, take the GCPs and start again.

Thanks all.


Okay, results are in…

The same quarry site was processed using GCP data and I am pleasantly relieved that the closer to the truth has been recorded than the horrendous lie it gave last time.

The double pitched roof has more or less parallel contours that reflect the same horizontal line of the ridge:-

…and I don’t have anywhere near as much of the bowl effect I had before:-

I’ve entered the surveyed GCP data and although the measurements given from the processed DD image are different, they are proportionate to the levels I gave. You will also see that 7no. GCPs were used and I measured 4no. points on 2no. roofs also. These areas were not so accurate unfortunately. The shorter flat roof was out by 1.265m and the double pitched roof was out by 1.7m.

The drone’s path started in the SW corner of the map and flew east before returning west and making its way north so I wouldn’t have expected the drone to have suffered that much sagging at this point so I can only put it down to an inaccuracy in how the data has been processed. I dare say had I have climbed up onto the roofs and pinned a marker there those points would also have tied in as the GCPs, but that’s obviously impractical.

Due to the nature of the site, only those GCPs I’ve shown were able to be located and it’s interesting to see that beyond them, the bowling affect starts to take place again, suggesting the surrounding land falls dramatically away to the east, which it doesn’t. The road out to the east is almost flat but according to DD it has an 8m fall on it.

It’s obvious that DD requires GCPs to be used for its elevation data to be considered remotely accurately, but it is disappointing to find that despite entering GCP data around the buildings, it’s still managed to introduce discrepancies of up to 1.7m. The discrepancies appear to increase the greater the height from the nearby GCP.

With regards to the difference in measured levels, GCP1 was measured at 24.745 and despite entering that when tagging the GCP and despite entering the correct EPSG of 27700 and exporting as such, the same point has been determined at 71.65m by DD. I’m assuming it’s me not using the correct export settings?



You are having quite a challenge. Even GCP’s did not fully rectify the issues. My recommendation is still to fly the same mission on an overcast day. My missions on sunny days are consistently off by 1 m in elevation over a 30 m distance. Not as bad as what you are seeing, but definitely worse than missions on overcast days.

One caution: it is especially important to fly at a low speed on overcast days as the shutter speed will be much slower. The shutter speed on my last mission flown at 9 mph or 4 mps was 1/60 sec. So the camera moved 6.7 cm during an exposure. While this creates a little blur in the direction of travel (up on photo below), it is not very noticeable:

Using all default and automatic setting (except overlap set at 80% front & side), the prior mission was flown at 15 mph or 6.7 mps resulting in 11.2 cm camera movement during an exposure. This made noticeably blurry photos which I did not process.

The much more uniform lighting on overcast days seems to significantly help DroneDeploy create more accurate maps.



Thanks @SolarBarn.

Please can you help me by confirming how the flight speed can be determined? I always thought this was automatically set by DD.

I do need to get my head around exposure vs speed.

@Christina, @zach1, please can you explain what I have done wrong with regards to the elevation data datum being off? As mentioned above, I input the correct British Ordnance data levels for the GCPs, use the correct 27700 EPSG and yet those levels given by DD in the processed image are some way off.

For example, GCP1 was measured at 24.745, input as 24.745 and the image was processed using the correct EPSG of 27700, but for some reason DD has determined the same GCP to be at 71.65m by DD. Can this be corrected so that the DD measurement reflects the same GCP level? They are all more or less in proportion with each other but the datum needs to be corrected.




The maximum flight speed will be automatically set by DroneDeploy unless you reduce the maximum value in the Advanced planning menu. This can be accessed from the panel that appears when you are setting the area for your mission. On this panel touch the down / symbol to bring up the Advanced menu as shown below:

You can see I have the Max Flight Speed set to 9 mph. I have had good results using automatic focusing and exposure (selected in DJI Go App) and so I do not select the Set Exposure or Set Focus Manually options near the bottom of the Advanced panel. And orbiting at the End of Mission will just drain my battery and not help my tree mapping. Besides, I think this option is going away.

Once the Max Flight Speed has been reduced, DroneDeploy will not fly any faster than this but it could fly slower if required due to light conditions. The advice on the form “Only reduce if flying in low light” applies to my missions which are flown on overcast days. So I reduce the speed and DroneDeploy could reduce it further if the light is bad. But if that happens, then the mission will probably take so long a battery change would be required and I have avoided that so far.

I think the combination of flying low in sunlight is contributing to the problem. A mission at 300’ above takeoff point on an overcast days may give you much better results. And as you can see from my results, the resolution can still be good.

Hope this helps.



Hello @JamesC,

@SolarBarn Thank you for your answer to Jame’s flight speed question. You are correct in that DroneDeploy sets the max speed of the flight. The drone will not fly faster than this set speed. However, it will fly at a slower speed (slowing down for turns for example).

As far as your elevation values being off, @zach1 will be reaching out in regards to that.

Thank you!



Thanks again both.

I was aware of the speed limiter toggle but never had any reas9n to use it. At either 50m or 60m altitude, the fastest the drone has flown at is 5m/s. S9metimes 3m/s and when the altitude has been reduced to 25m to hopefully obtain high res images, 1m/s. I’m assuming the higher the drone the faster it is happy to fly at at given the amount of blur will be reduced.

Even with the quarry flight, that was a reasonably bright day and the drone definitely flew at 5m/s. This was using automatic focus and exposure.