Title
Ortho Mapping Workflow and Orthomosaic Creation
Author

Levi S. Lebhart
American River College, Geography 350: Data Acquisition in GIS; Fall 2018
w1388402@apps.losrios.edu
Abstract

The project revolved around following the workflow as described in the Methods section of this document, borrowing from workflows for Historical imagery as derived by ESRI, in order to build a completed orthomosaic image that could then be used as a feature services within the ArcGis Online Environment.
Introduction

The goals of this project were to generate a basic workflow for orthomosaic creation using non-spatial data, resulting in a finished product to be used within the ArcGis Online environment. Other secondary objectives of this exercise were to become more proficient with the tools available within the ArcGis Pro platform as well as create better habits for data management. The main challenges faced during this project will be locating and downloading the necessary data, as well as metadata required for the generation of the orthomosaic. The process is also extremely time consuming- massive amounts of manual input to geo-reference the rasters, as well as applying proper pre-processing for the image files. Another issue comes down to the fact this imagery will most likely be non-spatial, requiring different procedures and protocols to be used within the ESRI suite of products.
Background

Levi S. Lebhart is currently enrolled in American River College, majoring in Geographic Information Systems. He has currently completed the majority of courses within the program and is hoping to recieve his certificate in GIS after this fall semester.
Methods

The primary workflow is as follows:
  1. Download Data
    • USGS Earth Explorer
  2. Pre-Processing
    • Fix Orientation
    • Build Pyramids
    • Define Projection
    • Rescale
    • Clip
  3. Georeference
  4. Compile Metadata
    • Create Point Feature
    • Derive COG Value
    • Build Frame Table
  5. Use Frame Table to Build Mosaic Footprint

Data Collection
USGS Earth Explorer
The data was first collected from the USGS Earth Explorer, using a predefined shapefile in order to measure out the area of interest for the project. This geometry covered the majority of the Sacramento region, focusing primarily on the urban areas. The data that was collected were aerial single frames, at a scan resolution of 63 microns, 400dpi, with a scale of 1:15000. The photos were taken on May 9th, 2002, with a Carl Zeiss 153mm lens, and later scanned by the USGS and added to their archives in June 2017. The photo graphs were downloaded using the USGS bulk downloading applications they provide on the USGS website. The total disk space required by the files totaled 18 gigabytes, with 600 individual frames.
USGS Earth Explorer
Orientation Correction
Pre-Processing
Fix Orientation
The downloaded imagery was improperly positioned for georeferencing, so it was re-oriented within Windows photo viewer.
Pre-Processing
Build Pyramids
Once re-oriented, the imagery needs to have its raster pyramids rebuilt in order to reflect the changes within ArcGis Pro.
Reviewing Data in ArcCatalog
Batch Define Projection
Pre-Processing
Define Projection
The imagery had no spatial reference, so a batch process of "Define Projection" was completed in order to properly orient the imagery spatially within ArcGis Pro. This process was carried out with ArcCatalog. The fils were placed into a temporary file geodatabae titled "imageryRescale" in order to prevent them from becoming mixed in with the rest of the raw images. The files were then opened in ArcGis Pro.
Pre-Processing
Rescale
ArcGis Pro has a simple tool that can be used for fix images whose extent do no fit with the current map the user may be currently working within, called "Rescale". The user interface within ArcGis Pro was far more intuitive for batch processing as well, allowing you to drop massive amounts of file into the data frame, and then start a batch process for multiple files with a simple click to add all of the files needed to be processed.
Rescale Batch Processing
Clip Example
Pre-Processing
Clip
Once rescaled, the images still had a black border from the previous scan of the photography that needed to be removed before further processing could be completed. A batch clip process was implemented to achieve this. The geometry for the polygon was derived by overlaying multiple items and finding out where they shared the most area. The final result was out put to a geodatabase called "ImageryCorrection", where much of the processing were to take place.
Georeferencing
After pre-processing had completed the next portion was primarily used to georeference the entirety of the tiles. The tiles were georeferenced using a first-order polynomial transformation. These rasters were to cover the area as defined by the City of Sacramento "Neighborhoods" shapefile, as found on the City's Open Data Portal. The final count for rasters that had been georeferenced was 103 files, the rest of the files that had been processed as that point discarded and cleaned up.
Georeferencing Completed
Editing Metadata
Compile Metadata
Create Point Feature Class for Raster Centers
The next portion of the project required collecting and creating the proper data needed to build the Frame and Camera tables for the mosacing portion of he process. The metadata that were collected were recommended by the ESRI workflow for historical imagery, which outlines a basic process for generating mosaic and orthomosaic imagery for imagery that is derived from older rasters. A new point feature class was created in order to accomplish this- the values that the point geometry would store would be used alongside the metadata to generate values for the photo laydowns "Course over Ground" (COG for short- the distrance that is travel by the plane with respect to a location on the ground). The metadata was compiled is as follows:
  1. Approximate X,Y - Store as a point feature class, in meters
  2. Raster Field - The file path for the raster to be used in the mosaic, stored as a text string, 255 Characters
  3. PhotoScale - The scale of the map extent as "15000" as a text string, 255 Characters
  4. FocalLength - The lens that was used, stored in microns, in this case 152999 microns, stored as a text string, 255 Characters
  5. Frame - The number of the photograph in the roll of film, four digits, stored as a text string, 255 characters
  6. Run - The number or line index of the film, fourt digits, stored as a text string, 255 characters
  7. Film - The number on the roll of film in which the photo slide exists, 6 digits, stored as a text string, 255 characters
  8. ScanDirection - The direction the film was taken as, defined by the ESRI toolset, text srting, 255 characters
  9. ScanResolution - In microns, the resolution of the scan itself, stored as a text string, 255 characters
  10. FrameSize - in microns, this case 63 stored as 630000, text string, 255 characters
  11. Cols,Rows - The columns and rows of the given rasters, stored as text strings, 255 characters

The definitions found above were derived from the ESRI Historical Imagery workflow, and the metadata collected from the USGS Earth Explorer, using the USGS data dictionary to interpret the values provided.
Compile Metadata
Derive COG Values The next step used the information derived from the metadata in order to provide the proper COG values to build the Frame and Camera tables for use with the Orthomosaic wizard. This was completed using the "Estimate COG Values" tool provided in the ESRI python tool box for the Historical Imagery toolbox.
Finding COG Values
Building Frame Table
Compile Metadata
Build Frame Table
Once the COG value was derived, I could begin bulding the frame table. This was done by using the ESRI python tool "Check Estimate Orientation", as found in the Historical Imagery workflow. There were no errors, but two warnings while trying to attempt this, and the warnings were only to provide additional, optional data for the tool. I disregarded these warnings and went ahead with the process and used the next python tool titled "Estimat Orientation". The tool ran successfully, but only returned null values.
Results
Orthomosaic Even though the values provided were null, I still attempted to run the orthomosaic tool to see if it might generate something. This resulted in nothing more than the fabled "Error 999999" reading. The tool was able to crawl and find the rasters however, only failing when attempting to apply the table
Error 999999
Mosaic Raster Footprints Instead of an orthomosaic, I went ahead and build a mosaic raster foot print, which be used in various other processes to ortho correct the imagery at hand.
Raster Footprints Built
Analysis
The primary issue I believe occured while pre-processing the images. I ran comparisons on different metadata finders for the images as raw files that had been downloaded from the USGS Earth Explorer, and then ran metadata finders for the final images that were georeferenced and found a startling lack of information for the processed slides. Another issue I came up on were gaps in the metadata from the USGS. I went all around looking for calibration reports for the cameras used only to find the page where they store these to have last been updated in 2008. It was also an issue trying to track down who exactly took the photos, I searched USGS up and down, the USDA, the National Archive and even Data.gov in order to find any inkling of idea of what project these images were from, but to no avail. The agency that had been responsible for recording these images was only referred to as "Urban Area" which in multiple search engines from google, to duckduckgo, to bing provided no specifics in regards to the USGS. The only item I was able to come across was a small tidbit from the National Map Small Scale. Using Archive.org provided some insights here and there, but mostly just wound up being the same pages I had already seen, just with a different URL than the USGS uses now.
Conclusions
The files themselves would still be usable I believe. However they may need to be rescaled by means of the scale tools found within the georeferencing tools in ArcGIS pro, and would have to raw, directly from the website as originally were, perhaps only defined for a projection. I would have tried to contact someone in regards to interpretting the metadata provided by the USGS more clearly, and even possibly filed an FOIA request for the calibration report for the camera that was used in capturing the aerial imagery, if it was neccesary. The general workflow regarding multiple geodatabases worked well, however in reflection on the pre-processing methods it would be redundant, as much of those processes ended up harming the slides more than helping. The final word research.