Executive Summary
The Parcel Fabric technology behind ESRI’s Parcel Editing Solution, differs from the standard feature classes used within ESRI’s geodatabases in many ways. The Parcel Fabric, looking to develop a more structured and integrated land records solution, incorporates all the traditional thematic layers used by land records, together with auxiliary functional feature classes to provide a more complete solution that provides for creation, maintenance, history, metadata and adjustment layers required in a production environment to ensure the “mappers” have at their immediate disposal a complete resource for cadastralists. This structure, while being optimized for land record maintenance places a much more rigorous demand on computer resources. This short discussion will explore some of the demand points.
Integrated Feature Classes
The Parcel Fabric, in order to integrate the various thematic layers and make the validation of “topology” between the traditional features, manages the features differently. Rather than maintaining a multitude of feature classes, each having separate. discrete thematic feature classes, groups all features in the Parcel Fabric by geometry type, or “the type of geometric elements they represent such as polygon areas, line features and point features” rather than “the type of geometric features that represent, such as PLSS Township, Sections, Subdivisions, Lots, Tax Parcels, Encumbrances and Other areas, along with each layers corresponding lines and points”. By reducing the number of feature classes included in the Parcel Fabric, it simplifies the structure, ensuring all features share the same spatial reference and connectivity, but using attribution to differentiate between the elements they represent.
This unification of geometry types complicates the search and display operations of the Parcel Fabric by having a greater number of features that must be searched through for record retrieval. This integration is one reason why the creation, optimization and constant maintenance of the spatial indices with the feature dataset containing the Parcel Fabric is critical.
Relational Data Structure
Within the Parcel Fabric, all geometric feature classes, together with additional auxiliary operation feature classes and tables, are related to one another. The Parcel Fabric can be thought of as a “geometric network” for polygons. Each polygonal record contains a complete set of lines that were used to create the polygon boundary, together with a corresponding record in the plan table containing the source data metadata and relates to all corner points that contain information about how the polygon corners are “linked” or “joined” together to define the spatial location and geometry of the polygon. As such, operations requiring the retrieval of a single record requires that that single record, and all related features must be retrieved to provide the Cadastralist with necessary information of every element related to that polygon. This intensified retrieval of single, al all related records places a much greater demand on the ability of the Parcel Fabric to index, search and retrieve the database records.
Editing Integrated Records
Because all records in the Parcel Fabric are related to corresponding line and corner records, editing the Parcel Fabric in a multi-user editing environment such as ESRI’s SDE versioning environment is highly transactional. Within the SDE editing environment all changes to the tables, including adding records, deleting records or modifying records place “temporary” records in the “Change or Delta” tables that represent the “pre-committed”, or “posted”, data changes. Since all records have these multitude of of related data associated with them, the Parcel Fabric will create or delete these associated features every time any change occurs to a polygonal record. For example, a simple modification of the location of a single point requires that all polygons, including polygons that are considered on other “layers” such as PLSS layers, subdivision layers, lot layers, easement layers, along with those lines connected to that corner, must be deleted from the Change table and added back into the change table to reflect that one simple move. While that one simple move in a simple feature class may be represented by a delete and an add, in the Parcel Fabric, this one change may be represented by 30 or so deletes and 30 or so adds into these same Change tables. The more the data is edited in the Parcel Fabric, the larger and more cumbersome the Change tables become.
For this reason, ESRI restricts the levels of versioning in the Parcel Fabric to only one level and highly recommends that maintenance on the Change tables be performed daily using the “analyze” geoprocessing tool to reduce and compress the number of redundant “state’ records contained in the Change table. ESRI also recommends that all versions be reconciled and posted to the Default database state as quickly as possible.
Possible Implementation Scenarios
Taking into consideration the impact of the Parcel Fabric on the operations of the enterprise Geodatabase, there are several implementation recommendations.
Segregated Implementation - The purpose of the Parcel Fabric is solely the creation, maintenance and production of land record information and the publication of this data should NEVER be performed from this highly integrated data structure (the Parcel Fabric). Rather, the data should be extracted, transformed and loaded into a publication data structure, while this implementation is often performed on the same server, just into separate feature datasets, one alternate suggestion some of our clients have taken is to segregate the entire Parcel Fabric structure and the geodatabase containing the Parcel Fabric onto a separate database server. The exact configuration and implementation strategy is completely depend upon the organization's infrastructure and deployment strategy.
Optimized Hardware - Since the Parcel Fabric technology is highly transactional in nature, optimization of Input / Output is critical to success. This points to the recognition that much of the demand of resources for the Parcel Fabric in a multi-user database is not computational, but is the increased demand on the searching and retrieval of all the related records contained with the Parcel Fabric. We have had several clients successfully realize the greatest return on investment by configuring the data server sufficient memory and with solid state drives to optimize the I/O functions contained therein.
Summary
Governmental agencies using taxpayer funds to pay for their internal systems need to justify expenditures, but, in the case of the Parcel Fabric, it often makes more sense to spend additional funds to optimize the IT configuration for the use of the Cadastralists.
