Increasing the Level of Positional Accuracy
At California State University Monterey Bay (CSUMB), the necessity of increasing the level of positional accuracy around campus has been a growing interest. The small university campus located on a former Army base has been growing over the last few years with many new developments and ongoing demolition projects. CSUMB is already using Mobile GPS solutions to provide enough accuracy (3-5m) for field inspections of existing or non-sensitive assets. However, utility infrastructure being more sensitive requires additional consideration and higher positional accuracy. The university is moving to update existing utility drawings by validating locations of manholes, valves, and other features while also collecting As-Built utility data from surveyors during new construction and demolition projects. This will serve not only as a cross-reference to data provided by contractors but will assist in future surveys or field locating tasks.
CSUMB Moves to Mobile GIS and High-Accuracy RTK with GNSS
To capture horizontal (horizontal datum NAD83) and elevational data (vertical datum NAVD88), the university needed to determine first the required accuracy and if there was an affordable technology solution that could accomplish the task. By working with the GNSS experts at Anatum Field Solutions and their review of Bluetooth GNSS options, the EOS Arrow 200 RTK-GNSS using Esri’s Collector for ArcGIS app, paired with an existing campus base station transmitting centimeter-level RTK corrections via the Internet, met all requirements for horizontal accuracy. This workflow incorporates the iPad with cellular service running Collector and Eos Tools Pro software, connected via Bluetooth to the Arrow 200. The centimeter-level accuracy is achieved by receiving RTK corrections from the base station on campus. However, many states have publicly available base stations for achieving this same workflow.
While this allows us to capture horizontal data at a high level of accuracy in real-time and our preferred NAD83 datum, to more accurately collect vertical data, additional adjustments must be made to capture orthometric vertical elevations (commonly referred to as Mean Sea Level) in NAVD88 datum. The GNSS receiver provides vertical data in Height Above Ellipsoid (HAE) and that value is captured by Collector when a data point is recorded.
HAE approximates the earth’s surface using an ellipsoid, while the Geoid is a model of the earth’s surface using gravitational measurements provided by NOAA’s National Geodetic Survey (NGS) – learn more about geoids at (www.ngs.noaa.gov/). To get elevations in NAVD88 from HAE NAD83, a calculation must be performed at each point to acquire the difference between HAE and the Geoid. (NAVD88 Orthometric height = HAE – Geoid height).
You may be asking yourself why attention to this level of detail matters in gathering elevation data?
First, it is important to understand that the difference between HAE and orthometric heights utilizing a Geoid can range from a few meters to as much as 30 meters dependent on your location. Thus, it is important for users to understand the format of the data they are collecting. Esri explains these differences in this article on ArcUser.
For many users, that level of vertical accuracy might not matter so much as their focus is only the horizontal accuracy. But for many other users like utilities and construction groups, elevations are important. However, while some receivers may apply the full current Geoid12B model, many receivers apply a simpler less accurate Geoid model and return the value as “Mean Sea Level”. The question is, do you know what your receiver does to the elevation data it collects? (Apply no model, the full Geoid12B model, or modified Geoid12B model)
The Eos Arrow 200 and Esri’s Collector app gives the user more control over how they handle their elevational data. Collector captures the elevation position from the Arrow 200 (and many receiver models) as HAE and then uploads it to ArcGIS Online. Then, the user can allow the elevation data to remain formatted as HAE, or convert it to NAVD88.
If the user wants to convert their elevation data to NAVD88 and have that be their format of record, then there are a few steps to post-process their field collected data. First up, is the application of the Geoid12B model. The Geoid12B model can change the vertical elevation a significant amount over a short horizontal distance. This map below illustrates the spatial variation in the Geoid across the CSUMB campus. The map shows that from one side of campus to another (3 mi), there is as much as a 15cm (5.09 in) differential in the Geoid12B model. In other words, if we just took the standard HAE value from the receiver as is, our true elevation value could be off as much as 15 cm.
Adjusting HAE Data to NAVD88 – Geoid12B with ArcGIS Desktop
CSUMB worked with RS Geospatial to find an ArcGIS Desktop workflow to post-process field data to precisely convert field collected HAE elevations to NAVD88 orthometric heights. Utilizing ArcGIS 10.4, a toolset developed by ESRI for capturing elevations in Collector (ArcGIS Collector Utilities Toolbox www.github.com/Esri/collector-tools, and the Project-Z tool, users can now post-process their data in Desktop to adjust their vertical data with the Geoid12B model to match the exact location of collected data points.
Once you have applied the GNSS Metadata Capture to your Collector data fields and collected field data points, you can move to applying the Geoid12B model in ArcGIS Desktop 10.4.
- From ArcMap login to ArcGIS Online and Export your field data as a local copy.
- Run the Project-Z tool from the ArcToolbox.
- Input the correct Coordinate Systems and Output Coordinate Systems and run the tool.
The Project-Z tool will create a new (Z enabled) layer in the default database named “Geoid_Adjusted_Points” that has the geometry of the GNSS attributes from the originally hosted feature class. The elevation will also be converted from HAE to orthometric height (or MSL), but you will need to run the Add XY Coordinates tool to expose the Z field. We recommend then verifying that the coordinates were adjusted correctly.
The downside to this method is it is a post-processing step. Secondly, if the user needs the adjusted elevations in their ArcGIS Online database, the corrected data must be uploaded back to ArcGIS Online. A preferred fix would be for Esri to create the ability for users to add the current Geoid12B to collected data directly in Collector in the same way users can adjust the horizontal datums in the “Location Profile” settings. A different fix would be if the Arrow 200 and other external Bluetooth receivers applied the current Geoid12B to the elevation data before it was recorded by Collector. Either solution would be welcome for Collector users.
By Matt Alexander, RS Geospatial, LLC
This post is also available in: Español