A 421Kb PDF of this article as it appeared in the magazine—complete with images—is available by clicking HERE
The PLSS as a GIS Control
In April 2000 by the Western Governors Association adopted the Bureau of Land Management’s Geographic Coordinate Database (GCDB) as the preferred representation of the Public Lands Survey System (PLSS) for GIS applications. This is significant in the western states where most land ownership and stewardship boundaries and administrative boundaries are based on or referenced to the PLSS. That means that any GIS data of those boundaries must use the PLSS as the mapping framework. It is important to standardize on a single representation of the PLSS in order to integrate GIS and mapping data that come from a variety of sources. The BLM’s GCDB program sought to create a single source PLSS database that could serve to unify cadastral GIS information across the western United States. The GCDB, as implemented by the BLM and as adopted by the Western Governors Association does meet that requirement, and the GCDB is now available for most of the western states.
There are, however, some challenges that emerge when using the GCDB as a control framework for GIS data. The first challenge is how to move existing data from a non-GCDB PLSS framework to the GCDB framework. The second challenge is how to readjust data that are tied to the GCDB when the coordinates of PLSS points in the GCDB change due to accuracy improvement projects. The State of Montana has an aggressive program to improve the spatial accuracy of the statewide cadastral dataset by improving the coordinate accuracy of the GCDB.
A third challenge is actually developing the tools to do the adjustment. As early as 1998 the Montana Department of Administration contacted Environmental Systems Research Institute (ESRI), asking them to integrate GCDB/ GIS adjustment tools into their software. Releases of ESRI products like ArcSurvey and Survey Analyst made attempts to provide adjustment tools but those tools were never entirely successful for Montana’s purposes. In October 2004, ESRI’s Mr. Tim Hodson, who was involved in survey-related software development at the time, visited Montana to review and discuss these issues. On his flight home Mr. Hodson wrote a short GCDB/ GIS adjustment script which operates on the principle of linking the positions of original GCDB point IDs with new GCDB point IDs and moving the associated geography of the feature class or classes to the new GCDB point location. This script can also work with non-GCDB GIS databases provide that points within those databases carry a unique identifier attribute. While some additional tool enhancements would facilitate and standardize these types of adjustments, the script, as written by Mr. Hodson is the core utility referred to in the adjustment procedures outlined in this document.
Overview of Spatial Issues When Referencing GIS Data to the GCDB
GIS datasets may be based on the PLSS (and other features). There are many versions of the PLSS, though, for the most part, none are as accurate as the BLM’s versionthe GCDB. And the GCDB is the official version of the GCDB (as endorsed by the Western Governors Association).
Non-GCDB versions of the PLSS are usually not coincident. Typically this is because early versions of the PLSS were hand digitized from various map sources, such as the USGS topographical map series.
Because PLSS datasets rarely align well with the GCDB, any GIS boundary data that is controlled by a nonGCDB PLSS, will also not align with the GCDB. Figure 1 shows an example GIS data set that does not align with the GCDB because it was originally mapped to a non-GCDB PLSS data set.
This map shows a boundary layer (orange lines) that was registered to a 1993 (non-GCDB) PLSS layer. It does not align with the GCDB (black and gray lines).
Overview of the GCDB File Contents
The GCDB contains points for corners of townships, sections, and quarter sections, and may also contain other points (e.g., 1/16 corners, or meander corners). The GCDB points serve as the control for registering GIS layers to the PLSS. That is, GIS points, lines, or polygon vertices can be snapped (made geometrically coincident) to the GCDB. (Alternatively the GCDB line and polygon geometry can be used as boundary primitives from which to construct more complex geometries.)
GCDB points are the basis for doing spatial accuracy improvement adjustments—that is, the points form the control reference points. Each GCDB point has a unique identifier attribute (PLSSID) which is universally unique for every point in the nation. For more information on the GCDB file contents, see www.blm.gov/wo/st/en/prog/more/gcdb.html. For more information about the GCDB identifier naming schema see Nancy Von Meyer’s document on www.nationalcad.org (http://www.nationalcad.org/data/documents/BLMPointID-standard-summary.pdf ).
Other boundary elements that are not PLSS features may include roads, rivers, and topographical elements or administrative areas. A typical legal description may reference roadways, rivers, topographical features (e.g., the Continental Divide) and other features in addition to the Public Lands Survey System.
Meeting the Challenges of Conforming GIS Data to the GCDB
The challenges of integrating PLSS based datasets with the GCDB can be met by performing a two-dimension ordinary least-squares transformation (aka rubber-sheeting) process. This process uses coordinate values for a before (old) control data set, and coordinate values for an after (new) control data set, to calculate the change vectors (magnitude and direction of changes) by which the GIS data set is transformed. This type of adjustment will alter the geometry of the GIS datasets by varying magnitudes and directions based on each GIS vertices’ proximity to the change vectors. (note: GIS vertices are the angle points for the GIS lines and polygons). See Figure 2.
An additional consideration when performing the transformation of a GIS dataset to the GCDB or to a re-adjusted GCDB, is that many boundary layers contain non-PLSS references, such as rivers, mountain ridges, roadways, etc. which are not represented in the GCDB. The non-PLSS boundary segments typically should not move, when adjusted to the GCDB or re-adjusted to a new GCDB. Moving a boundary layer, such as a fire district boundary to the GCDB may require freezing, or holding fixed in place, the non-PLSS segments. Holding these non-PLSS segments fixed in place, presents its own set of challenges when using any sort of automated transformation process. This document outlines recommended procedures for dealing with these challenges in the hope of simplifying and standardizing the process to make GIS data match the GCDB. Note: this document does not address the initial registration of new GIS data to the GCDB because the methods to do this are similar to registering new data to any other control data set (e.g. snapping features of one data set to another existing data set).
In general the solution to fixing the non-PLSS positions so that they do not move, is to create two sets of control points for them that have duplicate IDs and duplicate coordinates in the transformation control point files. Because the rubber-sheeting method does not permit weighting, the recommended method for constraining certain areas or features to their original position, that is fixing their positions, is to ensure that the points hav
e the same coordinates in the New control file as they do in the Old control file. One way to do this is to simply copy their IDs and coordinates from the Old control to the New control. The process of fixing positions can be applied to any feature or parts of features that are based on mapping controls that are superior in accuracy to the GCDB point positions.
The Possible Scenarios
There are four possible scenarios delineating the relationship of the GIS data to the GCDB. See Figure 3. Each scenario prescribes an individual approach to resolving its particular challenges in integrating the GIS data with the GCDB.
Scenario A1–GIS data are registered to the GCDB and must be readjusted to a new version of the GCDB.
Scenario A2–GIS data are registered to the GCDB and other features, and must be readjusted to a new version of the GCDB (and other features).
Scenario B1–GIS data are registered to the PLSS and must be registered to the GCDB.
Scenario B2–GIS data are registered to the PLSS and other features, and must be registered to the GCDB (and other features).
Description of Each Process to Solve the Transformation Challenges
A. GIS DATA THAT ARE ALREADY REGISTERED TO THE GCDB
Scenario A1: GIS data are registered to the GCDB and must be readjusted to a new version of the GCDB.
Setting: The GIS data are tied to an existing GCDB, and the GCDB for the area of the GIS data has been adjusted to new coordinates, therefore the OldControl exists as the old version of the GCDB, and the NewControl is the adjusted version of the GCDB.
Process: Use the old GCDB as "OldControl" and the new GCDB as the "NewControl" to rubber sheet the GIS data to fit the new GCDB.
This is the simplest and most straight forward to deal with.
Scenario A2: GIS data are registered to the GCDB and other features, and must be readjusted to a new version of the GCDB.
Setting: The GIS data are tied to an existing GCDB, and the GCDB for the area of the GIS data has been adjusted to new coordinates, therefore the OldControl exists as the old version of the GCDB, and the NewControl is the adjusted version of the GCDB. Additionally, the GIS boundary also follows non-GCDB features, and these have not been adjusted, therefore, the GIS boundaries that follow the nonGCDB must stay in the same place. Process: Use the old GCDB and the vertices of the other features (giving the other features dummy gcdbIDs) as the "OldControl" and the new GCDB plus the same vertices of the other features (copied directly into the control file so that the coordinates of the other features are identical in the OldControl and NewControl files) as the "NewControl".
B. GIS DATA THAT ARE NOT ALREADY REGISTERED TO THE GCDB
Scenario B1: GIS data are registered to the PLSS and must be registered to the GCDB.
Setting: The GIS data are not tied to an existing GCDB therefore the OldControl must be created from the GIS vertices and the NewControl is the GCDB.
Process: Use the vertices of the GIS data set as the "OldControl", assign these points GCDB IDs by performing a spatial join to the GCDB points near them (that they should match to); use the GCDB as the "NewControl".
Scenario B2: GIS data are registered to the PLSS and other features, and must be registered to the GCDB.
Setting: The GIS data are not tied to an existing GCDB, and the GIS data has boundaries that are non-PLSS therefore the OldControl must be created and the NewControl is the GCDB. Additionally, the GIS boundary also follows non-GCDB features, and these have not been adjusted, therefore, the GIS boundaries that follow the non-GCDB must stay in the same place.
Process: Use the vertices of the GIS data set and the vertices of the other features, as the "OldControl", assign the PLSS related points GCDB IDs by performing a spatial join to the GCDB points near them (that they should match to), and assign dummy IDs to the non-PLSS points; use the GCDB, and a copy of the "other" features’ vertices as the "NewControl".
Other Considerations
TRANSITION AREA BETWEEN PLSS AND NON_PLSS BOUNDARIES:
Some additional editing might be necessary after the adjustment when non-PLSS features are boundaries because the linkages from the PLSS to the non-PLSS may be modified by the adjustment. Careful inspection of the adjusted data is very important for data integrity. For example, where a boundary follows a section line to a river as shown in Figure 4, the boundary line coming into the river may move to the new GCDB location. This sometimes creates a new vertex and new line as shown in the detail in Figure 5.
Adjusting the PLSS portion to the GCDB, but holding the river boundary fixed, may be introduce geometry changes such as shown in Figure 5. These types of transition areas must be inspected and dealt with on a case by case basis, and the procedure to deal with the geometry will depend on the descriptions of the boundary.
Author Note: Thanks to Keith Blount, GISP, of the Montana Base Map Service Center for his assistance with the research and testing of the methods described in this article. For more information go to the Montana GIS Coordination website http://giscoordination.mt.gov/ under the Cadastral framework page.
Rj Zimmer is Director of GIS and Mapping for DJ&A, PC of Montana, an engineering, surveying, and mapping consulting company. Stewart Kirkpatrick is the Montana State GIS Coordinator in the State Of Montana Base Map Service Center.
A 421Kb PDF of this article as it appeared in the magazine—complete with images—is available by clicking HERE