Ingesting, Managing, and Using UAV (Drone) Imagery in the ArcGIS Platform

Cody A. Benkelman Technical Product Manager – Imagery – Esri

cbenkelman@esri.com

Version 2 17 November 2015

This in an Esri draft document intended to describe workflows for ingesting, managing, and using

imagery from unmanned aerial systems (UAVs, also called UAS, RPAS, or drones) within the ArcGIS

platform. This discussion will be as brief as possible, essentially providing an outline, with links to

detailed documentation.

Softcopy of this document is available for download at http://esriurl.com/UAVWorkflow

Contents Overview ................................................................................................................................................................................. 2

Sensors, Viewing Modes, and Metadata ............................................................................................................................ 2

Workflow options based on Sensor and Mode ...................................................................................................................... 4

Frame Imagery – Nadir or Low Oblique view mode – with no camera orientation data ................................................... 4

Frame Imagery – Nadir or Low Oblique view mode – with accurate camera orientation data ......................................... 6

Frame Imagery – High Oblique view mode – with or without camera orientation data ................................................... 7

Full motion video – for Nadir/Low Oblique viewing modes, with accurate (MISB format) camera orientation data ....... 9

Full motion video – any view mode, without accurate camera orientation data ............................................................ 10

Lidar from UAV platforms ................................................................................................................................................. 11

Appendix A – Imagery & Related Products ........................................................................................................................... 12

Appendix B – Summary Tables .............................................................................................................................................. 15

Appendix C – Schema for Feature Class defining metadata for “Oriented imagery” ........................................................... 17

Overview ArcGIS is an effective platform for managing and exploiting imagery and/or lidar data acquired by nearly any UAV (also known as drones, UAS, RPAs). The wide range in UAV & sensor configurations results in a variety of data and metadata, and therefore different workflows. This document is intended to describe the different considerations and provide an overview of the recommended workflows, then direct the user to other documentation for further details.

Sensors, Viewing Modes, and Metadata The options and workflows for working with this imagery acquired from a UAV are based on the type of sensor, the mode of operation, and the metadata which is available, but not the type of UAV (fixed wing or rotary). The types of sensors include:

Frame cameras

Full motion video cameras

Lidar Other sensor types (temperature, humidity, air pressure, chemical, etc.) may be addressed in the future.

Figure 1: UAV sensors and operational modes

The modes of sensor operation include:

Nadir (vertical) viewing imagery or lidar

“Low Oblique” imagery, e.g. viewing buildings, structures, or terrain from above, with the image footprint striking the earth

“High Oblique” imagery, e.g. viewing the sides of structures, possibly including the undersides, such that the image footprint or viewcone does not intersect the earth’s surface.

Metadata regarding sensor location and orientation is typically one of three alternatives: 1. The UAV has precise metadata for sensor location (x,y,z) and also the orientation regarding where it is aimed

(three angles, either Omega/Phi/Kappa or Roll/Pitch/Heading), as well as a precise camera model. 2. The UAV has position (x,y,z) metadata from GPS but sensor orientation data is unknown (or may be

approximate, e.g. “the camera points forward and approximately 30 degrees below the horizon”). 3. The UAV has position (x,y,z) metadata from GPS but no information regarding sensor orientation.

The workflows outlined here emphasize frame cameras, which may have numerous combinations of the above modes and metadata. Full motion video cameras may also operate in different modes, but the processing workflow for video has fewer variations. Lidar is typically operated in only nadir-to-low oblique scanning mode, and will always include precise location & orientation metadata. Detailed discussion regarding these workflows is contained in other documentation, and the intent of this document is to provide the reader with an understanding of which workflow to choose. A summary of sensor types, modes, metadata, and workflows is provided in Table 1 and Table 2 in Appendix B.

Workflow options based on Sensor and Mode Terminology is defined in Appendix A.

Frame Imagery – Nadir or Low Oblique view mode – with no camera orientation data

DESCRIPTION This section outlines workflows for processing aerial frame imagery acquired with a nadir or low oblique view angle. It is presumed GPS is included, but sensor orientation metadata is not available. Numerous workflows and resulting output products are described, but note that these are not mutually exclusive – use of multiple workflows and outputs is common.

A few example applications for imagery acquired in one or both of these view modes include natural resource applications (e.g. agriculture, mining, or forestry), damage assessment (e.g. following an earthquake, flood, or tornado), search and rescue, volumetric measurements (mines, stockpiles), etc.

INPUT DATA Single image frames from a flight mission, with high % of overlap

GPS data

Ground control points (x, y, z)

WORKFLOWS and OUTPUTS 1. Ad-hoc photogrammetric processing to create georeferenced products

If accurate georeferencing of this imagery is desired, it is generally achievable, presuming images are adequate in number and overlap. This processing can be done using the ArcGIS Drone2Map App (to be released in 2016) or a 3rd party software application (e.g. from business partners such as Pix4D, Icaros or DroneDeploy). These applications apply photogrammetric techniques such as structure from motion (SFM) to identify a large number of matching points between multiple images to build an accurate model of the camera locations, orientations, and camera parameters. With this technology, a number of valuable products can be created.

a. Orthorectified Mosaic (View in ArcMap or Web Map via Image Service) One typical output is to create a mosaic of the input images. The mosaic will stitch multiple images together, but an additional step is required to accurately place this mosaic onto the ground. Input of ground control is required, with accurately known (x,y) values in earth coordinates at points that may be clearly identified in the imagery. With ground control and adequate imagery, the user can create an orthorectified mosaic, with varying degrees of accuracy based on the input data quality. This output mosaic may be ingested into ArcGIS using the workflow for Preprocessed Orthophotos described at http://esriurl.com/8213 and with downloadable examples for building the recommended data models at http://esriurl.com/6539. A sample web map with an orthorectified mosaic (courtesy of DroneDeploy) is here: http://arcg.is/1CiT7ee.

b. Digital Surface Model and 3D Point Cloud (View/Analyze in ArcMap) As part of the ad-hoc photogrammetric process, a digital surface model (DSM) and 3D point cloud can also be created as output products.

i. The DSM provides a detailed and (presumably) accurate representation of the elevation values for areas of exposed ground, road surfaces, tree crowns, and buildings, and may be ingested into ArcGIS using the workflow for Elevation data described at http://esriurl.com/7169. Note that this DSM is often displayed on top of a comprehensive elevation surface such as from the ArcGIS Online World Elevation (to provide a larger area context, and also quality control check regarding absolute Z values). Downloadable examples for building the recommended data models are available at http://esriurl.com/6539. A sample web map with digital elevation model derived from UAV imagery (courtesy of DroneDeploy) is here: http://arcg.is/1CiT7ee.

ii. The 3D point cloud is typically attributed with RGB (or RGB+NIR) values from the imagery, and if delivered in ASPRS LAS format, can provide very effective visualizations using ArcGIS. The point cloud can be managed within ArcGIS using the workflow described in the Lidar Guidebook at http://esriurl.com/LidarGuidebook. Downloadable examples for building the recommended data models are available at http://esriurl.com/6539, but note the documented workflow was developed for aerial lidar, emphasizing multiple return values and the ability to extract a bare earth digital terrain model (DTM), and not optimized for photogrammetrically derived point clouds. The 3D point cloud may be easily viewed in ArcGIS Desktop applications (ArcMap, ArcScene, ArcGIS Pro) using the LAS dataset. For large projects, it is recommended to convert the 3D point cloud to Esri’s zLAS format (free tool available at http://esriurl.com/zLAS), and possibly written into multiple tiles (rather than one very large LAS file, which can exhibit slow performance).

c. Accurately oriented single images using photogrammetric metadata (View in ArcMap or Custom Web App via Feature Service) The last recommended portion of this workflow, to maximize usability of the UAV image data, is to manage and share all original images (in addition to the orthorectified mosaic). Providing users with easy and rapid access to the individual images can be of great value in scenarios such as damage assessment, where multiple undistorted views of an object on the ground lend greater understanding than a single mosaic view.

After processing with photogrammetric software, accurate camera calibration data (referred to as the interior orientation) and detailed frame orientation data (the exterior orientation) have been calculated, and may be exported for use in ArcGIS. When this metadata is formatted as a Camera Table (defining camera parameters such as focal length, pixel size, etc.) and Frame table (describing accurate [x,y,z] position and [omega/phi/kappa] orientation for each image), the individual image frames may be managed and shared by ArcGIS for rapid access to individual images. Each image may be orthorectified on-the-fly if desired, or may also be viewed in “image coordinates” (original image without projection into map coordinates). Help documentation regarding ingesting single image frames using the Frame Camera raster type begins here. A Frame Camera workflow for ArcGIS is being written and will appear soon in the Image Management Guidebook.

2. Simple Web Map with geotagged imagery

If georeferencing is not required, a Storymap can be made by following this tutorial, allowing users to find and view images based on the location of the camera. This is a relatively simple workflow, but with limitations (e.g. each image must be handled separately, and users may not be able to zoom to full resolution).

With inputs limited to single frames and GPS (imagery referred to as “geotagged”), ArcGIS cannot easily georeference the images. If desired (e.g. for a small number of images), the georeferencing tools in ArcGIS could be applied, but the workflows under number 1 above are recommended for greater efficiency & scalability.

Frame Imagery – Nadir or Low Oblique view mode – with accurate camera orientation data

DESCRIPTION This describes processing aerial frame imagery acquired with a nadir or low oblique view angle, but using a platform (UAV & sensors) that includes accurate metadata about both location and camera orientation. This configuration is uncommon today in commercially available UAVs, but may be expected in military-grade systems.

INPUT DATA Single image frames from a flight mission, with high % of overlap

Precise [x,y,z] position and [omega/phi/kappa] or [pitch/roll/heading] orientation metadata for each image

Digital terrain model (DTM) for the project area

WORKFLOWS and OUTPUTS 1. Orthorectified images and single frames (image coordinates) via the Mosaic Dataset (View in ArcMap or Custom

Web App via Feature Service) Given accurate [x,y,z] position and [omega/phi/kappa] orientation for each image, the user may directly apply the Frame Camera workflow mentioned in the previous section to manage and share imagery using the Mosaic Dataset. Using this workflow, ArcGIS will orthorectify each image on-the-fly, and dynamically build a mosaic view while enabling the user to access any single image if required. Single images may be orthorectified (projected onto the map), or viewed without projection (in image coordinates), and these products may be shared via the internet using ArcGIS for Server. If an output orthomosaic file is desired, it may be exported from ArcGIS using either the Copy Raster tool or Split Raster tool (for large mosaics, to output multiple tiles). If a digital surface model (DSM) and/or point cloud are required outputs, processing would be required using the photogrammetric software mentioned above.

Frame Imagery – High Oblique view mode – with or without camera orientation data

DESCRIPTION This section outlines workflows for processing aerial frame imagery acquired with a high oblique view angle. It is presumed GPS is available, but sensor orientation metadata is either not available, or not precise. As an example, the UAV metadata may report the approximate orientation of the aircraft body relative to north, but may not have any information regarding pitch or roll. Accuracy of any orientation data may be on the order of a few degrees.

A few example applications for imagery acquired in this mode include inspection of vertical structures, such as electrical transmission towers, cell phone towers, wind turbines, the face of a hydroelectric dam or the hull of a ship, or the underside of a bridge.

If nominal values for camera orientation are not recorded electronically, the flight operator may be able to estimate them, perhaps based on a standardized flight plan. As an example, if performing inspections along linear infrastructure such as a pipeline, the camera may be mounted such that its view orientation is left and down relative to the direction of aircraft motion. If the mission involves acquiring imagery on all sides of a vertical structure such as a wind turbine, an estimate for the orientation of the camera may be estimated as a vector from the location of the aircraft toward the (x,y) location of the structure.

INPUT DATA Single image frames from a flight mission, taken at high oblique view angles (defined as looking toward or above

the horizon, such that the footprint of the image does not strike the ground).

GPS data

Nominal sensor orientation data may be available, presumably described as [pitch, roll, heading].

WORKFLOWS and OUTPUTS 1. Geotagged imagery (view with Simple Web Map)

For high oblique frame imagery with GPS but no orientation metadata, a story map can be built (see links above) to share the images as points on a map, but for most applications this will be of limited value. Adding sensor orientation metadata (below), even if only approximate, will increase usability of the imagery.

2. Single images with orientation metadata (View in Custom Web App via Feature Service) If orientation data is available, even if approximate, it can add great value to enable a user to determine “do I have images that show this point?” and then review any individual image as needed. A recommended workflow for managing and sharing this imagery is as follows:

a. Create a feature class for each data collection (e.g. each flight), using the position of the UAV for each image (x,y,z) to define the point features.

b. Add the orientation metadata as custom fields in the feature class. c. Include a hyperlink to each image, stored in a web-accessible storage location. d. Other attributes may be added as desired to manage the imagery (e.g. project name, sensor used, weather

conditions, etc.). e. Presuming this data is to be shared (publicly or privately), a feature service may be published. f. Metadata regarding image location and orientation may then be accessed via a custom web app, allowing

individual images to be viewed on demand. Locations of known infrastructure (e.g. transmission towers) may be shown on the map to facilitate selection of images of interest.

A recommended schema for such a feature class/feature service will be included in a future revision of this document in Appendix C (currently under development). In addition, a prototype widget for Web App Builder will be available for exploitation of this high oblique imagery, providing intuitive navigation on a simple 2D map to find and review individual images, and enable visual inspection of assets via unrectified imagery.

Full motion video – for Nadir/Low Oblique viewing modes, with accurate (MISB format) camera orientation data

DESCRIPTION This section links to workflows for processing aerial video acquired with a nadir or low oblique view angle, presuming the airborne system records the camera’s position and orientation according the MISB 0104.5 or MISB 0601 metadata standard. MISB refers to the Motion Industry Standards Board, with information available here http://www.gwg.nga.mil/misb/.

INPUT DATA Full motion video from a flight mission, with MISB format metadata re: camera orientation and location

embedded in the video stream.

WORKFLOWS and OUTPUTS 1. Map with aircraft flight tracks, video viewer, and dynamic video footprint (View in ArcMap)

The full motion video (FMV) add-in for ArcGIS allows users to work with aerial video accompanied by MISB format metadata using ArcGIS for Desktop version 10.2 or later. Note that nothing in this workflow is unique to UAV platforms, so this discussion is applicable to any video with MISB metadata. Aerial video with MISB metadata may be displayed in a popup window, accompanied by a moving footprint on the map. Features may be digitized from the video window, and existing GIS features may be projected into the video. Other metadata may be extracted to facilitate data management and video search, such as the complete aircraft flight path, or a mosaic dataset showing a subset of still frames (extracted from the video at a user-specified interval), with a composite footprint of all video footage. The FMV Add-in is available at no cost to registered ArcGIS users other than a registration fee of $19.95. On http://my.esri.com go to the My Organization tab, click the Downloads link that appears below it. In the Products list, beside ArcGIS for Desktop 10.3 (or ArcGIS for Desktop 10.2.x), click View Downloads. Refer to this blog for additional information regarding use of the FMV Add-in: http://blogs.esri.com/esri/arcgis/2015/03/02/arcgis-full-motion-video-1-2-1-for-arcgis-10-2-and-10-3/

Full motion video – any view mode, with GPS but without accurate camera orientation data

DESCRIPTION This section describes two optional workflows for processing aerial video acquired from a UAV with GPS but no camera orientation metadata.

INPUT DATA Full motion video from a flight mission

GPS data in a separate file (*.csv file)

(Optional) Estimated camera orientation metadata (*.csv file)

WORKFLOWS and OUTPUTS 1. Map with aircraft flight path and spatially indexed video (view in ArcMap)

This workflow involves a preprocessing step to “multiplex” the GPS position data into a metadata stream that is compatible with the ArcGIS FMV Add-in, emulating a subset of the metadata fields in the MISB format. With FMV version 1.3 (to be released in 1st quarter of 2016), a geoprocessing tool will be included called the Video Multiplexer. This tool will allow a user to process a GPS file to combine (multiplex) it with video into a single file compatible with the FMV Add-in. The Video Multiplexer will also allow input of camera orientation metadata which enables calculation of a video footprint. It is presumed that any camera orientation values will be estimates only (e.g.. a fixed look angle, relative to the aircraft body, and therefore the direction of flight). Note that, if input data is limited to the video and GPS, the metadata fields for camera location will be populated, but the camera orientation will be unknown. The resulting file will display the flight path of the aircraft in ArcMap, and allow the user to navigate to the proper time within the video file based on the aircraft position, but the video footprint will not appear within ArcMap. Refer to documentation provided with FMV version 1.3 for details regarding the workflow, and format of the input files. (Instructions in previous section for obtaining the FMV add-in).

2. Simple Map with aircraft flight path and hyperlinked video (view in ArcMap or web client)

This workflow describes steps to display the GPS flight path of the aircraft as a feature class, then simply link to the video file to enable user access. This method has the advantages of being simple and compatible with web clients (in addition to ArcGIS Desktop), and is an effective method for managing and accessing large numbers of aerial video files. However, using this method, the flight path and video are not correlated in time, so the user is not able to navigate to an (x,y) location along the flight path and use the location to jump to the appropriate time in the video. Accurate camera orientation data is also not available, so the video footprint cannot be projected on the map, and it is not possible to display (or digitize) features on the video frame. Workflow steps are as follows:

1. Obtain GPS data file in *.gpx format. 2. Run the geoprocessing tool “GPX to Features” to create a point feature class.

3. Next, run the “Points To Line” tool which will convert the feature class of points into a single polyline. 4. Upload the video file to an appropriate storage location accessible by your users (e.g. possibly a file server on a

private network, or if sharing publicly, you may upload the video to a site such as YouTube). 5. Add a new field “Video_URL” into the feature class for the GPS, and copy the URL to the video into that field. 6. The feature class may be shared on a local network, or alternatively copied to ArcGIS Online and shared as a

Feature Service. 7. Presuming you are managing multiple videos, each GPS flight record and video URL should be a separate record

in the same Feature Class/Feature Service (vs. a separate feature class for each flight).

Lidar from UAV platforms

DESCRIPTION This section links to workflows for processing aerial lidar data. Note that nothing in this workflow is unique to UAV platforms, so this discussion is applicable to any aerial lidar.

INPUT DATA Lidar from a UAV flight mission, professionally post-processed to generate *.las or *.zlas files, including 3D point

classification for ground vs. non-ground points at a minimum.

WORKFLOWS and OUTPUTS The recommended workflows for processing and managing lidar data are documented in the lidar chapter of the Image Management Guidebook at this URL: http://esriurl.com/LidarGuidebook. A brief summary is provided below. 1. LAS Dataset for QC and processing of a single project (View/Analyze in ArcMap)

Lidar data can be quickly reviewed for quality control in ArcGIS, generating both statistical and spatial metrics, by adding all LAS files from one flight into a LAS Dataset. Statistical metrics, such as classification codes, zMin and zMax values, and inclusion of multiple return pulses, can be verified in the properties of the LAS Dataset. Spatial metrics are generated using geoprocessing tools, to ensure the data includes adequate pulse density, point density, and complete project area coverage (e.g. using the LAS Point Statistics as Raster tool).

2. Derived elevation products in Mosaic Datasets (View/Analyze in ArcMap, or share with web clients)

Following QC, the recommended workflow for managing and sharing lidar data focuses on creation of rasters for a bare earth digital terrain model (DTM) and first return digital surface model (DSM). These base elevation rasters are managed using Mosaic Datasets, from which multiple derived products are available instantaneously for visualization or analysis (e.g. hillshade, slope, aspect, curvature, contours, etc.). Please refer to the Image Management Guidebook for full details.

Appendix A – Imagery & Related Products This section will provide a general discussion of imagery products, focusing on definition of terminology as well as highlighting the capabilities and limitations of each. 1. Geotagged imagery or video

If your imagery (single frames or video) includes GPS but no orientation metadata, the imagery is typically referred to as “geotagged”. GPS data may be stored in external files, but will most typically be embedded in the image header in EXIF format to record the camera location in 2 (x,y) or 3 dimensions (x,y,z). The (x,y) coordinates are typically longitude and latitude, and if height (z) is present, it may represent either orthometric elevation (above sea level) or ellipsoidal elevation. As a third alternative, for a UAV, (z) often represents a height above the location the UAV was launched, usually with units of meters. Examples could include individual images acquired from a UAV, or simple photos taken by a person on the ground. In the case of video, the term “geotagged” would typically refer to availability of a GPS data file to accompany the video file (*.ts, *.mpg, *.mp4, *.mov formats). The most common format for GPS would be *.GPX, containing one record every second, representing (x,y,z) location of the sensor, as well as GPS time and possibly other parameters. The (x,y) coordinates in a GPX file are typically longitude and latitude although they may be in a projected coordinate system. Elevation (z) is typically in meters, and usually represents ellipsoidal elevation (above the WGS 84 ellipsoid) although it may reference orthometric height (above sea level, e.g. the EGM2008 geoid). The GPS and Video files may not have any explicit correlation, requiring additional metadata – perhaps recorded manually - regarding the start and stop times for the video. For still frames and video, geotagged location information will not typically be accurate (perhaps ~10 meters) and without camera orientation data, automated georeferencing of the imagery will not be possible. Without further processing, managing and sharing geotagged imagery may be limited to approximate locations on a Story Map.

2. Oriented imagery In addition to geotag data for your imagery from GPS, if your system includes an attitude sensor, the imagery may be referred to as “oriented”, providing metadata representing position (x,y,z) and orientation (pitch, roll, heading) or possibly (omega, phi, kappa) for each image. Both position and orientation may be precise, but with most UAVs, the precision will be limited. Lacking an attitude sensor, approximate orientation may also be assigned to each image based on using a platform with the sensor mounted at a known angle (e.g. pointing toward the direction of flight and 30 degrees below the horizon), or even via simple operational rules (e.g. if imagery is acquired by flying around a vertical asset, it may be assumed that the orientation of each image is toward the asset). As with geotagged imagery, oriented imagery can be shared with a simple Storymap. A more robust application for sharing oriented imagery allows a user to navigate on a simple 2D map (or possibly a full 3D scene) and review individual images, e.g., to enable visual inspection of assets such as an electric transmission tower, wind turbine, etc. Without further processing, oriented imagery will not be accurately georeferenced. As noted in the workflows described above, nadir or low oblique imagery may be georeferenced through ad-hoc photogrammetry. If acquired in a high oblique orientation, it is not possible to georeferencing the images to project them onto a map.

3. Georeferenced imagery or video “Georeferenced” refers to imagery that has been processed to place each image (or each video frame, in a dynamically moving window) into a mapping coordinate system. A projected coordinate system is typically used, although geographic (latitude/longitude) coordinates may also be used.

Simple georeferencing may be accomplished through several different methods – e.g. creation of manual or automated tie points from the imagery to a suitable (orthorectified) base image followed by image rectification using any of several mathematical models, or “direct” georeferencing from a system that measures both position and orientation, as well as availability of a camera model (lens focal length, sensor dimensions, etc.). The ArcGIS Full Motion Video (FMV) add-in uses direct georeferencing based on the availability of “MISB” format metadata. Without precise measurements of all parameters and the availability of a digital terrain model (DTM) to compensate for terrain relief displacement, georeferencing is not the same as orthorectification. As a result, the spatial accuracy of georeferenced imagery is likely to vary significantly (from one data collection to another, as well as within a single data collection) depending on the source. If accurate spatial data is required, the image data must be orthorectified, not simply georeferenced.

4. Orthorectified Images or Mosaic

With still frame images taken in nadir or low oblique modes, the images are often processed into a mosaic, and ideally orthorectified so that all imagery is placed accurately onto a map. Orthorectification of UAV imagery is generally possible, depending on overlap, using a software package such as the ArcGIS Drone Imagery App (to be released late 2015 or early 2016). 3rd party applications (e.g. from business partners such as Icaros or Pix4D) have similar capabilities. These applications apply photogrammetric techniques such as “structure from motion” (SFM) to derive a camera model, position and orientation data for each image, then create a mosaic of the input images. With ground control, many of the leading software packages can create an orthorectified mosaic, with varying degrees of accuracy based on the input data quality (e.g. in some cases, the result should be considered georeferenced, but not truly orthorectified). This output mosaic may be immediately ingested into ArcGIS using the workflow for Preprocessed Orthophotos described in http://esriurl.com/8213 and with downloadable examples for building the recommended data models in http://esriurl.com/6539.

5. 3D Point Cloud and Digital Surface Model As part of the ad-hoc photogrammetric process described in the previous section, a 3D point cloud can also be created as an output product, and from that, a digital surface model (DSM) may also be produced.

a. The point cloud is calculated by correlating multiple camera views of the same location, and is typically attributed with RGB values from the imagery. When the various camera views include areas of discontinuity – e.g. at the edges of where a tree or building obscures view of the ground - the point cloud may exhibit erroneous values (extraneous points). For users familiar with lidar data, these artifacts are unique to point clouds derived via photogrammetry (sometimes from inexpensive cameras). Similarly, the imagery-based point cloud will be lacking many attributes that would normally be present in lidar data. If delivered in ASPRS LAS format or Esri’s zLAS format, the point cloud can provide very effective visualizations using ArcGIS Pro or ArcScene. It can be managed within ArcGIS using the Lidar workflow described in http://esriurl.com/LidarGuidebook, but note there will be limitations to these photogrammetric point clouds. Specifically, the ArcGIS Lidar workflow was developed for aerial lidar collections, emphasizing multiple return values and the ability to extract a bare earth digital terrain model (DTM). Photogrammetric point clouds do not include attributes such as first/last return, and the points are also usually not classified (as “ground”, “building”, “vegetation” etc.), so functionality within ArcGIS for filtering points based on those attributes will not be operational. Extraction of a bare earth DTM is not possible in an automated fashion, although a reasonable bare earth can often be derived through manual editing.

b. The DSM is created from the point cloud, and will show the extracted elevation values for exposed ground, road surfaces, tree crowns, and buildings. As noted above, any erroneous values within the point cloud will also appear in the DSM, especially along the edges of vertical structures (e.g. “ragged” edges of building rooftops and walls).

6. 3D models

Creation of 3D models from UAV imagery will be addressed in a future version of this document.

Appendix B – Summary Tables

Table 1 – UAV sensor modes, types, and sample applications

Table 2 – Applicable Workflows in ArcGIS as a function of sensor, mode, and available metadata.

* Note these Workflows refer to detailed documents available in the ArcGIS Resource Center starting at this Landing Page

(http://esriurl.com/ImageManagement) where the user will find links to detailed discussions in the “Image Management Guidebook” and also a Group in

ArcGIS Online with sample Python scripts. Some of these workflow descriptions are still under development (e.g. Frame Camera, FMV) but users can

find information in the ArcGIS Help system.

Appendix C – Schema for Feature Class defining metadata for “Oriented imagery”

A document defining a recommended schema for Oriented imagery (listing [x, y, z] position and orientation data expressed as [pitch, roll, heading] along with other metadata fields) will be inserted here. If shared as a feature service, this schema will allow access to unprojected imagery in a simple web application. Contact cbenkelman@esri.com for status.