Tips and Tricks to Recognize Problems and Resolve Issues
Late last month, I was asked to consider a best practices article discussing the status of geographic and projected coordinate systems, especially as they related to datums and GPS field data collection. This article fulfills that request. It is not intended to be used as a tutorial, although it provides concepts regarding coordinate system issues that might keep you out of trouble.
Recently, I experimented with data publishing on ArcGIS Online and on Portal for ArcGIS. I tested correct, incorrect, and missing coordinate system information in datasets, map documents, and services. I also built a public safety dataset in the Pacific Northwest that required me to merge or append different polygon datasets. I almost fell into a huge trap when the assigned coordinate systems clashed with one another. Fortunately, I recognized problems in time to fix them and create the required composite layers.
This article summarizes some current coordinate system and datum issues and lists additional helpful references. It demonstrates what happens when data is published as an online service without sufficient coordinate system documentation. It also shows what can happen when geoprocessing tasks are performed on improperly defined coordinate systems and datums.
Publishing without Preparation
“Using Web GIS to Build Consensus and Combat Wildland Fire Threats,” published in the winter 2016 issue of ArcUsermagazine, described how a wildland hazards map of Linn County, Oregon, was published to ArcGIS Online. The ArcMap document and its data were properly designed and included full metadata that consisted of coordinate system information for Universal Transverse Mercator (UTM) North American Datum of 1983 (NAD83).
With just a little coaxing, the map was published. But what would have happened if the same map was published without any coordinate system information for the data layers and the map? To test these conditions, I copied the original dataset into a new geodatabase and removed all coordinate system information from both the feature classes and the ArcMap document. When I reopened it, the modified map looked reasonable, and the data seemed to be in relational space. However, the map’s data frame properties did not list any coordinate system, the map units were unknown, and my proportional map scale window was disabled.
Next I inspected all layer properties and found that the coordinate system was undefined but the data looked fine, so I decided to publish the map. I logged into ArcGIS Online and proceeded to share the map as a feature service. When I analyzed the map, I received several major (high) errors, including one spatial reference fatal error, flagged by a red and white x. In the previous exercise, several high and medium error messages were generated, but no fatal errors. See “Using Web GIS to Build Consensus and Combat Wildland Fire Threats” in the winter 2016 issue for a discussion on resolving these warnings.
If I right-clicked the spatial reference error, ArcGIS Online prompted me to consider changing the data frame projection. Also, I found that context-sensitive help encouraged me to set a coordinate system for the data frame.
With Service Editor opened, I found that I could interactively define the data frame’s coordinate system. I contacted the data provider and learned that the map and its data should be projected in UTM NAD 1983 Zone 10N, US Feet. I was able to assign the proper data frame coordinate system without closing the Service Editor. I also opened the transformation tab and found that no transformations were needed. I hoped my data provider was correct. After fixing the spatial reference error and updating several minor issues, I reanalyzed my map and received several warnings but no fatal errors, so I published it.
Checking the Published Results
I was quite curious to see the published map, so I opened it in ArcGIS Online. I found that the data frame coordinate system was properly defined, the map units were correct, and my map scale worked fine. Next, I opened the properties of the Airports layer and checked the source coordinate system. The coordinate system for the ArcGIS Online layer was also set to UTM NAD 1983 Zone 10 North, although the coordinate system for the original Airports layer was still undefined. I now realized that I should return to my original map and define coordinate systems for all layers in ArcMap. The moral of this story is that more data preparation and documentation is better, and it is better to do it earlier rather than later.
A Real-World Coordinate System Challenge
Next I began preparing basemap datasets to support a public safety study for a Pacific Northwest Fire Protection District. Much of my data was obtained from a county GIS portal. Most of the available data was projected in a Washington State Plane NAD 1983 North US Feet coordinate system. However, one very important layer—Fire Districts boundaries—was described in the projection file and the metadata as projected in the Washington State Plane NAD 1983 HARN (High Accuracy Reference Network) North US Feet. When I used the union geoprocessing function to combine Fire Districts (NAD83 HARN) and Cities (NAD83) layers, many small boundary slivers and gaps formed. This made me question the Fire Districts HARN adjustment, so I decided to test it.
Testing Transformations
In a test model, I first loaded the County boundary layer, which was properly projected in WA State Plane NAD 1983 North US Feet. This dataset properly defines the data frame’s coordinate system. Next, I loaded the Cities layer, followed by the Fire Districts layer. Before the Fire Districts layer opened, I received a coordinate system warning error suggesting I set a transformation. I selected the appropriate NAD_1983_To HARN_WA_OR transformation.
When I zoomed to one city completely surrounded by fire districts, I noticed some possible irregularities along the city’s western boundary. As I zoomed in, I confirmed that yes, there are some small valid Fire Districts layer polygons extending into the city. As I zoomed way in, I also noticed that the Cities and Fire Districts boundaries layers were not coincident. Although the difference was less than one foot, that is certainly enough to create errors when the two datasets are combined through a union. I decided to troubleshoot the issue by experimenting with the HARN transformation and reset the transformation to None.
After removing the transformation, I zoomed in to the same corner that I previously measured and observed that the untransformed Fire Districts layer boundaries were now coincident with the Cities layer boundaries. I checked boundary relationships through the area and found that untransformed Fire Districts layer boundaries match Cities layer limits exactly. When I reran the Union tool, the slivers and gaps were gone. In this real-world example, I discussed my observations with the data provider, who promised to resolve any issues.
Who Needs Datums?
It turns out that anyone who creates maps and spatial models in our modern world needs to be aware of datums and understand them. To gain a better understanding of the relationship between datums and coordinate systems, you can review the slides from an excellent presentation, entitled “Space, Time, and Datum Forensics—Aligning GIS Dataona Dynamic Earth [PDF],” given at the 2015 Esri User Conference by Michael Dennis, president and owner of Geodetic Analysis, LLC. It provides a comprehensive review of coordinate systems and datums.
A workshop on this topic given by Dennis was summarized by Eric Gakstatter in his article “What really matters to GIS professionals,” available online at geospatial-solutions.com/what-really-matters-to-gis-professionals/. Gakstatter is the editor of Geospatial Solutions Monthly and a contributing editor to GPS World magazine and the Geospatial Solutions website.
Acknowledgments
I’m thankful for the many coordinate system experts in the surveying and GIS world and truly appreciate their diligence and shared expertise. I also thank all the agency, private, and other GIS data developers who strive so hard to provide the best data possible.
