Improving Cadastre: Development of a Workflow Prototype Utilizing ESRI's Parcel Fabric

INTRODUCTION Efficient and effective management of limited resources, such as land, is becoming more and more important as the United States continues to grow and development densities compound. Rapid City, South Dakota, not unlike many other communities, uses geographic information systems (GIS) to manage its land records (cadastre1) and other spatial information. For example, its parcels dataset is used to maintain ownership and tax information, record zoning and other planning designations, track annexations, maintain corporate boundaries, and develop future land-use plans. To date, the cadastre parcels are a representation containing accurate attribute information about the land such as area, ownership, and tax value. Historically, there was no need for accurately surveyed spatial data because it was developed primarily for taxation purposes and little if any other relevant spatial data existed. However, in recent years, additional datasets such as high-quality aerial imagery and sanitary sewer infrastructure have been developed with high positional accuracy. These layers are constantly under consideration by engineering and planning staff, and when plotted with base layers, such as the parcels, disparities in accuracy between the datasets become apparent, thus highlighting the need to improve the accuracy of the cadastre layer. Two layers in particular are driving the city's interest in improving its parcel base: zoning and future land use. Having these layers available and up-to-date would increase staff efficiency when reviewing development submittals, improve customer service by having the data accessible to the public, and help expedite planning and engineering studies. History of Cadastral Dataset of Rapid City The original cadastral dataset for Rapid City was developed in 1989 (see Figure 1 for overview) from plats at three scales and adjusted to U.S. Geological Survey (USGS) 7.5 minute quadrangle section corners resulting in some errors. From 1989 through 2000, parcels were added by digitizing and using coordinate geometry (COGO) input methods. Rectified but not ortho-corrected aerial images also were used to help align the property lines. As new imagery was acquired, many lines had to be adjusted, especially in areas of high relief (Rapid City GIS Division 2009). In 2000, the parcels were converted to the Environmental Systems Research Institute (ESRI) ArcInfo Coverage format, and again some errors were introduced. According to the GIS Division staff, there was reasonably good conversion of the data in the eastern half of the county but less so in the western half (Rapid City GIS Division 2009). Not only were errors introduced during the conversion, but sometime after the project was finished, it also was discovered that the conversion vendor incorrectly moved section lines to match the digital line graph (DLG) section lines, rather than moving the parcels to the correct section. In addition, water boundaries were erroneously incorporated to represent parcel boundaries. In 2003, the ESRI ArcInfo parcel coverages were converted into one contiguous countywide ArcSDE feature class. Maintenance of the parcels has continued using ESRI's ArcMap desktop software by COGO input and other editing techniques. From the original development of the parcels dataset through the conversions discussed above, errors have been introduced and continue to be propagated. Even the current methods used for updating and maintaining the data introduce, if not maintain, error in the dataset. For example, when an area is newly subdivided, the surveyor of record's platted information is reproduced digitally using software with coordinate geometry (COGO) input capabilities. Data integrity then is often compromised so that the shape(s) can fit into the area available in the parcel layer instead of being truly represented. [FIGURE 1 OMITTED] [FIGURE 2 OMITTED] Historically, one of the main factors limiting spatial accuracy in GIS systems was the capacity of hardware and software and their inability to handle geodetic coordinate systems effectively. …