ArcGIS Drone2Map

Having a bad case of vertigo?

Imagine the following scenario: Your client has asked you to create 1-foot contours for an area in which they plan to build a subdivision. You plan a well-thought-out drone collection of the area and then process it with ArcGIS Drone2Map or Site Scan for ArcGIS. While creating the contours, you realize the values are incorrect. Alternatively: You fly your drone over an area and create a beautiful 3D textured mesh or point cloud, but when you bring it into ArcGIS Online, the results don’t align with either the existing basemap or your client’s layers.

Why did this happen? How can you ensure this will not happen again when you plan another mission?

While there are other potential causes for incorrect results, the most common is inaccurate altitude values recorded by consumer drones. Many popular drone models do not consistently record accurate altitude information during a flight. Sometimes, the vertical GPS data from a drone can be off by as much as 100 meters. . If you have a real-time kinematic (RTK) drone, the rest of this blog is probably not applicable—refer to this alternate discussion of RTK drones with outputs that appear to be at the wrong elevation.

It is recommended that you always fix this problem if you want your z-values to be as accurate as possible and to align properly with the ground surface elevation.

Note: There are cases when this issue can possibly be ignored, such as with volume measurements taken from DEMs, publishing a scene layer package (SLPK) to the web, or when you are only creating an orthomosaic. However, it is not recommended that you do this, as you may still need to generate additional products from your images for which vertical accuracy will be significant.

Before we discuss the solution to this problem, let’s review some basic terms:

A detailed explanation can be found in the “Further Education” section of our related blog post (“Having a bad case of vertigo with your RTK drone?”), but now that you understand the basics, how can you fix this problem?

The answer depends on how many resources you have at your disposal:

Option 1

The best solution is to incorporate survey-grade ground control points (GCPs) when processing the images in Drone2Map or Site Scan. While this may be the costlier option in terms of time and money, it will ensure that your results have the most accurate values and result in savings down the line. When using GCPs from a licensed surveyor, ensure that the vertical coordinate system is agreed on as part of their deliverable.

Option 2

Another option is to collect accurate GPS values of your GCPs, and then incorporate them into your processing workflow. When collecting GPS values, you should ensure that the datum being used by your GPS unit is the same as the output datum you need.

Option 3

If you do not have the resources to lay out artificial control points, you may be able to use existing features in your project area as your control points (presuming the existence of human-made objects in your project area). These could be street corners or other permanent objects that are clearly visible from your images. These points should be scattered throughout your project area and not concentrated in an individual location or region of the project area

Option 4

If you are using Drone2Map, you can add GCPs from the basemap you are using by following “Add from map” process in the Manage control topic of the Drone2Map help. While the z-values are not explicitly shown on the basemap, they are extracted from the Esri World Elevation Terrain service. Be sure to read the details for each area, as the accuracies vary widely by region and may have an impact on your results. If you want to verify the z-values that were extracted in this process, you can open the GCP table, which shows orthometric and ellipsoidal elevation values for most of the world (for further information on ellipsoidal and orthometric heights, see

Whichever method you use to add control points, it is crucial to know which vertical reference system is being used for the z-values, and to modify them according to the requirements of your project. If your area is relatively small (which is usually the case for drone projects), a vertical offset can be applied to the values to convert from ellipsoidal height to orthometric height (see for more details). If you are trying to add your output products to an ArcGIS Online Scene, please be aware that it uses ellipsoidal heights from the EGM96 ellipsoid so make sure your Z values are using the same datum.

Finally, there is an option to correct z-values artificially in Drone2Map (and possibly in Site Scan in the future). In this workflow, you need to know the flying altitude above ground level (AGL) and check that the surface is mostly flat in the project area. This workflow will find the ground elevation in the area of the project, and then add the flight altitude above ground to calculate the altitude of each image.

Overall, when you collect imagery with drones, it is important to remember that most consumer drones do not have high-end GPS units. Incorporating ground control points is the best workflow to ensure your results are as accurate as possible, but if these options are not available, you can use reference vertical layers or Esri’s elevation services, or even set the image altitude values automatically.


Co-authors: Cody Benkelman, Mark Barker, Taren Woelk

About the author

Asaf Even-Paz is a Solutions Engineer on the Imagery and Remote Sensing team. He has been at Esri for over a year, supporting account managers in various imagery relates sales opportunities. Asaf has an extensive geo-spatial background spanning more than 15 years and included aerial imagery, traffic information systems and geographic system analysis. He is focused on working in the cloud on imagery workflows and developing new and exciting ways to use geospatial AI for our clients. Outside of work he enjoys practicing Martial Arts with his family, spending time outdoors and watching movies.

Inline Feedbacks
View all comments

Next Article

A First Glimpse into the Future of Population Data: Part 4

Read this article