Volumes based on differing terrain

I’m running LITE version of DroneDeploy (if that makes a difference)
We have an area of disturbed ground from which we will be extracting clay. I’ve flown a before mission (attached pic), but am wondering if an after comparison of the terrain would be able to approximate a volume extracted.
My thought would be to initially calculate a ‘volume’ of the site in its entirety - just to have an arbitrary number - and then, upon project completion, fly another mission; replicate the size/shape of the original volume, and compare these two numbers…


Are you using GCP’s? Or an RTK/PPK drone?

nope - Phantom 4 Pro v2 or a Mavic Air

In that case, you’ll need to make sure that drone deploys auto alignment from the previous map is working. Even if that does work, your best relative elevations are going to be plus or minus 1-2ft. This is probably good enough to get a rough quantity, but you could be several trucks off even if you flew twice the same day without any work.

That accuracy is what I would expect, as long as it is relative to itself; I will also have a load count, but of course that would include the material ‘fluff factor’ once in the truck.
Now if I could only talk my bosses into lidar… :sunglasses:

1 Like

Isn’t that the case for all of us. It would be great to have LiDAR to expand when we could fly, but honestly we’ve done so well over the last 7 years by editing the point cloud and making our own DTMs that it wouldn’t be as big of a benefit as it would in other scenarios.

The problem isn’t the relativity to itself but to the preceeding map. DroneDeploy’s alignment algorithm handles some of the horizontal but you have to keep an eye on it and it does not take elevations into consideration. The map itself should be that +/- 1-2ft but it’s relationship to the previous map may be up to a meter just because of the spec of the onboard GNSS chip.

1 Like

Thank Michael - when I mentioned ‘to itself’, I meant the site itself - as in the previous map. I get that, and what you’re saying rings true about the vertical information, the onboard GPS not much better than my handheld Garmin…
I’ve been using DroneDeploy for a few years now, mostly for inventory of stockpiles, primarily for in-house data. I’ve done a comparison with RTK GPS (I’m a surveyor) and found the quantities comparable to between 5-7% to that of DroneDeploy’s photogrammetric calculations, without GCPs or on-board GPS, and would accept the UAV data to be more accurate as the pixels on the screen are much closer together (1.7cm/pixel on the map above) than the shots I would take spaced over 5’ apart, sometimes 10’ - depending how energetic I’m feeling that day…
In that sense: ‘relative to itself’ would refer to itself; as in the volume of the stockpile on that particular day, based on whatever elevation the base plane chooses to be.

For the Phanton 4 Pro 2, I believe the vertical data comes from the altimeter and not GPS. Thus it can be quite good if the barometric pressure is fairly constant during the mission. The absolute value means nothing because the barometric pressure and altitude at the takeoff point are not in the data processing flow. But you can use the altitude calibration feature of DroneDeploy to set the altitude of a chosen point to be the same value in both maps. I presume you are already doing this. This will significantly improve the relative Z-data between your 2 maps.


1 Like

We see the same percentages but based on trucking tickets. We did stockpile management for years without GCP’s or RTK and that’s fine because stockpiles are smaller less dynamic objects. When you start spanning a larger area things start getting warped pretty quick.

You sure it’s not the altimeter for AGL and GPS for the ellipsoid value? The AGL can remain at 200ft but the coordinate is written from the GPS data. Without RTK the value written is at best +/-1ft according to the processing reports.

I looked at all the EXIF data created after a DroneDeploy mission and found that the elevation data comes from the altimeter. I have edited this elevation data in the EXIF field of the photos and sure enough the Z in 3D model created by DroneDeploy responds as expected.

The EXIF data created by a DroneDeploy mission is in non standard format with the elevation data separated from the GPS data (which is stored in standard format). Editing the elevation field of the EXIF GPS data does not change the elevation values in a 3D DD model. Weird but that’s what I found back in 2018-19 timeframe. Makes sense from a relative accuracy standpoint because the variation in the altimeter data is way smaller than the GPS data. If fact it is a clever choice. The altimiter in my cell phone is very sensitive, easily resolving 1’ elevation changes. So using this mass produced component in the P4P provides a significant and cheap improvement over the poor Z provided by the GPS data.


Good stuff, thanks for the background.