Washington Cadastral Framework

Partnership Agreement

Attachment A



Cadastral Data Transfer Standard and Method



Overview

Any data that PARTNERS contribute to the Washington Cadastral Framework database must meet the Framework data criteria (listed below) and must be submitted in the format of the Cadastral Data Transfer Standard. Although only one format for the Cadastral Data Transfer Standard has been developed at this time, other allowable formats may be developed as part of the standard. The Cadastral Data Transfer Standard will allow PARTNERS to send data to, and receive data from the Washington Cadastral Framework database. Both spatial and tabular data will be exchanged. PARTNERS can also access the Washington Cadastral Framework database directly through ArcView or DBMS connect strings using their partner login identifier to read the data.



Framework Data Criteria

Washington Cadastral Framework Database Design

The Washington Cadastral Framework database will hold data considered to be:

Cadastral Data Transfer Standard

The Cadastral Data Transfer Standard is made up of two sets of files. The spatial data will be transferred in a shape file format, while the accompanying tabular data will be in ASCII flat files. A shape file and corresponding ASCII file should be created for each feature type (Parcel polygons, Legal Description polygons, Boundary lines, and Points). The features in the shape files will be keyed by sequential identifiers that will also be used to key the associated tabular records in the ASCII file.



Shape Files

The shape files are an ESRI standard format to hold spatial data features. Shape files require 3 types of files:

The shape files are created using an arc 'shape' command. The records in the shape file will be sequentially numbered to provide an association with the tabular attributes.



ASCII Files

For the Survey Data Transfer, four spatial data structures have been created: fw_parcel, fw_legal_desc, fw_boundary, and fw_point. Several tabular data files have been created: fw_document, fw_transaction, fw_parcel_land_right, fw_boundary_ty_code, fw_parcel_legal_desc, fw_parcel_agent_doc, fw_legal_desc_boundary, fw_legal_desc_point, and fw_point_boundary. The non-spatial files are the document table, the transaction table for the data contribution, attribute tables that go with the spatial tables, and relationships between the spatial tables. Each of the files corresponds to a portion of the Washington Cadastral Framework database. The Cadastral Data Transfer Standard files are denormalized to provide the required data fields while remaining flexible enough to easily accommodate multiple source data models. See each of the file attribute data formats for detail on their structures.



Parcel:

The parcel is the package of land that an agent has an interest in for conveyance of ownership, encumbrances, management, or administration. The land use rights and ownership rights go along with parcel to describe the interests that are bundled into the parcel as an additional table: Land Right. The Parcel Agent Doc shows the agents having interest in the parcel, and may also link to the source document that details the agreement.



See the FW_LAND_PARCEL Attribute Data Format for detail on the structure of this file.



Legal Description:

A Legal Description provides the structure for the delineation of the areal extent of land or water. These structures can be used to build legal descriptions based on areas.



The Public Land Survey System (PLSS) follows the pattern of Townships and Ranges established by the federal government of the United States in 1785 and it's successors. PLSS surveys were originally begun in 1785 on public domain lands and the rules for its use were defined by the authority of the U.S. Government.



Non-PLSS Described Areas are areas described by any other methodology or system. A Non-PLSS Described Area description can overlay a PLSS described area.



See the FW_LEGAL_DESC Attribute Data Format for detail on the structure of this file.



Boundary:

A boundary, frontier or border could all be considered to be the same thing. Border is most often used when discussing the boundary line between two countries. Frontier has been used more often when describing the unsettled portions of land. The discussion of a boundary is often referring to a line on a map separating one piece of land from another. It could also be a shoreline separating the uplands for the aquatic lands. It could also be a river separating one state from another.



An international boundary line may be the same boundary line as a state boundary line. A state boundary line may be the same boundary line as a county boundary line. A county boundary line may be the same boundary line as a city boundary line. A city boundary line might be the same boundary line as an individual ownership boundary line.



One boundary line could form the boundary for all of the above. One boundary line could form the boundary for only one or two of the above.



See the FW_BOUNDARY Attribute Data Format for detail on the structure of this file.



Point:

A Coordinated Point may be a Corner Point or a Geodetic Control Point. If geodetic quality coordinates are known or established for a Corner Point, the reference point is still a Corner Point. A Geodetic Control Point is established for no other purpose than geodetic control.



To analyze the validity of a reference point, a surveyor must know both current and historical information about that point. This historic information can go back further than statehood, since some of the federal General Land Office (GLO) surveys occurred on land, currently within the boundaries of Washington State, prior to the Enabling Act that formed the state-owned land base at the time of statehood.



See the FW_POINT Attribute Data Format for detail on the structure of this file.



Latitude: The angle which the normal at the Coordinated Point, projected to the ellipsoid, makes with the plane of the geodetic equator. Positive Latitudes will be understood to be the angle measured north from the equator. The ellipsoid used shall be the Geodetic Reference System of 1980 (GRS 80). The datum for coordinates shall be the North American Datum of 1983 (NAD 83). The unit for the Washington Cadastral Framework shall be the decimal degree.



Longitude: The angle at the Coordinated Point between the plane of the geodetic meridian passing through the Point and the plane of the Meridian of Greenwich. Positive Longitudes will be understood to be the angle measured east from Greenwich. The ellipsoid for determining Longitude shall be the Geodetic Reference System of 1980 (GRS 80). The datum for coordinates shall be the North American Datum of 1983 (NAD 83). The unit for Washington Cadastral Framework shall be the decimal degree.



Vertical Coordinate: The vertical distance from a datum to the Point. A vertical datum is any level surface (as for example, mean sea level) taken as a surface of reference from which to reckon elevations. The datum shall be the North American Vertical Datum of 1988 (NAVD 88). The unit shall be meter.



Transactions

It will be the responsibility of each of the Framework PARTNERS to develop encoding and decoding methods to transfer data from their own database systems into the Cadastral Data Transfer Standard for sending proposed changes to the Framework Server and back again for receiving Washington Cadastral Framework data. The PARTNERS will download spatial data into shape files, and tabular data into ASCII files. The ultimate goal is to have each organization contributing data which is developed from their proprietary operations to the Washington Cadastral Framework. The data contributions are extracts from their proprietary databases; the extracts will require minimum effort by the data providers to contribute on a regular basis.



The shape and ASCII transfer files will be sent to the Framework Server via FTP. When the transfer data is received on the Framework Server it will not go directly into the Washington Cadastral Framework database, but first be ported into an integration database. PARTNERS will receive notice of the proposed change and have an opportunity to view the new data in the Integration database before it is implemented in the Washington Cadastral Framework database. The Integration database will keep a history of all changes to Washington Cadastral Framework data for future reference or rolling back changes.



While the goal will be to automate as much of the transfer process as possible, it will be necessary for all of the participants to work together in their appropriate roles to allow the transfer to go smoothly. The focus of the data integration process is facilitate accurate and timely data integration to the Washington Cadastral Framework database while minimizing the amount of time that has to be spent by the Integrator on validating data and resolving errors while maintaining partnership control over the resolution process. We anticipate that there will be data integration issues from time to time that may require the input from several PARTNERS to resolve. The completeness and accuracy of data, and communication and consensus among the PARTNERS will determine how smoothly the data transfers.



Identifiers

All of the data in the Washington Cadastral Framework database will be keyed with a non-unique 'Fixed Framework Identifier'. These keys will be necessary to identify features for updating. The Bureau of Land Management (BLM) Geographic Coordinate Database (GCDB) codes will also be used to identify PLSS point features, and PLSS lines by endpoints.



Transaction types



Roles

Data Developer: Develops proprietary data sets.



Data Provider: Develops metadata for proprietary data sets.

Develops conversion procedures from proprietary data sets to the Cadastral Data Transfer Standard.

Shares data maintained within jurisdiction and authority.



Data Integrator: Assists Providers with developing conversion procedures to the Cadastral Data Transfer Standard.

Verifies data validation after data is checked in.

Notifies Providers and Stewards of integration errors and conflict problems.



Data Steward: Reviews metadata for proprietary data sets.

Determines authority and jurisdiction of Provider for integrating data into the Washington Cadastral Framework database.

Resolves data conflicts.



Database Administrator: Maintains the Washington Cadastral Framework database.

Backs up the Washington Cadastral Framework database.

Recovers the Washington Cadastral Framework database from the back-up.



Data User: Obtains data from the Washington Cadastral Framework database.