The Washington State

Cadastral Framework Demonstration Project - Phase 1

Final Report



December 1998

































Prepared by:



Carrie Wolfe

Washington Department of Natural Resources

Information Technology Division

PO BO X 47020

Olympia, WA 90504-7020

Phone: 360-902-1639

E-mail: carrie.wolfe@dnr.state.wa.us



Greg Tudor

Washington Department of Natural Resources

Information Technology Division

PO BOX 47020

Olympia, WA 98504-7020

Phone: 360-902-1542

E-mail: greg.tudor@dnr.state.wa.us



Table of Contents



Project Summary.............................................................................................................. 5



Background....................................................................................................................... 6



Introduction ...................................................................................................................... 6-7



Milestone Tasks ................................................................................................................ 7-26



1. Provide Project Oversight............................................................................... 7-8

Approach Taken ....................................................................................... 7

Outcomes ................................................................................................... 7

Lessons Learned ....................................................................................... 7-8



2. Examine Business Events/Situations.............................................................. 8-10

Approach Taken........................................................................................ 8

Outcomes.................................................................................................... 8-9

Lessons Learned........................................................................................ 9-10

3. Model Business Processes................................................................................ 10-11

Approach Taken........................................................................................ 10

Outcomes.................................................................................................... 10-11

Lessons Learned........................................................................................ 11



4. Model Cadastral Framework Data................................................................. 11-16

Approach Taken........................................................................................ 11-12

Outcomes.................................................................................................... 12-15

Lessons Learned........................................................................................ 15-16



5. Implement Agreements for Establishment and Maintenance of Data........ 16-17

Approach Taken........................................................................................ 16

Outcomes.................................................................................................... 16-17

Lessons Learned........................................................................................ 17



6. Detail Organizational Requirements.............................................................. 17-19

Approach Taken........................................................................................ 17

Outcomes.................................................................................................. 18

Lessons Learned...................................................................................... 18-19



7. Evaluate Technology...................................................................................... 19-20

Approach Taken...................................................................................... 19

Outcomes.................................................................................................. 19-20

Lessons Learned...................................................................................... 20



8. Load Initial Data into the Cadastral Framework Data Model.................. 20-22

Approach Taken...................................................................................... 20-21

Outcomes.................................................................................................. 21

Lessons Learned...................................................................................... 21-22



9. Develop Metadata and Post to the Internet................................................. 22-23

Approach Taken...................................................................................... 22

Outcomes.................................................................................................. 22

Lessons Learned...................................................................................... 22-23



10. Post Cadastral Framework Data to the Internet....................................... 23

Approach Taken....................................................................................... 23

Outcomes................................................................................................... 23

Lessons Learned....................................................................................... 23



11. Promote Cadastral Framework Demonstration Project........................... 23-24

Approach Taken....................................................................................... 23-24

Outcomes................................................................................................... 24

Lessons Learned....................................................................................... 24



12. Assess Cadastral Framework Demonstration Project............................... 25

Approach Taken....................................................................................... 25

Outcomes................................................................................................... 25

Lessons Learned....................................................................................... 25



13. FGDC Reports and Meetings....................................................................... 25-26

Approach Taken....................................................................................... 25-26

Outcomes................................................................................................... 26

Lessons Learned....................................................................................... 26



Future of the Project ........................................................................................................ 26-27



Conclusion ......................................................................................................................... 27-28



References ......................................................................................................................... 29-30



Attachments



Framework Management Group Charter ............................................... Attachment A



Cadastral Framework Project Charter.................................................... Attachment B



Requirement Input Document................................................................... Attachment C



Partner Narratives and Project Expectations.......................................... Attachment D



Technical Workgroup Meeting Minutes.................................................. Attachment E



Business Process Model.............................................................................. Attachment F



FGDC Cadastral Data Content Standard Model-Modified................... Attachment G



Partner Modeling Session Result Summary............................................ Attachment H



Land Survey Definitions............................................................................ Attachment I



Logical Data Model.................................................................................... Attachement J



Roles and Responsibilities......................................................................... Attachment K



Firewall Alternatives................................................................................. Attachment L



Technology Diagram................................................................................. Attachment M1



Technology Narrative................................................................................ Attachment M2



Physical Data Model (survey and parcel)................................................ Attachment N



Phase 1 Evaluation Form.......................................................................... Attachment O

















PROJECT SUMMARY



The Washington Cadastral Framework Demonstration Project is an ambitious effort that tests an inter-organizational partnership approach to create, manage, and distribute commonly needed cadastral data. Partnerships include a cross section of federal, state, local, and private organizations. Each partner contributes funds, in-kind hours of service and input, geospatial data, or some combination thereof.



Cadastral data are defined as the geographic extent of the past, current, and future rights and interests in real property including the spatial information necessary to describe that geographic extent. Rights and interests are the benefits or enjoyment in real property that can be conveyed, transferred, or otherwise allocated to another for economic remuneration. (FGDC, Cadastral Subcommittee, 1996, December.) Cadastral data are the backbone of most data in Geographic Information Systems (GIS).



Typically, cadastral records are kept by public and private surveyors, county recorders, county tax assessors, land title companies, private land management businesses, private land agents, and government agencies entrusted with public lands. Each organization keeps the records which are necessary to conduct its business. Surveyors measure and describe land; they keep records of their surveys and legal descriptions. Counties are responsible for publicly recording business transactions including conveyances, easements, leases, and sales from the land, and they keep these records. County tax assessors are interested in the value and usage of land as the basis of local government revenue. Land title companies duplicate the records of land transactions and add value by spatially indexing those transactions. Private land managers, such as timber, railroad, and mining companies, along with government agencies managing public lands, must track the extent of their large and dispersed holdings and must also track any encumbrances and restrictions placed on those holdings which limit the use of the land. Private land agents, such as developers and realtors, watch the transactions of land closely for investment and marketing. Each organization keeps a specific and detailed proprietary database of its business interests. All of these organizations conduct business among each other, and many are interested in communicating their land holdings and transactions to facilitate their business operations.



The long term goals of this project are to develop a basic information standard of communication for land holdings and transactions, create a common statewide database of cadastral information, and implement a method of communicating cadastral information between organizations and the common database. This demonstration project is the first phase of this multi-phased effort. Phase 1 development includes the following: collection of business requirements from participating partners, determination of business processes, development of a statewide cadastral framework data model, initial data population of the new model, metadata creation, and distribution of the framework data and metadata over the Internet. The data model is based on the Federal Geographic Data Committee (FGDC) Cadastral Data Content Standards, but with some revisions, extensions, and implementation details.



BACKGROUND



The Washington Department of Natural Resources (DNR) has played a leadership role, as well as a partner role in this project. As a partner, the DNR has many interests in the Cadastral Framework Project. The State Land Survey Office (SLSO) of the DNR maintains a statewide data set of the Public Land Survey System network, corners, and state ownership parcels. The Land Records Sections maintains the documentation of state land transactions and is in the process of building a data set. The Resource Mapping Section of the DNR collects ownership, administration, and management information from other public agencies and maintains a data set of major public lands inventory. The Aquatic Land Ownership Section is building a data set of the aquatic subdivisions of land and state ownership parcels. All of these data sets will be contributed for integration with the framework cadastral database.



The DNR has a great interest in improving the quality of spatial data and developing standards for distributing spatial data in general. Active participation in many geographic information system cooperative initiatives has helped to set standards of spatial data communication, integrate spatial data sets, and provide methods of accessing spatial data sets. As a member the Washington Geographic Information Council (WAGIC), the DNR has been actively providing direction for improving government geographic information products and services. In the DATA96 project initiated in 1994, the DNR worked with private, tribal, local, state, and federal organizations to complete existing transportation, hydrography, land survey, and topography data sets. The data was put into a common format and distributed to the partners. The WAGIC was awarded an FGDC grant for the Washington Clearinghouse in 1995. The clearinghouse is a searchable national catalog of metadata allowing users to find existing data sets and their data sources.



The Washington Framework Management Group (FMG) was initiated in 1996 to direct the implementation of the National Spatial Data Infrastructure (NSDI) framework strategy within Washington state. The FMG was charged with coordination and facilitation of the statewide geospatial framework. Participants of the FMG include representatives from federal, state, local, private, and tribal organizations. The Cadastral Framework Project and Hydrography Framework Project were identified as high priority targets for Washington framework development. Later, the Washington Transportation Framework Project was identified for development. The DNR created a framework coordination work unit in 1997 to support the FMG and facilitate and coordinate framework projects. In 1998, the FMG was recognized as a subcommittee of the WAGIC (see Attachment A).

INTRODUCTION



With the DNR playing a leadership role in supporting the Framework Management Group, work began on the Cadastral Framework Project as the highest priority. The DNR began recruiting partners, started scoping the project, and hired a project manager to plan and oversee the project development. A project charter was developed (see Attachment B). Thirteen milestone tasks were identified in the original project proposal submitted to the FGDC. For the purpose of this report, each milestone task will be listed with three subsections that include; 1) the approach taken to accomplish the task, 2) the outcome of the task, and 3) the lessons learned in the process. Following the milestone task information, there is a section on the future of the project.



MILESTONE TASKS



1. Provide Project Oversight. The Washington Framework Management Group (FMG) will meet regularly to provide administrative, subject matter, and technical guidance.



Approach Taken to Accomplish Task



The FMG started meeting in April of 1996. Meetings are now held quarterly. The DNR Framework Coordinator position is responsible for coordinating the meeting agendas. Status reports of the framework projects are a regular agenda item.



Five FMG meetings took place during the course of this demonstration project. Discussion topics and guidance covered such areas as framework data criteria development, feature maintenance scenarios and recommendations, incentives for local government participation, budget planning for framework projects, and quarterly project status reports. Another issue that was identified in these meetings was the need for state legislative exposure regarding framework projects.



Outcomes

The FMG provided excellent input and feedback on framework development issues. Membership and participation increased steadily over the past year. That allowed for a greater diversity of perspective on framework issues to be voiced.



As the group matured and progressed in the oversight of various framework projects, it became apparent that a more formal group organization definition and decision making process was needed. As a result, a subgroup formed to look at alternative organizational relationships and decision making processes. A product of that effort was the development of a group charter (see Attachment A). The charter outlines the group purpose, key objectives, measures of success, a formal organizational structure, roles and responsibilities, and decision making processes. The charter was approved by the FMG and the WAGIC.



Lessons Learned

1. When working on a project with a large group of different organizations, it pays to identify a clear decision making process and an oversight body for out-of-scope project decisions.



2. Examine business events/situations. The cadastral framework will be established to respond to the business events/situations of partner organizations and others. These business events/situations will be identified. A plan will be developed to test how well the cadastral framework responds to these events/situations. The plan will identify who, when, and where testing will occur.



Approach Taken to Accomplish Task



There were three main approaches taken to complete this task. First, a Requirement Input Document was mailed out to the participating partners. The input document had three main parts. The first section asked some general questions such as contact information, software usage, acceptable import and export file formats, Internet connection types, browser capabilities, current data coordination, and jurisdictional area of data production. The second portion was a first step crosswalking exercise to the FGDC Cadastral Data Content Standard. The last section contained fill-in tables for each attribute in the standard. Information was collected on data holdings and maintenance, data needed that was not currently maintained by the organization, transaction types (create, read, update, delete) needed and by whom, business outputs (uses and products), and wether or not the attribute was considered be "framework data" or sharable information (see Attachment C).



The second process taken in identifying business requirements was a partner meeting held in Olympia, Washington. The group reviewed summarized results of the mail survey. Draft data, technology, and business process requirements were discussed. An effort was made to distinguish which parts of the FGDC Cadastral Data Content Standard data model were considered necessary for the framework.



The final process was a phone survey. The Project Manager contacted each partner in order to gain information about the background of each partner organization as well as core business expectations of the cadastral framework and the Internet application for data distribution. The information was summarized into a document and distributed to the partners for review and edits (see Attachment D).



Outcomes



The Requirement Input Document was helpful in identifying some base information such as the types of hardware, software, Internet connection, and framework data needed and/or maintained by each partner. We had approximately an eighty-five percent (85%) return rate. The downside was that the survey was a very bulky document that was too daunting for some partners to tackle. It required a certain degree of crosswalking partner data to the standards. The standards were not well understood by all recipients.



The partner meeting was a good opportunity to get the whole group of participants together to meet and discuss requirements. There was some disagreement as to what portions of the FGDC Cadastral Data Content Standard data model should be part of the framework data model. Some of the partners wanted all of the model included and others felt that the entire model was too much and only certain portions should be included in the framework data model.



One issue that did become clear as the meeting progressed, was that we needed to break the project up into manageable phases. Specifically, Phase 1 would include requirements necessary for framework data model development, initial population, and distribution of the initial framework data to the partners over the Internet. Integration of partner data would occur within a pilot county to test the process and tools necessary for larger scale integration. Phase 2 would then involve development of partner data submission processes and framework update processes.



Another issue that was raised in the meeting was the need to be flexible on the hardware and software requirements necessary for participation. As a result, the only requirements placed on the partners for access to the framework data was an Internet connection and a JAVA enabled browser.



The phone survey document was extremely useful. It helped summarize each partners main business expectations of the cadastral framework. A common business expectation also surfaced throughout this document. All of the partners keyed on a central need for a common Public Land Survey System (PLSS) grid for the state that all partners use and share as base information to build on.



Lessons Learned



1. The Requirement Input Document provided useful information to the project. However, it was a large packet that proved to be too daunting for some of the partners. It may have been more productive, and less challenging, to collect each partner's metadata for their cadastral data in order to determine certain data requirements. Assuming the metadata was available and complete for each partner, much of the bulk and time required to complete the survey could have been reduced. However, if that approach was taken, it would be prudent to include some form of information request that would determine cadastral data needs that are not met by each organization's business data. Meeting needs that aren't currently met provides important incentive to participate.



2. Framework development should be approached in manageable project phases. The FGDC Cadastral Data Content Standard included tables and attributes for real property and its geographic extent. However, it did not include much detailed information describing the relationships between tables or explanation about how the model was to be used. It was very important to fill in that detail through the interview process. Make sure that all of the business events and processes will make sense in terms of the data model.



3. Partner response is better when draft proposals and/or prototypes are provided for feedback rather than asking for input from scratch. It is often easier for people to respond to a starting point.



4. For maximum participation, remain flexible on hardware and software requirements.



5. It is important to develop an understanding of partner expectations. Determine and record what partners expect and desire in the short and long term from framework development. The information is beneficial in project decisions and evaluation.



3. Model Business Processes. A process model will be developed showing how data will flow in the cadastral framework, and how the framework will respond to identified business events/situations. The model will include data flows in both directions: from partner organizations to the framework, and from the framework back to the partner organizations.



Approach Taken to Accomplish Task



A technical team meeting was held to discuss potential process flows. Several sketches were discussed and contemplated. A partner meeting was also held with the partners participating in the pilot county data integration effort. Some business framework data processes were discussed. A general process was identified. Meeting minutes were then distributed to all of the partners for review (see Attachment E).



Outcomes



Three main process models were developed. The processes for the first phase of the project included the conversion of DATA96 cadastral data to the new model and transmission of that data to the Framework database to be displayed, queried, and served to users. An intermediate process model describes how provider data is integrated into the DNR data set before conversion to the Framework database. This includes certification of the data set to be provided. The final target process model describes how data from providers would be incorporated into the database by an integrator. In this process a data provider checks out data from an area of the framework. The check-out sets a data lock for that area. Edits are made by the data provider and are submitted to a public File Transfer Protocol (FTP) area. The checked in data goes through a quality control check. If the data is validated, it goes on to be added to the cadastral framework database for public access. If the data submission is not accepted, the integrator notifies the data source with an explanation. The process model will be revisited as development continues into the next phase of the project (see Attachment F).



Lessons Learned



1. Determine roles and responsibilities of the framework functions. A couple of thoughts that can help with this process are to clearly detail the responsibilities of each role, based on the business requirements, and build on current business processes as much as possible.



2. Develop an understanding of local government perspective. Local government organizations function very differently than state and federal level partners. The benefits of framework participation are not always as apparent to the local users. Develop an understanding of how they do business and find ways that framework development can help them.



3. Write a script of the procedures that focuses on the actions that each role will take. This usually clarifies how the whole process works.



4. Model Cadastral Framework Data. The business process model will be examined. The impact of ESRI's Spatial Database Engine (SDE) and the Internet will be evaluated. Using these and other factors, including the FGDC Cadastral subcommittee's logical data model and a statewide cadastral inventory, a physical data model for the cadastral framework will be established.



Approach Taken to Accomplish Task

The FGDC Cadastral Data Content Standard models the business of tracking rights in land conveyed through transactions in which the extent of the land is based on a legal description. In the model, legal area descriptions are compiled from legal description components that are individual Public Land Survey, platted lots, metes and bounds, boundary, and strip descriptions. The extent of the land and land rights come together in the parcel. Transactions show agent interests in the parcel. Restrictions affect the usage of parcel rights. Document sources index where to find legal descriptions, restrictions, transactions, boundaries, agents, corners, and coordinate measurements in the public record or in private files.



Data analysis was approached from several directions: existing DNR coverages, the FGDC Cadastral Data Content Standard, a partner requirements survey and review, and developing DNR projects. In the context of existing DNR data coverages, a technical analysis was performed to document the physical structure and the foreign key relates, and also to logically normalize the entities, attributes, and relationships. From the FGDC Cadastral Data Content Standard, physical elements were made more logical and super/subtypes were identified after Cadastral Subcommittee members reviewed the intent of the model with us. Some extensions were also made to the model to include coordinated geodetic points and monuments in the model (see Attachment G). The partner survey was developed from the FGDC Cadastral Data Content Standard. Among other things, the survey asked partners which of the entities and attributes they maintain in their normal business functions and which they do not maintain, but have a need for (see Attachment C). In terms of developing DNR projects, the Automated Tract Book (ATB) Project became the active model for development of an FGDC compliant data model. Aspects of the Aquatic Land Ownership Project were also included in the development of the data model. The complexity of this approach is apparent, and some of the modeling has been reworked in prototyping after initial data conversion.



Many logical and physical data modeling sessions were held. Sessions were initially done by smaller groups of centralized business experts. The sessions were intense and focused. Once the data requirements were captured by each group, the model was edited to reflect the needs. Typically, a final review session was held that combined some of the smaller groups together. The framework partners came in from around the state for a two day modeling session. Nancy Von Meyer, from the FGDC Cadastral Subcommittee also came to the session and provided helpful expertise. The results of the session were mailed out to the partners for review (see Attachment H).



The complexity of the logical data model required resolution of the many possible implementations of the model. Prototyping was used in several cases to force resolution of the super/subtype entities. Lack of data to fill in some of the relationships between tables is another problem worked out in the physical model implementation. Being new to the object oriented feature model of SDE also made prototyping of implementation ideas necessary. At first, individual extracts of data sets from coverages were made for SDE. However, it was apparent that these could not readily be converted back to an integrated coverage format for editing in a conventional Arc coverage environment - most of the tools for editing in a SDE/ArcView shape format have not been developed or have not had the time to mature. The approach being taken is to extend the base coverage to a region format and then convert to SDE layers based on the region subclasses. These layers can be merged back together into a region coverage for editing. The FGDC Cadastral Data Transfer Profile is also in terms of an Arc/INFO regions coverage. However, it has no coding scheme and may be difficult to use for data exchange.



Outcomes



There were some areas of the FGDC Cadastral Data Content Standard that were modified in the Washington Cadastral Framework Project. The modifications are in the form of documentary clarification, modeling structure, and extensions to the content. The relationships are clarified by adding text which describes the nature of the relationships. The FGDC data model mixes logical and physical modeling techniques. In the FGDC model for example, logically, all attributes are contained within the major entities -- there is no coding; physically, both primary and foreign keys are included, and subtypes are diagramed as relationships. The model is separated into both forms for ease of use by analysts. Because data contributors have data sets that are closely related to the cadastre, content extensions are made to facilitate the conversion of these within the context of the whole data model. Other content structure (Outer Continental Shelf) was left off because it did not fit the current requirements.



A narrative of intended use of the Cadastral Data Content Standard was not included in the standard itself. It took several months of data modeling and direct guidance from Cadastral Subcommittee members to establish how the standard was to be used. The standard is supposed to allow the extent of parcels to be described within the context of traditional legal description structures including Public Land Survey System, metes and bounds, boundary, map reference, and strip descriptions, along with the corners and boundaries of these descriptions. Some of these description structures are not clearly identified in the standard. The standard is also supposed to allow tracking of parcel rights, ownership, agents, and transaction documentation. There was much confusion over how the two sides of the standard came together.



In the Washington model, the relationships between entities are labeled to describe the relationship. Both directions of the relationship are labeled. For example, the relationship from PLS Township to PLS Township Subdivision is "subdivided into"; this is read "A PLS Township may be subdivided into one or more PLS Township Subdivisions." Along the same relationship in the inverse direction from PLS Township Subdivision to PLS Township, the relationship is read "A PLS Township Subdivision must be subdividing one PLS Township." Labeling the relationships helps diagram users understand the context of the relationships between the entities.



Because of the technical complexity of land surveying, data analysts needed more background to understand what they were working on. A glossary of detailed definitions was written to describe the entities, attributes, and data values for the data model (see Attachment I).



It is recommended that a glossary of detailed definitions be written for the standard with an emphasis on property law for land transactions, rights, and restrictions.



During the logical modeling, supertype and subtype structures were identified and created. Relationship meanings were documented and labeled. Foreign keys were retained for the physical model but taken out of the logical model. The intended usage of the data model was established and documented.

Several sets of related entities were identified as supertypes and subtypes in the FGDC content standard. The subtypes are a more specific type of the supertype. Legal Area Description is broken down into PLS Description, Survey System Description, and Outer Continental Shelf Description. Outer Continental Shelf Description was dropped from the Washington model as a data structure. Outer Continental Shelf should fit within the definition of Survey System Description entity. PLS Description is broken down further into its subtypes: PLS Township, PLS Township Division, and PLS Section Division. The extent of a land parcel can be described through the Public Land Survey System by whole township, a whole township subdivision, or a subdivision of a section. The subdivision relationships still exist between these description entities to show the parentage of any PLS subdivision.

It is recommended that Metes and Bounds Description, Strip Description, and Boundary Description are specifically added as types of Legal Area Description. Boundary Description was the many-to-many relationship between Parcel and Record Boundary in the FGDC standard. This should probably be a many-to-one from Record Boundary to Parcel; each Record Boundary of a Legal Area Description may be referencing one Parcel; a Parcel may be referenced by one or more Record Boundaries.



Record Boundary is broken down into subtypes of Straight Line and Curve. Curve is further broken down into Circular Curve and Spiral Curve. Other Curve was dropped from the Washington model.



Agent is broken down into subtypes of Individual and Organization. An optional many-to-many relationship between Individual and Organization was added; an individual may represent an organization; an organization may represent an individual. Public Agency was identified as a subtype of Organization. Native American Tribe and Private Organization were added as subtypes of Organization



A relationship between Parcel and Address was added to allow for geocoding the location of a parcel. Agent Address was renamed to Address since it did not apply only to agents.

.

The structure of relationships between Parcel, Parcel Transaction, Transferred Right, and Agent was changed from the Cadastral Data Content Standard to allow for collecting initial data. In many cases, GIS databases do not have the transaction information stored which show a clear line of title. If transaction data is required for recording basic parcel ownership rights, then the Cadastral Data Content Standard would not be able to accept data converted from existing databases. Therefore, the relationships were altered in the Washington model to go between Parcel, Ownership Right, Agent, and then Transaction. Some of the data provided to the Cadastral Framework database may not be accurate, but publishing the information in this form over the Internet allows challenges to surface with documentation of transactions. The accuracy of ownership information will increase over time.

Two content extensions, the geodetic control theme and governmental unit theme, were added for the Washington model. Coordinated Point was added as a supertype of Corner Point and Geodetic Control Point. Geodetic Control Point has a mandatory attribute Name, and optional attributes Alias and Identification Description. Survey Monument was taken out of Corner Point so that Coordinated Point can be related to Survey Monument. The relationship between Measured Coordinate and Corner Point is also generalized to go between Measured Coordinate and Coordinated Point. In terms of governmental units, State and County Boundaries are included in the model as well as Administrative Areas (see Attachment J and Attachment N).



The outcome of the physical model was influenced by discussions with partners about future update transactions. Partners decided that validation of the jurisdiction, authority, and values of data being contributed in the future would be completed before allowing integration of partner data into the partner database. The validation of the data would be automated to minimize the amount of integrator effort involved. The data integrator would check the validation reports and work to resolve any integration problems or data conflicts.

In order to increase the speed and accuracy of update transactions, values for many attributes are coded. Coding allows for Boolean validation. Text string searches, which take time and can be inaccurate, are minimized.

Lessons Learned



1. It is important to determine right from the beginning what portion of the model will be initially implemented as framework. In other words, what is the priority base data that is desirable to share and maintain cooperatively as a start.



2. Determine framework data criteria. This will help determine what areas of the FGDC Cadastral Data Content Standard data model to focus on in building a framework data model. Aside from this issue, criteria will also identify clear expectations of the data model population.



3. Do not let data analysis go on forever. Try to bring closure to data analysis issues as quickly as possible. It is too easy to get caught up in continual analysis and re-analysis. Capture the data requirements, build the model based on those requirements, and start prototyping as soon as possible. Continue to refine the model after testing.



4. Break data requirements sessions into small focused groups and peer review frequently.



5. Keep internal proprietary requirements and Framework partnership requirements separate. The more detailed proprietary requirements add complexity to the generic data model and confuses Framework partners.



5. Implement Agreements for Establishment and Maintenance of Data. A full list of institutional responsibilities, including those suggested by the FGDC, necessary to develop and manage the cadastral framework in Washington State will be defined. Data entry and maintenance agreements for cadastral framework data will be negotiated and established.



Approach Taken to Accomplish Task

Roles and responsibilities for the development and management of the cadastral framework were discussed in partner meetings and in the FMG quarterly meetings. Four functional categories of roles have been identified. Those included executive guidance and policy development, framework data coordination and management, framework data integration and maintenance, and framework data distribution. Core responsibilities were outlined for each category and groups of project participants were assigned to appropriate categories. As the project progresses and moves forward, it is anticipated that this information will be further defined and may continue to change over time.



Partnership agreements for the project were drafted and reviewed by the DNR Attorney General Office. The draft agreement was then sent out to the partners for review and comments. The project manager summarized the comments that were received and presented them for discussion at a partner meeting. Feedback from the review and partner meeting was incorporated into a second draft which was mailed out for a second review. The second review was to be coordinated with each partners legally binding authorities.

Outcomes

A document was produced that identifies, at a fairly high level, the roles and responsibilities involved with the cadastral framework and what project groups fit within each role (see Attachment K). Specific responsibilities for each individual partner are not detailed. Rather, the partners are referred to as a group in the document and assigned to roles of data coordination and management and data integration and maintenance. Part of the reason for that has to do with the objectives of the first phase and part of it has to do with the overall project development. The first phase of the project focused on building the framework data model, initial data conversion and population, and Internet access. Maintenance and integration responsibilities won't crystalize for each individual partner until update and integration mechanisms are in place. Those mechanisms will be built in the second phase of the project. It is clear that each individual partner will fulfill slightly different levels of responsibility within the partner roles identified and that those levels of responsibility may change over time. For example, some partners are just beginning to think about building a business GIS system. They may not be involved with data integration issues at all, but play a large role in framework maintenance over time.



The partnership agreement is in second draft form. It is still undergoing partner legal review. Outstanding issues from the second draft will be discussed with the partners at the next partner meeting to be held November 18, 1998. Final changes will be made to the document and mailed out for signatures by the end of November. When complete, a master copy of the document and signature pages will reside at the DNR Information Technology Division office.



Lessons Learned

1. Determine roles and responsibilities that are needed to fulfill the framework functions, make initial assignments, and refine both throughout project development.



2. Two things need to be clear in order to make effective role and associated responsibility assignments. The scope of the responsibility needs to be clear, and assignments need to match up with business needs. This approach ensures both commitment to the responsibilities and realization of benefits.



3. Legal documents, such as the partnership agreement, take a great deal of time to finalize when dealing with a multitude of organizations. A less binding agreement such as a Memorandum of Understanding (MOU) or Memorandum of Agreement (MOA) may be a more expedient method to documenting partnership. However, the legal agreement ensures a greater level of commitment.



6. Detail Organizational Requirements. A plan will be developed to meet organizational requirements of the project, including training, help desk, change control, and facilities.



Approach Taken to Accomplish Task



Organizational requirements including training, help desk, change control, and facilities were addressed during the needs assessment stage of the project. Training needs focused on the Internet framework data access application. The initial training plan included on-site training or group site training with the various partner organzations. Help desk requirements were determined with partner input as well as change control procedures. The only facility requirements in the project were related to the physical location of the Internet server.



Outcomes

Due to project time constraints and suggestions from partners to utilize the Washington Interactive Technology (WIT), the training plan strategy was changed slightly. Instead of on-site or group site training, the WIT sites were used for training. The WIT sites are video conferencing facilities that are located at central areas throughout the state. Interaction between all of the participants is possible through the sites. The video screen is voice activated. When a participant begins speaking, the video screen shows the site they are speaking from. The trainers transmitted from the base WIT site near Olympia, Washington. A two hour training was held that covered organizational details and the data access application training. The Internet application was stepped through by projecting the computer screen onto the video screen. Periodic opportunities for questions were provided. One of the service options provided by the WIT site operators was a video tape of the session. That option was utilized for partners that were not able to attend. It was agreed among the partners that any training needed beyond the Internet access application would be the responsibility of each individual partner.



The main help desk requirement identified was a procedure for system failure reporting. The DNR took on responsibility for system administration and database administration. As a result, it only seemed logical to have system help desk support located within DNR as well. The central DNR GIS help desk staff agreed to provide support for the cadastral framework system failure reporting. Any data questions are referred to the metadata contacts. Application questions or comments are currently directed to the project manager.



Since the framework access application is considered to be a prototype and the framework data model is in a certain degree of flux until complete evaluation takes place, change control procedures include Partner Communication web pages. There is a Partner Comment web page for evaluation of the application and the data model. There is also a Notification Of Change web page for changes to the application and/or the data model. Any major changes would need to be approved by consensus of the partner group.



In terms of the facilities requirements, it was determined that the physical location of the Internet web server would be in the DNR main computer room. Logically, it is not connected to the state network. The Internet service is provided through the state Department of Information Services.

Lessons Learned



1. Start the planning early so that there is time to develop a detailed plan.



2. The video conference worked well for training, but participation in discussion is more difficult.



7. Evaluate Technology. Mandatory requirements for technology within the cadastral framework will be identified. A technology architecture diagram will be developed.



Approach Taken to Accomplish Task



At initial partner meetings, it was determined that there were two basic technology related goals for the project. One goal was to avoid placing mandatory hardware or software requirements on partners for participation in the project. The other goal was to use as much existing technology as feasible.



The cadastral framework was the first web application developed and managed by the DNR. As a result, the web server installation was one of the first issues that had to be resolved. Alternatives for the web server installation were reviewed and considered with system administration staff, network administration staff, database administration staff, and the state Department of Information Services (DIS). The DIS manages a state government network which allows connections to the Internet and several state agencies including the DNR. Three basic options were reviewed. They included installation outside of the DIS firewall with DNR administration, installation inside the firewall with DIS administration, or subscription to a bastion server that allows very limited partner access (see Attachment L).

In terms of software requirements, it had already been determined that the software for the cadastral framework database would be Oracle/SDE. A separate project taking place within the DNR, called the Oracle Transition Project, conducted a study on SDE. One of the central focuses of the study was the data update capabilities of SDE.



Partners provided input regarding the Internet data access application. Essentially, the partners wanted a very simple application with opportunities to query and download the data by various geographic areas. The geographic areas requested were by state, county and township. The DNR system administration staff gathered information about software product options.



Outcomes

After several meetings and much discussion, the choice was made to install the framework web server outside of the DIS firewall with no connection to the state network. Physical access to the web server and partner data access were key factors in this decision. A technology diagram and narrative was produced (see Attachment M1 and M2).



The outcome of the SDE study was a determination that most of the tools for editing in a SDE/ArcView shape format have not been developed or have not had the time to mature. As a result, the current approach for editing will be to convert data to SDE layers based on region subclasses. These SDE layers will be merged back together into a region coverage for editing.



The Arcview Internet Map Server (IMS) product was selected and purchased for the framework data distribution application. With this product, the technical team was able to quickly customize a web display and query for the framework partners. A new version of the software was expected to be released in early spring of 1998 that was to include data downloading functionality. The new version never materialized, so the technical team built in the data downloading functionality.



Lessons Learned



1. Keep flexible on hardware and software. Look for the partners' common denominator. For maximum participation, a flexible system works best.



2. Use off-the-shelf technology products when possible. It can save time in the short term and support is inherent over the longer term. Oftentimes, there are also examples of other applications that can be reviewed.



8. Load Initial Data into the Cadastral Framework Data Model. Cadastral data from participant organizations will be collected, integrated, and loaded into the new cadastral framework data model.



Approach Taken to Accomplish Task



The initial data that was to be loaded into the new cadastral framework model included three legacy data sets. The three data sets to be loaded included POCA, PLS-PT and MPL. The POCA data set is an integrated set of geo-referencing data covering the state of Washington. The polygon information content includes Public Land Survey System (PLSS), DNR ownership parcels greater than five acres, shorelines, state and county boundaries, tribal lands, military reservations, and state and national park boundaries. Line information includes type of line, including surveyed, found (USGS), projected, and protracted. The PLS-PT data set is a PLS point layer consisting of statewide surveyed points (corner positions). It serves as a control layer for the township, range, and section delineations recorded in the POCA layer. The MPL data set contains statewide ownership parcels for federal, state, county, city, and tribal lands within the state of Washington. All three legacy data sets include integrated data from other organizations.



During the course of project development, the complexity of the data model and conversion process became painfully clear. Many possible implementations of the logical model were possible. The technical development team recommended that we prototype physical model development in order to ensure that business requirements were met. A conversion process was developed in order to convert data to both the new data model and the new database software (ARC/INFO to Oracle/SDE). This process included a technical analysis of the legacy data and formulation of a data conversion matrix.



In terms of additional data integration over the longer term, the partners decided that a pilot approach should be taken to integrate further partner data to the framework. Criteria was developed by the partners for selecting a county to serve as the pilot area. Counties were nominated and voted on by the partners. Snohomish County was selected for the pilot. Three partner data selections were determined for integration that included a federal partner, a private partner, and a county partner. The Bureau of Land Management partner made arrangements with the U.S. Forest Service partner to fund collection of Geographic Coordinate Database (GCDB) data in about thirty townships within Snohomish County. Longview Fibre Company provided ownership data within Snohomish County. The Snohomish County partner provided their PLSS data and one township of their entire integrated cadastral data set for testing.



Outcomes



The core framework data need, expressed by the partners, was for a common statewide PLSS data layer. As a result, this data became the first priority for legacy data conversion. It was the first to be prototyped and made available to the partners over the Internet. The rest of the legacy data is still in the process of data conversion but is expected to be completed by the end of November 1998. The thought behind this step-by-step approach was to ensure that the base PLSS data was going to meet the partner's business needs prior to complete conversion of all the legacy data. For the partners with established business PLSS data, the business need includes conversion of the framework PLSS to their business data. For the partners just building a GIS system, the business need includes the usability of the framework PLSS as a base set of data to build on. This prototype approach avoids the situation where complete legacy data conversion takes place only to find out the product is not going to work for the partners.



Once the legacy data conversion is complete and prototype testing from the partners has provided sufficient feedback, the physical framework model should stabilize. Then the pilot data integration effort can begin. The data providing partners will participate in that effort.



Lessons Learned



1. Start prototyping as soon as basic data requirements are known. Continue to refine the model after testing.



2. Develop an understanding of partner expectations. Determine and record what each partner expects and desires in the short and long term from framework development. The information is beneficial in project decisions and evaluation.



9. Develop Metadata and Post to the Internet. The cadastral framework data developed through this project will be documented according to the Content Standard for Geospatial Metadata where feasible and served through the Internet.



Approach Taken to Accomplish Task



The Cadastral Framework Project Manager attended a one day workshop on metadata creation for the Washington Clearinghouse. It was sponsored by the Washington Department of Information Services (DIS). The DIS provides an education and coordination role for the development of the Washington Clearinghouse Node. The workshop presented an overview of the Clearinghouse functions and participants. Various tools for metadata creation were presented and discussed. The second half of the workshop provided an opportunity for participants to choose a metadata tool, create a metadata entry, and post the entry to the Clearinghouse.



In addition to the Clearinghouse metadata, a web-based data dictionary application was targeted for use in order to serve more detailed information such as tables and attributes. The data dictionary application was developed in another, DNR specific, project. It was built to replace an old application.



Outcomes

At the metadata workshop, the Metadata Entry System (MES) tool was used to post cadastral framework metadata on the Washington Clearinghouse node. In the future, more detailed metadata may be added to the Clearinghouse.

The web-based data dictionary application did not complete in time for the implementation of the cadastral framework Internet application. However, the prototype was used to build the initial on-line table and attribute metadata for use through the Internet framework data access application.

Lessons Learned

1. Data stewards should be trained to use the metadata entry tools so that they can contribute directly to the metadata.



2. The project would have benefitted from collecting compliant metadata from partners in the requirements gathering phase. This would have provided a solid foundation for requirements analysis for building additional partner requirements.



10. Post Cadastral Framework Data to the Internet. The cadastral framework data established for this demonstration project will be available on the Internet.



Approach Taken to Accomplish Task



ESRI's ArcView Internet Map Server (IMS) was chosen to serve the framework data over the Internet. ArcView's Database Access extension allows a direct connection to the SDE database. ArcView's IMS extention serves GIS data for map display and query through a customizable standard interface. The IMS offers several formats of standard interfaces as multiple frames. The layout and number of frames is easily adjusted in the master, and the content of several frames may be modified by editing the HTML. JAVA enhancement of the standard web page and the Map Café viewer are also possible.

Outcomes



A prototype application was built and implemented for access to the cadastral framework data over the Internet. Since the data and the project development is still considered a work-in-progress, access to the data is limited to the project partners at this time. In the future, the goal is to provide widespread public access.

Lessons Learned



1. Keep it simple. Assess requests for enhancements as they occur.



11. Promote Cadastral Framework Demonstration Project. The results of this project will be promoted through WAGIC and IRRIC meetings. Additional promotional opportunities will arise in contacts with survey industry and information technology professionals.



Approach Taken to Accomplish Task



Many outreach efforts have been accomplished in promotion of the Cadastral Framework Demonstration Project. The methods used for promotion have included; Internet web site information, presentations at local GIS user group meetings, responding to word-of-mouth phone inquiries, articles for newsletters and professional publications, attendance at IRRIC and NSGIC meetings, and presentations at professional GIS conferences. All of these methods have served to create a good deal of interest and enthusiasm in the project.



Two main web locations have been used for promoting the project. Project information including the project charter, upcoming meetings, and meeting minutes are posted on the WAGIC Internet site (http://www.wa.gov/gic). More recently, the cadastral framework Internet access application has been implemented. There are web pages within this application that also provide information about the cadastral project as well as overall framework efforts in the state. These web pages have links to the WAGIC web pages.



The Project Manager has made several informational presentations at various regional GIS user group meetings. These presentations have taken place at the WAGIC Olympic Peninsula User Group meeting, the Snohomish County GIS User Group meeting, the Spokane County GIS User Group meeting, and soon at the City of Seattle GIS User Group meeting. Generally, content of the presentations has included a project overview, benefits of framework participation, and current project status.



Several newsletter articles have been written throughout the project. Five overview and status articles have been written for a bi-monthly technology newsletter called the Point and Click. This newsletter is distributed to other state agencies. Additionally, an article on the project was written for the Information Processing Management Associates (IPMA) newsletter. IPMA membership historically includes leaders in information technology within Washington State government and has been in existence for more than twenty years.



Promotion of the project has also occurred through professional GIS conference presentations. A project presentation was made at the Washington URISA/WAGIC May 1998 Spring Conference in Tukwila, Washington. Another project presentation was made at the ESRI Northwest User Conference in Sun Valley, Idaho in October 1998. Both conference presentations generated discussion and new partner interest.

Outcomes



Several new partners joined in at various points throughout the first phase of the project. All of the new partners had heard of the project through word-of-mouth or through presentations. The only difficulty has been trying to keep up with new participation in the midst of technical project development. The more participants there are, the more difficult it becomes to provide effective communication and reach consensus on certain issues.



Lessons Learned

1. Publicize the project. Look for opportunities to promote project activities in as many media as possible. The new contacts pay off. The more the word gets out, the more people talk and interest generates.



12. Assess Cadastral Framework Demonstration Project. A formal evaluation of the project will be conducted to measure success and to adjust technical and administrative procedures for the future.



Approach Taken to Accomplish Task



One approach taken to get partner evaluation feedback, was to implement a Partner Comment page on the Internet application. During the Internet application training session, partners were encouraged to submit comments as a means of providing feedback on the application and data usability. The comment page includes an archive for partners to view other comments that have been collected. This method of evaluation provides general comments.



For more specific project assessment, an evaluation form with specific questions and ratings was developed (see Attachment O). The participating partners were asked to fill out the evaluation form at a partner meeting.



More informal evaluation information has been gathered through phone calls and e-mails to the Project Manager.



Outcomes



Most of the assessment information gathered from all three methods, to date, has been positive. Partners have appreciated the work completed and the good communication throughout the project.

Lessons Learned



1. Follow through on project tasks to build partner trust. Fostering partnerships begins by building trust. If tasks cannot be completed on time, let the partners know and let them know why.



2. Good and frequent communication is important to project success and participation. Provide periodic status reports and continuous input opportunities through mail, e-mail, phone, and meeting correspondence.



13. FGDC Reports and Meetings. Periodic reports and meetings will be provided for the FGDC. Quarterly reports will be submitted during the project and annual follow-up status reports will be prepared in 1999 and 2000.



Approach Taken to Accomplish Task



All of the required FGDC meetings have been attended, and all of the required reports have been submitted to the appropriate FGDC staff. The project has received a second grant for the grant year 1998 - 1999 to complete the second phase. Status reports will follow within the required time lines and formats.



Outcomes

The required FGDC Kick-off meeting and Interim Progress meeting were helpful to the project in several ways. They afforded an opportunity to meet other project leaders doing similar types of projects and facing similar issues. Contacts were made that allowed for post-meeting discussions. The meetings also provided the latest information on FGDC activities and products.



In addition to the required meetings, the Project Manager attended a fall 1997 FGDC Cadastral Subcommittee Meeting in Portland in which NACO and NSGIC members were invited to attend. Valuable and helpful information was learned at that meeting in regards to preliminary educational materials under development for the Cadastral Data Content Standard and status information on the Cadastral Data Transfer Profile. From the contacts made at this meeting, the technical project team was later able to consult with subcommittee members on data modeling issues related to the FGDC developed cadastral standards.



Lessons Learned



1. For projects following the FGDC Cadastral Data Content Standards, consulting assistance from the FGDC Cadastral Data Subcommittee is very beneficial.



FUTURE OF THE PROJECT



In phase 1 of this project, the emphasis has been on reviewing the Cadastral Data Content Standard, developing the standard into a physical database, and populating the database with existing data sets. The next phase of the project is to develop procedures for updating the data on the framework cadastral database and to develop automated procedures for integrating additional data sets while maintaining the integrity of the database.



The next steps are to reexamine the business events and processes. Events include data change, data integration problem, data conflict, database failure, and data requirement change. Processes include data development, location of developed data through clearinghouse indexing, data provider certification, data editing, database update notification, database maintenance, database integration, database integration problem resolution, database conflict resolution, database backup and recovery, and database change control. The procedural response to each event, and the details of each process are being finalized with partners. The processes are being developed to minimize database integrator intervention.



The partnership will identify data developers, data stewards, data users, database integrators, and database administrators. Data developers create proprietary databases which have data sets which could be integrated into the cadastral framework database. Data stewards are the business experts familiar with cadastral data who have been designated to certify data sets for integration, and resolve database conflicts. Data users are the public and private agencies who conduct cadastral business; these will have to be targeted for cadastral framework publicity and information. Database integrators review the results of integration validation and respond to problems and conflicts. Database administrators support the framework database operations, backup, and recovery.



Data stewards will draft quality control standards for data certification. The standards will determine the authority and jurisdiction of data providers. Data stewards will also examine the data conflict situations, e.g. two counties are accepting different corner points as the representation of a corner. The data parameters identifying conflict situations will have to be developed to minimize database integrator intervention. The data stewards will have to work through conflict resolution processes for handling each situation.



The project will construct the whole update and integration application. Database administrators will continue to evaluate data formats for editing and exchange (coverage, region coverage, shape files). Partners will integrate framework data within the pilot geographic area (Snohomish County). The database integrator (DNR) will maintain the framework database and distribute on a continual basis. The project will evaluate cadastral data editing packages, then develop or acquire an edit environment. The developers will build an Internet check-in/check-out staging area and start developing tools and utilities for data integration, problem resolution, and conflict resolution.



The partnership will determine how to financially support the stewardship, integration, maintenance, and distribution of the framework database. Financial incentives for getting rural counties started on the framework database will be addressed. Additional private organizations will be encouraged to participate in the cadastral framework, in particular surveying firms doing work for rural counties.



The Washington State Cadastral Framework Project will provide assistance to other cadastral framework projects and coordinate with other framework projects on government unit, transportation, and hydrography framework theme development.



CONCLUSION

Phase 1 of the Washington State Cadastral Framework Project has been a valuable test of cooperatively implementing the FGDC Cadastral Data Content Standard. The project developed a partnership between federal, state, county, regional, and private organizations. This partnership has established the interests and expectations of the partners for implementing the Cadastral Data Content Standard, providing data over the Internet, and developing a process for integrating cadastral data over the Internet. The Cadastral Data Content Standard has been thoroughly examined and enhancements have been made. The implementation of the content standard has been populated with an initial set of data. The testing of the initial data load resulted in additional changes to the implementation. Metadata of the Cadastral Framework database has also been published on the Washington Clearinghouse node. Partner evaluations of Phase 1 have been positive. Improvements will continue to be made as these evaluations are reviewed and Phase 2 of the project continues.





































































References



Bureau of Land Management (1997, November 4). GCDB Home Page (Geographic Coordinate Database). http://www.blm.gov/gcdb/ .



Federal Geographic Data Committee (1995, March 24). Content Standards for Digital Geospatial Metadata Workbook. Reston, VA.



Federal Geographic Data Committee (1997). Framework: Introduction and Guide. Somers-St. Claire, Fairfax, VA. http://www.fgdc.gov/framework/frameworkintroguide/ .



Federal Geographic Data Committee, Cadastral Subcommittee (1996, December). Cadastral Data Content Standard. Reston, VA. ftp://ftp.fairview-industries.com/pub/cadastral/ .



Federal Geographic Data Committee, Cadastral Subcommittee (1998, February). Cadastral Data Transfer Standard. Reston, VA. ftp://ftp.fairview-industries.com/pub/cadastral/ .



Federal Geographic Data Committee, Cadastral Subcommittee (1998, September). FGDC Cadastral Subcommittee. http://www.fairview-industries.com/fgdc-cad.html .

Federal Geographic Data Committee, Cadastral Subcommittee (1998, May 1). Learning the Cadastral Data Content Standard. http://www.fairview-industries.com/welcome.htm .



Hair, D.; Timson, G.; Martin, P. (1997, May 28). Feature Maintenance: Concepts, Requirements, and Strategies. U.S. Geological Survey, Mapping Division.



Snohomish County (1998, December). Integrated Land Records Metadata. http://www.co.snohomish.wa.us/dis/gis/metadat.htm .



Washington Cadastral Framework Partnership (1998, September 15). Cadastral Framework Project. http://framework.dnr.state.wa.us/framework/cadastre/ .



Washington Cadastral Framework Partnership (1998, November 24). Washington State Cadastral Framework FGDC Metadata. Federal Geospatial Data Clearinghouse, Washington State Geospatial Clearinghouse Node, via http://agdc.usgs.gov/AGDCgateway.html Search: cadastral.



Washington Department of Natural Resources (1997, May 23). Washington State Major Public Lands (MPL) FGDC Metadata. Federal Geospatial Data Clearinghouse, Washington State Geospatial Clearinghouse Node, via http://agdc.usgs.gov/AGDCgateway.html Search: MPL.



Washington Department of Natural Resources (1997, May 23). Washington State POCA (Public Land Survey, Ownership, County, and Administration) FGDC Metadata. Federal Geospatial Data Clearinghouse, Washington State Geospatial Clearinghouse Node, via http://agdc.usgs.gov/AGDCgateway.html Search: POCA.



Washington Geographic Information Council, Framework Management Group (1998, October). Framework Management Group. http://www.wa.gov/gic/frameworkwg.htm .



Wattles, G.H (1979). Writing Legal Descriptions. Wattles Publications, Wustin, CA.