Elevation readout or click-for-elevation

With the addition of volume measurement, DroneDeploy is becoming a great tool. However, a simple way to set and display elevations would greatly improve its usefulness.

From what I’ve seen, on a Pro account, there is a legend on the left side showing colors for different elevations. These appear to be relative to the takeoff point. Here is what would be really handy: You could click on a known point on the map, and set the elevation to, let’s say, 1685 feet. Then all other locations on the map would display their actual elevation. This would be either a real-time readout, or a click would show you the elevation at a location.

Is this a possibility? I believe you can get actual elevation readouts using GCPs, but I’m talking about a quick and easy way to show approximate elevations.

1 Like

Thanks for the feedback.

We’ll use this in our next generation of our interface.

Are you looking for the elevation for just a point - i.e. drop a marker see the elevation? Or are contours what you’d want?

The idea to set elevation sounds quite interesting.

1 Like

Contours would be great, of course. But I’m talking about (I think) a simple functionality change since the data are already there. Just click a point and have it tell you the elevation. My understanding is that the elevation relative to a known point is already in there. Combine that with the known elevation that you supply for a single point, and this would be a quick way to get non-precision elevations.

This would be a great idea, especially if you could also view elevation above sea level at the same point.

Continuing the discussion from Elevation readout or click-for-elevation:

Continuing the discussion from Elevation readout or click-for-elevation:

Count me in on a desire for both an MSL elevation function and contour lines. We have a definite need for 2’ (yes, 2 foot) contour lines.

1 Like

Thanks Guys. Good to know. Elevation by point and Contours are both on the roadmap. I’ll bring this thread back up as we get closer to them.



Would be amazing to see such a feature!

Sorry I may be a bit late to the party but was there any movement in offering contour lines? I assume in terms of providing this data as an export the file would have to be a ‘shape’ file?
Thanks in advance,

Hi @cmoorec - no update yet on this.



I’d also love to see a contour feature added. Also being able to download a geotiff with the contours already overlayed (with annotations) would be icing on da cake. :smiley: Thanks in advance.

Hi All

We released the click-for-elevation feature. Check out the blog post: https://blog.dronedeploy.com/new-elevation-and-volume-tools-for-mining-and-construction-89e798b7e1a8#.auy9hutt4

The new elevation export will enable easier creation of contours in other software … but keep a look out for contours on DD in the future.


1 Like


Tested the new click-for-altitude feature today. We use a small, white portable table for launch. Because it’s white, it’s also easy to find on the orthomosaic. Clicking on the table yields an altitude of -21.89 ft. Either I’m doing something wrong or the feature isn’t anywhere close to accurate…

What does it say is the accuracy of your map? Is it possible that is due to that?

I’ve made further elevation accuracy tests recently. Taking off from a known spot on level ground (in a large level parking lot) and then going back to check the takeoff elevation after processing yields about -5’ instead of 0’. Since the takeoff point is in a large level area, I’d imagine that the map accuracy doesn’t come into play here. Is anyone out there getting better results than this? Worse?

Has anyone tested the accuracy of elevation differential within a map? In other words, if you take off from ground level next to a building with a known height of 100’, what elevation differential do you show between takeoff and the top of the building after the orthomosaic is produced? If your takeoff point reads -5’ and the top of the building reads 95’, that’s something we can work with, just add 5’ bias to all measurements. If the top of the 100’ building reads 80’, that’s something else entirely.

It’s certainly not productive to advertise an ability to measure elevations to customers and then discover the measurements are inaccurate.

What accuracy readings are the rest of you seeing???

I’ll look at some of my maps tomorrow I’m currently processing 50 or so fresh flights all with known take off points and manual gcp’s via laser transit to check this very thing. I ran into a huge problem with a couple flights in that the entire map was shifted in elevation. For example 3 points on the left were all reading same elevation as they were in real life. Center gcp were showing rise of 3-5 ft depending on which flight, and the right side gcp were showing elevations of 5-10ft. Again depending on the flight. In real life, only one map was accurate. But oddly enough, the volume measurements (which were the primary goal) came out almost exactly the same on all 3 maps. I’ll get some screen shots to show examples tomorrow.

Great, thanks. Next week we’re going to do some tests using some suggestions which Zack, from DD passed along. The suggestions were, “lower flight altitude and higher overlap”.

My concern is that it would be a very bad idea to sell a job based on an ability to read elevations from the orthomosaic and then see the large fluctuations that we’re presently seeing from our experience. A customer isn’t going to remain a customer for very long if we can’t deliver accurate readings.

We’ve completed our testing of the elevation feature with disappointing results. To be perfectly clear, we did NOT use GCP’s.

My flying buddy and I own 3 identical Phantom 3 Professionals. Repeatedly flying the same same flight from cloned DD missions on all 3 copters gave wildly divergent elevation results both at our (marked) take off point elevation and measurements of the height of a building which we had pre-measured with a laser rangefinder. Furthermore, repeating the same flight on the same day with the same copter also gave wildly divergent results. As a final test, I re-uploaded the pictures from one of the flights to create a second map with the identical pictures. The elevation readings for the second map were very different from the readings from the first map!

Neema suggested we to a “tiered” flight at 50 meters and 100 meters. This didn’t yield any better results.

So, In my opinion, the elevation feature is unusable without the use of GCP’s. I’ve requested DD’s results of their tests from Neema, but have received nothing.

Getting the equipment to do a GCP mission is very expensive simply to do a test. Does anyone out there have any results they can share from a GCP mission?? Has anyone out there been able to get any kind of accuracy without GCP’s. If so, I’d sure like to hear how you did it.


I see the same differences in elevation I believe. Taking off from the same spot will not consistently give me elevation values that are the same. I actually just finished up flying the monthly data set on those 50 sites and can give some examples to what you were experiencing with elevation troubles in regards to take off points. As far as map consistency, I’ll have that data processed shortly. One example to which I can attest to DD accuracy is a survey I did recently of an lake which the water level had been dropped for some dam maintenance. The entire water line on the map was within a couple inches of being the same elevation on the map

1 Like

This spot is my take-off point. Yah, I thought it was supposed to read ‘0’.
@Nexus, if I’m reading that correct, the map is accurate within itself (a couple inches here or there…), which is fine for my application.
@jlindh, next time I’m out and about I’ll try some GCP’s just to check the differences and will let you know on this thread.