Utah County is evolving its tax parcel information to the new object data model that is available via ArcSDE and Oracle. This process began in 1999, and includes the transition from a librarian-based, dispersed data model to an integrated spatial object model. The process has involved data conversion, establishing temporary data storage techniques and building a new spatial data set. The data conversion process was complex due to Utah County's use of the COGO module to generate cadastral-based information.
In 1999, Utah County made the transition from a dispersed based GIS to an enterprise based GIS. This moved was made to improve the availability and management of its spatial data sets. Prior to making the transition to an enterprise GIS, the county had also decided to migrate to Oracle for its data management system for all other county functions. With these considerations, the county's GIS team began investigating available products that would meet the requirements of all of its users. These users include cadastral mappers, land appraisers and general analysts and technicians.
After meeting with various county departments to determine the requirements of the new enterprise GIS, the county began discussions with Esri about upcoming products that might help in the transition to an enterprise GIS. One of the first products that was mentioned was ArcInfo 8.0 and ArcSDE 8.0. Specifically ArcSDE would allow the county's GIS to interface with Oracle, and allow the county to transition over to the new geodatabase model.
As not too much was known about the geodatabase and ArcSDE 8.0, the county decided to join the beta test group for Esri. This allowed the county to preview the functionality of the new spatial data set. Early on, the county decided to begin preparing for the transition to ArcSDE by transitioning its parcel library to a parcel catalog.
The concept for this parcel catalog was based upon the image catalog concept. The first step was to figure out how to move the parcels being stored in librarian over to a basic feature, such as a polygon coverage. Since the county uses COGO, it was determined that the most accurate method would be to extract the COGO code files from the county's database and re-generate the coverages from the files. This would avoid the problem that exists with the county's parcel library.
The problem with the parcels in librarian deal with data synchronization. The problem arises when the county's cadastral mappers use the COGO module to generate a coverage from legal descriptions. Once this COGO coverage is generated, a code file containing the appropriate COGO items is sent to the county's database and the cadastral line coverage is sent to librarian. At the same time a polygon coverage is created and loaded to the library for analytical purposes. The error occurs when editing is performed on the coverages without editing the COGO code file being stored in the database. This occurs rather easily since no tool exists to ensure the data is synchronized.
So, although the errors that exist in the COGO code files that were fixed in the coverages would be re-generated in Oracle by using the code files, the county determined this was the best method to ensure data base integrity. Once this determination was made, the county then needed to begin designing an appropriate data base structure. The structure had to account for all the items associated with COGO and other information associated with the tax parcel, such as date created and date killed.
After months of brain-storming and testing, a data structure was developed. This structure came to be known as the parcel catalog. In essence, this data structure was comprised of polygon coverages for all parcels that would include polygon and line attributes, such as serial number, that were related to data tables that contained information relating to the cadastral elements, such as traverse information. With this structure in place it was time to begin putting information into the parcel catalog.
To do this the GIS team needed to extract the appropriate COGO information from the county's data base. This was accomplished by obtaining a list of effective serial numbers and building an arc macro language application to retrieve the COGO information from the database. Once the data was extracted, the program built the appropriate polygon coverages and attributed the associated data tables. Although the program worked flawlessly, problems were encountered that were associated to system limitations.
The first attempt tried to write all the coverages to a single unix partition that was approximately 10 gigabytes in size. The program shut down due the number of files that can be stored within a single INFO directory. Once this problem was overcome , the second major problem dealt with the limitations on the number of sub-directories that can be stored within a single partition/directory. To overcome both of these issues, the county created several 2 gigabyte partitions/directories that ensured neither limitation would be encountered.
Once the program was run, individual polygon coverages were generated for each serial number in the list. If a parcel was composed of several polygons then several coverages were generated. Using this method, coverages were ultimately generated for all the serial numbers that had COGO information. These dated back to 1992, when the county deployed the COGO module for cadastral mapping. Once these coverages were complete, it was possible to query them using customized amls and arcplot.
The next step was to take all these coverages and migrate them over to ArcSDE and Oracle. Several attempts were made throughout the beta testing period and once ArcSDE 8.0.1 was released. The process took the individual polygons and created two feature classes for them, one a polygon feature and the other a line feature. The line feature is necessary for the cadastral elements of the tax parcel. In addition, the tables were converted from INFO to Oracle.
Once the feature and object classes were imported into ArcSDE, several programs were written to maintain and load newly created tax parcels to the data base. These programs will eventually allow "real-time" access to the parcel information. This has been a priority goal for the county for several years. Without ArcSDE, "real-time" access would not be possible since the daily work of the cadastral mapper would not be in an area that is accessable to an internet map server.
Since the initial load, Esri has assisted the county in optimizing both the Oracle and ArcSDE install to make sure the system is able to query and display the parcel information in a timely and accurate manner.
Currently the ArcSDE database is being maintained in conjunction with the parcels in librarian. Further data cleaning needs to occur before the ArcSDE database will entirely replace the parcel library, but this is due to the quality of the information that was loaded into ArcSDE and not the fault of the program.
Prior to this full transition, different components of the county's new enterpise GIS will be implemented that will utilize ArcSDE. This includes ArcIMS and new customized applications using Visual Basic and Visual C++.
To date, the parcel catalog within ArcSDE and Oracle has proven a very effective means for maintaining tax parcel information.
I would like to thank Bert Miller (Utah County GIS Manager), Brent Hoskission and Jay Kim (both GIS Programmers) for their assistance with this presentation.