Each parcel may comprise one or more tracts and thus may be represented by one or more features (polygons) in the spatial database. Multiple tracts may occur as a result of multiple acquisitions over time, single acquisitions from multiple owners, and/or a parcel that is bisected by a road or other base feature.
The data are available both in personal geodatabase format (.mdb) and in shapefile format (.shp).
As of 2001/2002, the entities responsible for the development of the data set include: OSP (collection, compilation, and automation of state/federal lands), the regional planning agencies (collection, compilation, and automation of municipally-managed parcels), SPNHF (collection and compilation of Forest Society Lands), and CSRC (collection, compilation, and automation of all other protected lands, and integration of all contributions into a seamless, statewide data set).
The process starts with the collection of source information (PARCELSOURCE) from agencies protecting/managing parcels in the state. Protecting agencies typically include state/federal organizations, county/municipal agencies, land trusts, watershed associations, and other non-profit organizations. The protecting entity is asked to provide the best available source map, and the associated descriptive information, to the organization responsible for parcel compilation (SPNHF, OSP, an RPA, and/or CSRC).
The organization recompiling the tract/parcel information must typically re-scale the source maps to achieve the target compilation scale of 1:24,000. This is accomplished via traditional copying machines with variable reduction capabilities. (For data that is digitally transmitted (e.g. DXF/DWG files), this step is omitted.) Once the source parcel is scaled appropriately, the parcel boundaries are recompiled onto 7.5-minute quad-based mylars. Prior to the late 1990's, these mylars displayed DLG-3 source data and any existing parcels in the data base. More recently, the DOTROADS data have replaced the DLG-3 roads.
During recompilation, tract/parcel boundaries that are coincident with any base features are flagged appropriately. Color codes are used to indicate whether the intended coincidence is with a base map road, surface water feature, town boundary, etc.
When new parcels are mapped that share boundaries with existing tracts/parcels, the compiler must select the best boundary to utilize. In these instances, attribute data (e.g. SOURCE, ACCURACY, etc.) associated with the existing and the new parcel are reviewed, and a determination is made.
The recompiled boundaries are then digitized, using standard GRANIT automation tolerances. This automation may take place at several locations (as noted above). During the digitizing phase, all flagged, coincident boundaries are replaced with the appropriate base feature from the GRANIT database. This ensures consistency of the resulting tracts/parcels with the GRANIT base layers. Boundary arcs and polygons are then coded. If the automation is handled by OSP or a regional planning agency, the new parcels are submitted to GRANIT for final review and incorporation in the statewide layer.
Checkplots are generated as each quad is updated, to ensure the accuracy of the linework digitizing and arc/polygon coding. Attributes are entered and verified through visual checks and by processing against valid domains. Note that certain attributes have been added since the original template was defined. As a result, not all fields will be populated for all records.
Further information on the derivation of the data set, and the standards utilized, may be obtained from the GRANIT database manager at CSRC.