@Layne, @zach1, @Gary, @Jeremy, @Nipul,
You can do this job without GCPs since you are mainly concerned with adjusting the large offset in the elevation. To do this, you can use an Auto-Calibration Technique to achieve cm-level accuracy in the elevation data. This is done by first making maps using only 30 photos from a mission. Choose photos that encompass a point with known elevation, say where you would have placed a GCP. Process this subset of photos into maps. This will go very quickly. Then on the 2D map, measure the elevation of the known point. Now compute an offset = Known elevation of point - Measured elevation of known point. Next add this offset to the AbsoluteAltitude field in all the photos of the mission and generate new maps using all the photos. The new maps can have cm-level elevation accuracy if the elevation of the known point has cm-level accuracy and the known point is well modeled in DroneDeploy, which will happen if you put a high-contrast GCP target at the known point.
If you do this for each of your missions (or all the missions you ever fly so that you always have excellent elevation data in your maps), then you can combine photos from multiple missions to make one big map.
GCPs are better if you want better GPS longitude and latitude data in your maps also. But for your case, the elevation error due to the offset in launch elevations is 10 to 100 times larger. So you get the biggest bang for your buck by just correcting the elevation data at zero cost.
The only technical part of this approach is adding the offset to the AbsoluteAltitude field in the Exif data of the photos. For that I wrote a Python script that does a binary search and replace of the AbsoluteAltitude field. Perhaps you can also do this or have a friend that can do it for you. The key is to change the AbsoluteAltitude field that looks like this:
drone-dji:AbsoluteAltitude="+275.96"
to this when, for example, the offset is 11.04 meters:
drone-dji:AbsoluteAltitude="+287.00"
Anyway this is working great for my missions and, since I am on a free Pro trial with no support of GCPs, it was something I could try out. I also learned that I could not manually edit the Exif data using a simple editor like Notepad in Windows 10 since it mangles the Exif data after saving. Nor could I use the widely available exiftool by Phil Harvey since it writes out the data in a format that DroneDeploy cannot parse. My 20-line Python script automatically processes all the photos from a mission to add the offset, taking about 100 sec to process 143 photos with 1 GB of data. My script is not very portable because it runs inside the 3D Rhino program using their RhinoPython variant but it can easily be ported to another Python version or other language. A copy is below. I had to use __ to show leading spaces as otherwise they are squeezed out of the post and note that the difficult to decipher ‘’’’ is actually ’ followed by " followed by '.
Python program to add offset to DJI AbsoluteAltitude field in Exif data of all the photos in a directory.
from time import time
import System
startime = time()
altitudeOffset = 11.01 # Set this to: Offset = Actual altitude - altitude measured on DD map
dir = ‘C:\Users\Terry\Pictures\fixelev’ # Set this to directory with photos
key = ‘drone-dji:AbsoluteAltitude="+’ # Fixed part of search pattern
files = System.IO.Directory.GetFiles(dir, ‘*.JPG’)
for file in files: # Offset the altitude in all photos
__ f = open(file,‘rb’); s = f.read(); f.close() # Open, binary read file and close
__ i = s.rfind(bytes(key)) + len(key) # Find pointer to value of absolute altitude
__ if i == len(key)-1: # then rfind returned -1 since it did not find key
____ print ‘The key:’, key , ’ was not found in file ‘, file, ‘\nPlease fix and retry’
____ exit()
__ oldAlt = str(s[i:i+10]).split(’"’,1)[0] # 10 works for up 100,000ft; Remove " and beyond
__ original = bytes(key + oldAlt + ‘"’) # Construct byte pattern for search
__ new = float(oldAlt) + altitudeOffset # Add offset to old altitude
__ fixed = bytes(key + ‘{0:.2f}’.format(new) + ‘"’) # Construct replacement bytes
__ s=s.replace(original, fixed, 1) # Search and replace bytes
___ with open(file, ‘wb’) as output_file: # Open file for binary write.
_____ output_file.write(s) # Write byte array to file.
__ print file, oldAlt, ‘{0:.2f}’.format(new) # Write summary of change for each file
print ‘Time = {0:.3f} sec to add altitude offset of {1:.3f} to {2} files.’.format(time()-startime, altitudeOffset, len(files))
This Auto-Calibration Technique is like creating a virtual, altitude-only GCP which is all you really need in some situations. And it only takes about 30 minutes of preprocessing time to generate the 30-photo map and update the altitude data. Plus it can be applied retroactively, allowing you to improve the elevation accuracy of old maps. You just need to have kept the photos and be able to identify a point with known elevation that has enough texture to be well modeled by DroneDeploy. I do nothing special for my missions, using no special targets. I just use a concrete surface that I know is at 1000’ elevation. This surface has an exposed-aggregate finish which is enough for DroneDeploy to model well in 3D.
I recommend doing this for all your missions whether or not you are combining pictures from multiple missions because it always gives you maps with accurate elevation data with zero added cost. Otherwise the elevation can move around by up to 1000’ over the course of a year due to the typical 1" variation in barometric pressure. I know this is true for my Phantom 4 Pro because it uses its on-board barometer to calculate the altitude. Over a 2-week period, the measured elevation of the same point on maps from different missions varied by 500’. And I suspect most drones will see this same issue as they likely use their on-board barometer to calculate the altitude that is recorded in the Exif data and to fly level during a mission.
Regards,
Terry.
