Transportation Framework



Project Charter



December 1999





Project Team Members



IRICC Roads Committee

US Forest Service

US Environmental Protection Agency

US Bureau of Land Management

US Geological Survey



Washington State Department of Transportation

County Road Administration Board

Washington Department of Natural Resources

Washington State Parks

Department of Information Services



Puget Sound Regional Council

Thurston Regional Planning Council



Snohomish County

Spokane County

Thurston County





Washington Geographic Information Council



1. Introduction 1

2. Vision 1

3. Background 1

4. Approach 1

5. Objectives 2

6. Scope 2

7. Assumptions 3

8. Critical Success Factors 3

9. Key Deliverables 5

10. Outcomes and Measures 5

11. Project Organization 7

12. Roles and Responsibilities 7

13. Project Resources 8

14. Funding 9

15. Decision Making Process 9

Appendix A - Objectives

Appendix B - Scope Definition

Appendix C - Contingency Plan



1. Introduction

The purpose of this project charter is to describe the project to develop the Transportation Framework for the State of Washington. The charter defines the understandings between the project partners under which the project is to be managed.

2. Vision

The Washington State Transportation Framework is a seamless set of data that are consistent, connected, and continuous between segments of the transportation framework and with other framework layers. The transportation framework represents the best data available and includes mechanisms to improve over time. Framework data is accessible to the general public at the least cost with the least restrictions.

3. Background

The Washington Geographic Information Council (WAGIC) strategic plan calls for development of a geospatial framework to facilitate sharing of data and to enable cross jurisdictional analysis. Identified data themes include cadastral (property ownership), hydrography (surface waters), transportation, ortho-imagery (corrected aerial photographs), and topography (elevation) data sets.

Data components of the transportation framework may include line work, feature codes, attributes, and a linear referencing system (LRS). In addition to data, the framework will include development of the institutional relationships needed to maintain the framework over time. This would include such things as identifying roles for contributing and maintaining the framework, or funding and other incentives for partners to contribute to the framework.

Previous work to be considered includes the WSDOT LRS, the Puget Sound Regional Council pilot project findings, WADNR Forest Roads project, and work of the Washington Framework Management Group (FMG). Standards, guidelines, and vision for the framework concept in general and transportation framework specifically are available through the Federal Geographic Data Committee (FGDC). Finally, other states' efforts will also be reviewed and considered.

4. Approach

The approach to developing the framework is to start with an initial consensus of what the framework will consist of as defined by this charter. The next step will build on the understandings documented in the charter to further identify partners, their business needs, technology available, and a data model. A pilot project will then be undertaken for a limited geographic area (i.e. a few counties) and limited data contents (i.e. roads, railroads, bridges, and culverts) to show what it takes to do a framework and whether we can do a framework. Throughout, institutional arrangements necessary to facilitate the framework will be identified and implemented.

A project team will be formed to be responsible for scope, objectives, and overall success of the pilot project. A technical team reporting to the project team may be formed towill make recommendations to the project team.

The data model to be developed will be inclusive. That is, the model will be developed to meet the business needs that are identified to the greatest extent possible while avoiding analysis paralysis. If the pilot determines full scope data modeling is not practical, the scope may be limited to allow the project to move forward. Data population of the database during the pilot will be limited in geographic area and contents in order to test the data model and framework processes at a lower cost.

It is anticipated that development of the transportation framework will be an iterative process that will result in changes to this charter and to requirements as we learn.

5. Objectives

The project objectives identify the major things that need to be accomplished to implement the transportation framework. It is anticipated that these objectives will be refined as the project progresses and more is learned about business needs, the capabilities of existing technology, and the condition of existing data. These are summary objectives. See Appendix A for details.

5.1. Identify and recruit partners to develop, maintain, and distribute the transportation framework and framework data that meets a set of business and analytical needs defined by the partners and users.

5.2. Develop a transportation framework data model and standards based on business and analytical needs for the data, technology available to implement the model, and the ability to provide and maintain the data over time.

5.3. Define and implement institutional arrangements to facilitate data collection and maintenance partnerships, and to make the data accessible at the least cost with the least restrictions on use.

5.4. Implement interactive platform independent software, database, and processes to support integration of data received from data providers, maintenance of data by data stewards, and data accessibility by partners and the general public.

6. Scope

The project scope identifies the boundaries of the transportation framework development efforts. The scope defines elements of the transportation framework that will be considered for inclusion in the framework. Topics include contents, extent (geographic area), resolution (scale), datum (horizontal and vertical), metadata, linear referencing, feature attributes, institutional arrangements, data integration (within the transportation theme and between the transportation theme and other framework themes), data quality, technology, software, and tools. It is anticipated scope will be different for requirement definition, pilot, initial implementation, and future capabilities. See Appendix B for an initial scope definition details. The scope will be revised as business needs are defined in the pilot.

7. Assumptions

7.1. Sufficient partners representing data providers and data users participate in the project.

7.2. Funding is available from partner organizations for a project manager, data modeling, and software development.

7.3. Key staff resources are available and can be scheduled to complete project tasks.

7.4. Agreement can be reached on a common data model.

7.5. Agreement can be reached on a common linear referencing system.

7.6. Technical capabilities are available to support business needs.

7.7. A phased approach will be utilized to develop the framework incrementally.

7.8. Existing infrastructure will be used to make transportation framework data accessible.

7.9. The transportation framework project and other framework projects will be coordinated.

8. Critical Success Factors

Critical success factors are those items that need to be addressed to increase the ability of the project to succeed in meeting the objectives. These factors were established by identifying possible problems and associated preventative actions. The list below is a summary. See Appendix C__ for the contingency chart used to develop the critical success factors details.

8.1. Establish broad participation.

Identify and recruit partners who . . .

can identify a business case for investing in the transportation framework,.

represent a range of uses of the database,

are needed to create full data coverage. of the state,

8.2. Establish standards which enhance the will and ability of partners to collect and maintain the data.

Match the standard to the ability of the partners to collect and maintain the data.

Identify a standard which allows data quality to improve over time.

Identify funding incentives for partners to participate.

8.3. Provide the data needed to meet business and analytical needs.

Data must be . . .

Accurate.

Complete.

Not too complicated to use.

Described.

Up-to-date.

Relevant to business and analytical needs.

8.4. Define a data model that partners agree meets their needs.

Identify business needs and functional requirements, and define the data needed to support them.

Examine existing data models.

Seek consensus agreement on the data model. Partners commit to achieving consensus.

Provide frequent and on-going communication of progress and decisions to partner organizations.

8.5. Identify the right standards and processes.

Identify standards and processes needed to meet business needs.

Examine existing standards and processes.

Identify standards and processes needed to facilitate integration of data from multiple sources.

8.6. Identify standards and processes that recognize the capabilities of existing technology to support the standards and processes.

Identify standards and processes that recognize the capabilities of existing technology to support the standards.

Provide tools for data integration, data access, and metadata.

8.7. Phase development.

Set the scope of phases to allow delivery of tangiblea products within a set time framethe biennium. For example, set the scope of the next phase to be the data model pilot prototype with completion by June 30, 2001. Expect on-going growth and improvement.

9. Key Deliverables

9.1. Data Model.

9.2. Database.

9.3. Data access and distribution software and process.

9.4. Data integration standards, processes, and tools.

9.5. Partnership agreements.

9.6. Definition of roles.

9.7. Pilot project to populate the database - limited geographic area and limited data contents.

9.8. Plan for maintaining the transportation framework.

9.9. Project report. Include lessons learned and recommendations for future direction and follow-on phases.

10. Outcomes and Measures

10.1. Partners are successfully recruited to define, develop, and populate the transportation framework.

10.1.1. Measure: Members represent 75% of the Regional Transportation Planning Organizations (RTPO). Members are representative of transportation interests (both users and providers) from federal, state, local, and private entities.

10.2. Partners agree that the data model meets their needs.

10.2.1. Measure: Consensus on the draft data model is established for the pilot.

10.3. Partners can get fromcontribute data to and use the transportation framework data that meets identified business needs.

10.3.1. Measure: Partners agree data meets their business needs as identified for the pilot.

10.3.2. Measure: Partners agree that data integration tools are satisfactory.

10.4. The transportation framework is available at the least cost with the least restrictions.

10.4.1. Measure: Partners agree on the cost and restrictions for accessing transportation framework data.



11. Project Organization

12. Roles and Responsibilities

12.1. Washington State Geographic Information Council (WAGIC)

The WAGIC is recognized as the statewide body responsible for coordinating and facilitating the use and development of Washington State's geospatial information. WAGIC is an advisory body to the Framework Management Group (FMG) and supports the vision of the Washington Geospatial Data Framework. WAGIC serves as a resource for dispute resolution and/or deadlock decision making to the FMG.

12.2. Framework Management Group (FMG)

The FMG is a consensus building body that provides overall direction to individual framework projects. The FMG determines framework priorities, identifies and facilitates resolution of common framework issues, and ensures coordination among the projects. Overall framework decisions and decisions that are out of individual project scope are made by the FMG. Widespread participation is solicited and encouraged from federal, state, local, private, tribal, and professional organizations.

12.3. Transportation Framework Project Manager

The Transportation Framework Project Manager is responsible to lead development of the transportation framework. This includes leadership of the project team, reporting of progress and milestones to the Framework Management Group, cross project coordination with other framework projects, successfully recruit project partners, arrange resources for the project, project planning and schedule tracking, and project budget and expenditure tracking. The project manager may appoint a technical team leader for that group.

12.4. Transportation Framework Project Team

The Transportation Framework Project Team is made up of representatives from the partner organizations. The project team is responsible for the project scope, objectives and overall success of the project. A technical team may be formed to develop the data model, standards, processes, tools, etc. Final decisions on technical team recommendations are made by the project team.

12.5. Transportation Framework Technical Team

The technical team functions as the working group for the project. The technical team consists of experts in data production, data use, data access methods, etc. The technical team provides decision options and recommendations to the project team. Final decisions are made by the project team.

12.6. Administrative Support

The Administrative Support person is responsible for: scheduling of project meetings; booking, setting up and taking down meeting rooms; communication with participants; preparing and distributing project documentation; taking and distributing meeting notes; maintaining contact lists; and, working closely with the Project Manager to support the success of the project.

13. Project Resources







14. Funding







15. Decision Making Process

Decisions are made by consensus. Consensus is achieved when:

Everyone has a chance to offer their ideas and opinions

Everyone's ideas and opinions are considered

Most are in support and no one actively opposes the decision

Everyone will support the decision



If consensus is in doubt or a critical decision is being made, then a voting procedure will be used as follows:

Four fingers raised = I will support it

Three fingers raised = I will not oppose it

Two fingers raised = I will not support it

One finger raised = I cannot live with this. It conflicts with my organizational goals and/or personal values.



If anyone in the group raises one or two finger(s), the decision is stalled and discussion must continue until all votes indicate three or more fingers. In the case where a decision is deadlocked, the FMG has the option of presenting the issue to the WAGIC for resolution.







Objective - Summary Objective - Detail
Identify and recruit partners to develop, maintain, and distribute the transportation framework and framework data that meets a set of business and analyical needs defined by the partners. Identify and recruit the partners that will use the transportation framework database and can provide funding for their needs.
Identify and recruit partners needed to create full coverage of the state
Identify sources of existing data and producers of data.
Identify data/business needs of least common denominator of partners to get them to participate
Identify common data needs for partners to participate.
Develop the business case - may vary by organization (partner).
Identify benefits.
Identify incentives for partners to participate.
Develop a transportation framework data model based on business and analytical needs for the data, technology available to implement the model, and the ability to provide and maintain the data over time. Identify data/business needs of least common denominator of partners to get them to participate. (R)
Identify common data needs for partners to participate. (R)
Identify business functions and data needed to support them.
Set data standards which allow for analytical needs to be met.
Identify and develop consistent, connected, compatible data organization scheme.
Determine ground rules for data access and use.
Identify the technology environment for data storage, data management, data access. (From CSF.)
Develop the long term strategy for improving data over time.
Develop, maintain, and distribute transportation data.
Define and implement institutional arrangements to facilitate data maintenance partnerships, and to make the data accessible at the least cost with the least restrictions on use. Identify roles to develop, maintain, and distribute data and metadata.
Identify funding to provide data at minimum cost.
Identify incentives for partners to participate.
Make data available at the least cost with the least restrictions on use.
Implement interactive software to . . .
- integrate data
- maintain data (import/export tools?)
- make data accessible		 Identify the technology environment for data storage, data management, data access. (From CSF.)








Pilot		 Initial Implementation Future
Capability
Comments
1 Contents
2 Roads x Do all to determine req. for full implementation.
3 Federal x
4 State x
5 City Streets/County Roads x
6 Private - Lg land owner x Needed for EMS.
7 Private - Lane, drive x Who does these?
8 Railroads x
9 Trails
10 Waterways
11 Transmission Lines
12 Pipe Lines
13 Other facility
14 Bridges x
15 Culverts x
16
17 Airports
18 Seaports
19 Mall
20 Other nodes
21 Transit Stations
22 Transfer Points
23
24 Transit Routes TBD
25 Ferry Routes TBD
26 Freight Routes TBD
27 Other routes TBD
28
29 Linework x
30 Feature Codes x
31 Attributes - imbedded TBD
32 Attributes - external TBD
33
34 Linear Referencing x
35 Linear Datum Data Model - Spatial
36
37 Extent - Geographic Area
38 Limited x A few counties for the pilot.
39 Statewide maybe? Statewide is long term goal.
40
41 Time Sensitive
42 Current Data
43 Historical Data
44 Roll Back/Roll Fwd
45
46 Existing x
47 Proposed x
48 Vacated x
49
50 Resolution/Scale
51 Fixed No!
52 Multiple x
53
54 1:500,000
55 1:100,000
56 1:24,000 x Minimum is 1:24K.
57 Larger x Urban up to 1:1200?
58 Smaller
59
60 Horizontal Datum
61 State Plane Coord. x
62 Latitude/Longitude x
63 Other x
64
65 Vertical Datum
66 Identify Standard x
67
68 Metadata
69 Standards Defined x
70 Required x
71
72 Feature Attributes
73 Limited to Key ? Determine in the pilot.
74 Imbedded in spatial file. ? Determine in the pilot.
75
76 Data Development
77 Centralized
78 Distributed x
79
80 Based on Political Boundary
81 By feature owner x Determine in Pilot
82
83 Data Maintenance & Update
84 Centralized
85 Distributed x
86
87 Based on Political Boundary
88 By feature owner x
89
90 Data Model
91 Vector x Lines, points, routes
92 Raster x
93
94 Data Distribution
95 Access - Open x
96 Access - Limited x Limit to partners for the pilot.
97
98 Cost - Free TBD Goal: Least cost.
99 Cost - Recovered TBD Goal: Least cost.
100
101 Format - Open TBD
102 Format - Proprietary TBD
103
104 Data Integration - Spatial Between modes e.g. intermodal connectors.
105 Within Trans Theme
106 Allow gaps/overlaps (and other data quality issues.)
107 Resolve ambiguities x Happens between jurisdictions. e.g. at county
108 Dev. methods to eliminate x boundary or county/state intersection.
109
110 Between Themes
111 Allow gaps/overlaps x Determine magnitude of the problem.
112 Resolve ambiguities x Determine magnitude of the problem.
113
114 Data Quality
115 Certify Data Producers x
116 Test Data Quality ? Compare to ortho photo?
117 Dev. criteria for data quality x
118
119 Software and Tools
120 Identified x
121 Developed x Prototype.
122
123 Data Integration x
124 Data Access x
125 Data Quality Testing ? Identify needs.





Possible Problems Preventative Actions
Fail to have broad participation - fail to identify and recruit partners. Identify and recruit partners needed to create full coverage of the state.
Identify and recruit partners who represent a range of uses of the db.
Identify benefits/business case to potential partners to encourage their participation.
Fail to have broad participation - partners are missing. Identify and recruit partners needed to create full coverage of the state.
Identify and recruit partners who represent a range of uses of the db.
Partner reps commit to participate in activities or arrange substitutes.
Fail to have broad participation - Wrong reps - can't speak for the org. Document organizational commitment - leads to responsible reps.
Partners are not committed - lack the will and/or ability to collect and maintain data that meets the standard. Identify a standard which matches the ability of the partners to collect and maintain the data.
Identify a standard which allows for data quality to improve over time.
Identify a standard which allows for data of varying quality and resolution to be mixed in the db.
Identify incentives (funding) for partners to participate.
Don't provide the needed data . . . inaccurate data. Provide metadata which indicates the quality of the data.
Develop criteria for data quality within the transportation db and with other framework db's.
Develop the long term strategy for improving the data over time.
Identify roles to develop, maintain, and distribute the data.
Don't provide the needed data . . . incomplete data. Identify a model which allows for incomplete data - i.e. it works for the data that it contains.
Identify a model which allows for multiple partners to contribute and maintain the data they are responsible for.
Don't provide the needed data . . . data is too complicated. Test the data model with data providers to ensure they have the ability to provide data which meets the model; with the data integration process to ensure that integration tools can be developed; and with data users to ensure that it provides useful data.
Don't provide the needed data . . . data is not described. Provide metadata which indicates the contents of the data.
Don't provide the needed data . . . data is out-of-date. Provide metadata which will indicate the currentness of the data.
Establish update cycle and schedules which meet the needs of data users and the abilities of the data providers.
Don't provide the needed data . . . data is not relevant to the business need. Develop the data model based on business need.
Develop the data model to allow analytical needs to be met.
Data doesn't meet the needs (useful) of users e.g. map scale doesn't meet the needs of local agencies. Develop a data model which allows for multiple resolutions of data representing the best available data. Develop the long term strategy for improving the data over time.
Don't achieve agreement on a model which meets business needs. Identify data/business needs of least common denominator of partners to get them to participate.
Identify business functions and data needed to support them.
Identify and develop consistent, connected, compatible data organization scheme.
Seek consensus agreement on data model. Partners commit to work toward consensus.
Provide on-going communication of progress and decisions to partner organizations to avoid surprises.
Don't have the right standards. Identify standards which meet business needs.
Identify ground rules for data access and use.
Technology is not available to implement the model. Identify standards which recognize the capabilities of existing technology to support the standards.
Provide tools for data integration.
Take too long to deliver. (Deliver a product within a biennium. Expect on-going growth and improvement. Identify phases of development which deliver tangible products within time constraints of budget process.
Identify phases of development which deliver tangible products within constraints of budget process and ability of partners to provide data and products.
Identify the time frame for achieving success. e.g. "in 2 years, recruit x partners."