Statewide Data and Information Systems Committee
menu 1
menu 2
menu 3
menu 4
menu 5
menu 6
menu 7
menu 8
menu 9

 

Data Partnerships - Making Connections for Effective Transportation Planning
TRB Statewide Transportation Data Committee Peer Exchange
AASHTO Data Task Force of the Standing Committee on Planning

May 21, 2003
Duck Key, Florida

(DRAFT 6/30/2003 E-Cxxx)

James P. Hall, Editor

The Transportation Research Board is a unit of the National Research Council, a private, nonprofit institution that is the principal operating agency of the National Academy of Sciences and the National Academy of Engineering. Under a congressional charter granted to the National Academy of Sciences, the National Research Council provides scientific and technical advice to the government, the public, and the scientific and engineering communities.

The Transportation Research Board is distributing this Circular to make the information contained herein available for use by individual practitioners in state and local transportation agencies, researchers in academic institutions, and other members of the transportation research community.  The information in this Circular was taken directly from the submissions of the authors.  This document is not a report of the National Research Council or of the National Academy of Sciences.

Contents
Background
3
Minnesota Department of Transportation - Jonette Kreideweis
7
Michigan Department of Transportation -Ron Vibbert
12
Pennsylvania Department of Transportation - Tom TenEyck
17
Florida Department of Transportation - James Golden
20
Kentucky Transportation Cabinet - Rob Bostrom
23
Colorado Department of Transportation - Tim Baker
30
Illinois Department of Transportation - James P. Hall
33
Alaska Department of Transportation and Public Facilities - Jack Stickel
34
Texas Department of Transportation - Kim Hajek
38
Peer Exchange Summary
41
List of Participants
44
Appendix A: "Issues and Challenges to Data Partnering" Survey Instrument
46
Appendix B:  Survey Results
49

Background
SCOPE

Statewide planning requires a variety of transportation system, land use, passenger, freight, demographic, economic and environmental data from many different federal, state, regional and local sources.  Establishing effective partnerships for sharing data can optimize available resources and enhance the quality of data brought to the decision making process.  Evidence also shows that sharing data early in the decision-making process increases stakeholder support and decreases process timeframes.

Connecting disparate data sets is often complicated by cultural and institutional factors, as well as how data are defined, collected, derived, stored and managed.  New ITS and GIS technologies for collecting data are raising additional challenges relative to data imputation translation, data archiving and the integration of spatial data with differing accuracies.

To address some of the benefits and challenges facing the development of transportation data partnerships, a peer exchange was held on May 21, 2003. Invitations were extended to members of the TRB Committee on Statewide Data and Information System and other participants who are involved or interested in data partnerships and transportation planning. Participants shared recent endeavors in data sharing for statewide transportation planning.   From the discussions, a synthesis of effective strategies, methods and tools was identified for addressing factors that influence the  sharing of spatial and other data between and within federal, state and local governments.

FORMAT

Prior to the Peer Exchange, a survey was distributed to all A1D09 Committee members to determine the most critical issues and factors affecting the sharing of data at the federal, state and local levels.  The results were presented and discussed at the beginning of the Peer Exchange. Next, each participant shared a specific example of a project or initiative that involves integrating and/or sharing data in one of the following four categories of data partnerships:

  • Planning and safety data partnerships
  • Management systems data partnerships (e.g. pavement, bridge, asset management)
  • Federal, state, MPO, local government data partnerships
  • Planning and operations data partnerships

Presentations included a discussion of the one to three most significant issues, challenges and opportunities encountered in data partnering within the chosen category and how they were overcome or resolved.  The presentations were followed by brief discussions of how others in the group were managing similar issues within their agencies. These lessons learned are contained in the summary of the report as well as key aspects for  successful data partnering and effective strategies to implement partnerships.

SPONSORS

The Peer Exchange was organized by the Statewide Transportation Data and Information Systems Committee (A1D09) and the Data Task Force of the AASHTO Standing Committee on Planning.  The FHWA Office of Planning and Environment provided funding.

PARTICIPANTS

  The following attended in the 2003 Peer Exchange:

  • Tim Baker, Colorado State Department of Transportation
  • Bob Bini, FHWA/Federal Lands Highway
  • Thomas Bolle, Bureau of Transportation Statistics
  • Rob Bostrom, Kentucky Transportation Cabinet
  • Ed Christopher, FHWA, National Resource Center
  • James Golden, Florida Department of Transportation
  • Kim Hajek, Texas Department of Transportation
  • James Hall, University of Illinois at Springfield
  • Patricia Hendren
  • Pat Hu, Oak Ridge National Lab
  • Barna Juhasz, Federal Highway Administration
  • Anthony (Tony) Kane, AASHTO
  • Jonette Kreideweis, Minnesota Department of Transportation
  • Bruce Lambert, Federal Highway Administration
  • Ron McCready, Transportation Research Board
  • Tom Palmerlee, Transportation Research Board
  • Roger Petzold, Federal Highway Administration
  • Ron Ratliff, RSH
  • Jack Stickel, Alaska Department of Transportation
  • Tom TenEyck, Pennsylvania Department of Transportation
  • Anita Vandervalk, Cambridge Systematics
  • Ron Vibbert, Michigan Department of Transportation 
INTRODUCTORY REMARKS

Anita Vandervalk, facilitator of the peer exchange and chair of the TRB A1D09 Statewide Transportation Data Committee, welcomed the participants.  She reiterated the purpose of the peer exchange to share best practices in data partnerships for statewide transportation planning.  The goal of the meeting was to identify effective strategies, methods and tools to address factors that influence capabilities to share spatial and other data between and within federal, state, and local governments.  Other groups represented at the peer exchange were the AASHTO Standing Committee on Planning Data Task Force, the Federal Highway Administration, and the Bureau of Transportation Statistics.  Anita then presented the results of a preliminary survey on data partnerships

DATA PARTNERING SURVEY

A survey, "Issues and Challenges to Data Partnering" distributed prior to the peer exchange, asked committee members to rank the following issues in terms of importance and the need for assistance:

  • Cultural and institutional barriers
  • Roles and responsibilities of partners
  • Data definitions and standards
  • Technology, equipment and connectivity
  • Data integration
  • Data with different spatial accuracies and resolutions
  • Archiving and managing large data sets
  • Resources, funding and cost sharing
  • Quantifying and qualifying the value and utility of data partnering investments
  • Data privacy and security
  • Management leadership and support

The results of the survey are shown in Appendix B.  From the survey results, the areas that committee members believed were most important were:

1. Management leadership and support

2. Data integration

3. Data definitions and standards (tie)

3. Resources, funding and cost sharing (tie)

3. Quantifying and qualifying the value and utility of the data partnership investments (tie)

Areas that committee members identified as requiring a high need for assistance were:

  1. Quantifying and qualifying the value and utility of the data partnership investments
  2. Data integration
  3. Data definitions and standards

The survey results provided an important foundation for the Peer Exchange discussions and participants expressed an interest in gathering more data. The committee considered distributing the survey to additional data practitioners before the TRB annual meeting to strengthen the validity of the results and provide more insight into the challenges facing data partnering.

STATE PRESENTATIONS

The peer exchange continued with presentations by representatives from state DOTs on the data partnership issues and experiences in their state.

Minnesota Department of Transportation Perspective
Jonette Kreideweis, Minnesota Department of Transportation

Jonette Kreideweis presented the Minnesota experience in the use of safety data partnerships.

Introduction

Data partnerships are becoming more and more a way of doing business at the Minnesota Department of Transportation (Mn/DOT).  This is especially true in today's environment where there are diminishing resources, growing data integration opportunities and incredible new tools and technologies for sharing data. In this presentation, I would like to focus on the partnerships that have evolved for the use of safety data.  Over time, strong partnerships within the department and with external state, regional and county agencies have evolved to help us improve the quality and utility of the crash data we provide.

Background

To accomplish our vision has required strong partnerships within the department among many different functional areas, including:

  • The Office of Transportation Data and Analysis maintains data on the physical characteristics of roadways and is the steward of the department's Transportation Information System (TIS).
  • The Office of Traffic, Security and Operations is responsible for crash data reporting and broad statewide safety planning.
  • The Geographic Mapping and Information Section produces the Mn/DOT's GIS BaseMap.
  • The Information Technology Office provides support and assistance on equipment, network and application issues.
  • The GIS Support Unit is helping build a new and more stable linear datum for locating crashes and other key planning level data.

One of the most critical crash data partnerships is outside of the department.  In Minnesota, the Department of Public Safety (DPS) is responsible for coding crash data from accident reports. Over the years, strong and collaborative partnerships have been necessary between DPS and Mn/DOT to manage the transfer and archiving of crash data. 

Safety Data Management

Nearly 30 years ago, Mn/DOT began building a large mainframe Transportation Information System (TIS) to house crash data, as well as data on roadway characteristics, bridges, pavements, traffic and railroad crossings.  A major impetus for building TIS was the need to automate and improve the transfer of accident and crash report information between DPS (the Department of Public Safety) and Mn/DOT.

Since the development of TIS new information, tools and technologies have come along to significantly improve how data is shared and managed between the two departments.

Mn/DOT has provided DPS with better tools for locating accidents and crashes.  For example, all ramps and intersections have been drawn with location coding instructions.  Electronic connections have been built so that DPS personnel can view Mn/DOT's videolog system and access enhanced crash location and data editing tools.  In addition, new electronic data transfer mechanisms are available for downloading "sanitized" crash data from the DPS database to Mn/DOT's TIS on a monthly basis.  And, efforts were initiated to move Mn/DOT's TIS from the mainframe to Oracle to provide GIS and mapping capabilities and more efficient data reporting features.

Even with all of these changes continuing challenges remained.  There were limitations in TIS linear referencing methods:

  • Ramps and loops were not in the system.  Routes could only carry one name, so accident coders ran into difficulties when there were crashes on routes with multiple names or coincident routes carrying two or more numbers.
  • There were also problems with trying to establish reference off-sets for local roads. 
  • There were no methods for displaying past or future roadway networks.  Historical data was always mapped to the most "current" roadway system. 
  • Databases that interfaced with crash data were using different linear referencing methods for identifying locations on the highway system.
  • In addition, data on roadway changes had to be entered separately  -- first into the Mn/DOT GIS BaseMap and then secondly into TIS Oracle.

This resulted in several key "make or break" issues, including:

  • Crash data were still being coded to wrong locations and tools for editing and correcting locations were not readily available.
  • Regional, county and city governments could not directly access crash data once it was transferred to Mn/DOT's TIS because of security provisions.
  • Many independent crash databases were being maintained, resulting in potentially conflicting results.
  • Mn/DOT's linear data were just not good enough for other applications such as routing or asset management.
Mn/DOT's New Location Data Model

After much debate and analysis, the department elected to build a new linear referencing system that will provide:

  • A stable method for determining the location of transportation facilities and managing data that is located on the system.
  • Transparent tools that permit data conversions between:
    • Different linear referencing methods
    • Difference coordinate system
    • Spatial and linear reference systems
  • A central web accessible "geo-data store".
  • Tools for easy data entry, display, map editing and reporting.
  • Methods for importing and converting data in various formats.
  • Applications, tools, methods and components that are shareable and reusable for other data system needs in the department.

Mn/DOT's new Location Data Manager (LDM) is a custom applications developed by Bentley Transportation.  It will create and maintain stable linear references for all 440,000 public road segments in Minnesota.  In addition, it is being structured to eventually handle all segments in the state's multi-modal transportation network.

The LDM model is based on a system of anchor points and anchor segments.  Anchor points are intersections or endpoints.  Each will have a unique number and x, y locations.  Anchor sections permanently identify a section of pavement in the real world.  They represent the area between anchor points.  Each anchor segment has a unique number, direction (from and to), length, and length source. 

Users will typically not see anchor points or sections.  Instead, they will interact with the cartographic representations or graphic reps of the anchor points and anchor segments.  The LDM is being designed to permit conversions of data with differing accuracies or resolutions.  As a result, an anchor segment may have multiple graphic reps based on different scales and data sources.  Events such as crashes or traffic volumes are displayed at the appropriate percentages along whichever graphic representation the user selects.

For the first time, the new LDM will give us the capacity to store historical and future data on roadway and other transportation features.  Anchor sections may be added or retired in accordance with physical changes to the geometry of the pavement section.  The anchor segment number and the data attached are coded with an "active", "retired" or "proposed" status and date and remain in the system until modified by the data stewards.

The LDM is compatible with the National Spatial Data Infrastructure standards (NCHRP20-27).  In the end, the new model will provide a stable identifier for clearly defined sections of pavement, thereby allowing sharing of data between participants.

Current Status

Mn/DOT began work on the LDM in 2002.  At this time, the entire TIS roadway network is being synchronized to the Mn/DOT GIS BaseMap for all 135, 000 miles and 440,000 anchor segments.  This means that all roads for all systems will be identified and all beginning and end points (graphic representations) will match.  New web reporting tools are under development to provide users with easier access to data.  In addition, a new "Mn/DOG" (preliminary name) access tool is under development to "fetch" and integrate data from multiple systems and applications. 

The synchronization of TIS with the Mn/DOT GIS BaseMap is a huge undertaking.  Perfectly synchronizing all road segments is taking 1-3 months per county.  On the partnership side, new agreements have been initiated with the GIS Departments at St. Cloud State University and the University of Minnesota Duluth to assist with this effort.

Continuing Issues

Despite the progress made thus far, there continue to be issues.  Mn/DOT, like many state and local governmental agencies, has fewer resources available for maintaining data and map layers.  At the same time, the roadway network in Minnesota continues to change, expand and contract.


The mound of roadway and mapping status changes is increasing, especially for counties and cities experiencing rapid growth.  In addition, as we get closer to the end of the project, there are rising expectations for new data layers and system interfaces.  Some go beyond plotting traditional data on the roadway network.  For example, we are beginning to be asked how the location data model can help with   emergency services, security, bus and over-dimension vehicle routing.   And, today our external partners are still requesting paper or electronic data reports and hand entering crash, traffic and other Mn/DOT data into their own systems.

Next Steps

With the new data and mapping tools almost in hand, we are starting a new round of data partnerships with county highway agencies..  A Mapping and transportation Data Partnerships Pilot Project is currently underway with five counties in Minnesota to utilize the new tools for sharing data reporting and maintenance responsibilities. Through the project we hope to:

  • Reduce redundancies by entering data only once and sharing it often
  • Provide users with easier data access, display, mapping and reporting capabilities.
  • Move responsibilities for data maintenance closest to those who are most likely to have the most accurate data.
  • Minimize conflicting data sets.
  • Optimize available resources.

We will be using the new location data model structure to convert and share data with a variety of different linear reference systems through web based servers and browsers. 

Partnership Benefits

Benefits from the series of partnerships that are evolving around safety and crash data include:

  • The development of a more complete and up-to-date roadway network.
  • Better quality crash data, with a higher percentage of accidents coded to the right locations.
  • Empowered partners who no longer have to call Mn/DOT to map and report on crash data for the highway systems under their jurisdictions.
  • Improved data and tools for safety planning and program development, particularly projects designed to address federal Hazard Elimination Safety (HES) goals and objectives.
  • Enhanced data and tools for other applications such as security and evacuation planning, over-dimension vehicle routing, bikeway and trail system development, construction project scheduling and detour planning and maintenance operations activities.
Lessons Learned

We realized from the start that a project of this magnitude required strong backing from senior management, strong project management skills and strong support from all the project partners, including those deep in the organization that code the data.  At the beginning we needed to address people and resource issues. 

As we moved along we realized that we also needed to look at how we could shift resources to meet needs and work with new partners to get work done faster.   We also needed to involve all the partners in frank and open discussions about data quality and timeliness and we needed to carefully review our processes to see where there might be opportunities for streamlining and redesign.

Conclusion

We believe that we are in the home stretch of the project.  There are tangible results.  Crash data can be mapped to all systems and soon partners should be able to update, edit and report data for the systems they have jurisdiction over.  Less tangible evidence suggests that there are other changes occurring as well.  Slowly roles are shifting and relationships are expanding.  The culture is becoming more outwardly focused and data and mapping tools are becoming more relevant and useful to customers

Michigan Department of Transportation Perspective

Ron Vibbert, Michigan Department of Transportation

Ron Vibbert presented Michigan Department of Transportation's (MDOT) experience with integrating crash information across the MDOT, the Michigan Department of State and the Department of the Michigan State Police.

This presentation discusses some of the cultural, as opposed to technical issues that had to be overcome as Michigan re-designed the processes that collect, analyze, and distribute crash data. The problem addressed was one of multiple agencies use of data that was cumbersome to gather, edit, and then distribute to its many customers. Along the way each of the agencies had to deal with their different financial, legal and technical environments as well as their widely differing missions within state government.

The Michigan State Police is required to collect crash reports (UD-10) from every police agency in the state for crashes where property damage is greater than $400. This consists of supplying crash data forms to each police agency on a periodic basis. As the forms come in they are run through a scanner where there's an attempt to extract information that has been 'bubbled' in, and then they are sent to an outside company where other data is keypunched into flat files. These are sent back to the MSP and loaded into the mainframe where the bubbled data has also been loaded. At the same time the crash diagrams are assembled, and microfiched. Crash location at one time was also done during this process.

The State Police would then do a close out of the previous year's data and then distribute that data to various users. These users include planning agencies, some local police agencies, Michigan's Department of State (which handles driver and vehicle records), universities, county and city road and street agencies, NTSA, and the Michigan DOT

There are no requirements that local police agencies submit data on time. Also, there was no feedback loop where the police agencies were notified of errors made, so they could be corrected. As a consequence, rash reporting on the local level has been sporadic, slow, incomplete, and contained many errors.

Cultural Differences and Making Change

Correcting data accuracy and timeliness issues problems had been attempted several times over the last 20± years. While best efforts and intentions were made, the institutional and cultural differences between the participants led to some, but not substantial changes and progress being made. Since success was rare, efforts tended to focus on immediate and achievable results, without dealing with the underlying issues. The cultural differences between each of the participating agencies directly involved in implementing change, more than the technical and process issues, had limiting effects on the amount of success that could be expected in the short term.

Michigan State Police

Police are "in charge", with a top down command and control environment. Crime prevention and solution are viewed as the critical mission of the organization, not crash reporting. Thus, the location of a crash is not viewed as a mission critical item, and crash locations have been error ridden. UD-10 forms were viewed as being primarily useful to insurance companies, and not to the engineering community.

Michigan Department of Transportation

MDOT engineers, in comparison to the police agencies, are much more accustomed to teamwork, having as part of their primary function to implement projects involving many disciplines at locations. Detailed crash information, including the detailed location of crashes over time to identify engineering solutions are mission critical in the department's mission to provide safe transportation facilities.

Michigan Department of State

The Michigan Department of State also relies on crash data, as it is responsible for driver's licenses, tickets, violations, vehicle registration & licensing, and closely related items. As with the state police, location is not an important item, but the disposition of crashes as they affect drivers and vehicles is mission critical to their function. There is an element of enforcement in their activities, but is more concerned with the disposition of vehicles and drivers, and looks at these from a record keeping stance.

Institutional and Technical Differences between Departments

A key difference between the departments and specifically between MDOT and the departments of State and State Police are the sources and nature of funding, and the underlying technical environments

State and State Police

Transportation

Key punch/data entry

Mainframe, monolithic

Ask permission

Budget focus

1 Year horizon

Command and control

General fund

Data processing

Client-server, modular

Why not?

Results focused

Long term horizon

Teamwork, collaboration

Restricted funds

While these may be viewed as subtle, the differences in perspective and an agency's ability to accommodate change are very much a function of the time horizon of the agencies involved.

The more volatile and less dependable funding available to the departments of State and State Police cause a shorter planning horizon and thus limit their ability to undertake projects with a length much beyond the current and next fiscal year. Departments of Transportation are accustomed to multi-year projects and the funding sources to go along with it.

Another difference which actually aided Michigan in undertaking a process redesign was that MDOT had considerable experience in conducting and implementing business process redesign efforts. MDOT had already taken some components of the state's crash data and put them into a client-server, relational database environment, and thus could provide an alternative way of implementing changes outside of the monolithic mainframe environments possessed by the departments of State and State Police.

What Caused the Change?

Michigan would have likely continued the practice of manually keypunching, processing, and locating crashes, and distributing the crash data to customers until the state decided not remediate the crash location software to meet Year 2000 (Y2K). This left Michigan without a way of assigning locations systematically to crashes for MDOT's (and other transportation agencies) use in engineering and other analyses. Instead, Michigan engaged Michigan Technological University to write new crash location software based on "Michigan's Geographical Framework" (MGF) project. Using this new software Michigan has been able to locate about 75% of the crashes in a development environment. This was not an acceptable solution, but was the best that could be done in the short run.

What was the Status after Y2K?

Michigan had created 2 crash databases, based on the State Police's mainframe database. Each of these was created for different purposes, and contained somewhat different data elements. These databases were:

  • Management Systems to support the Safety Management System originally required by ISTEA
  • Crash Reporting Information System (CRIS)) - to provide crash reports for internal crash studies.

While each performed their intended function, they were somewhat inconsistent, making it possible for one to get different answers depending on which database was queried. For example, the Management System version of the crash data was updated only annually, but contained data for all of the state's roads. That meant however that the database was "current" for only one month of the year. The CRIS database was updated monthly, but contained only information for the state trunk line system. This made it useful for only a part of the crash data customers in the state.

The Change Process

Seat Belt Incentive money became available to Michigan in August 2001. Since the expenditure of these funds involved the agreement of MSP and MDOT to use, the departments agreed to address the crash data processing and location issues.

Business Process Redesign

This process included each of the principal departments, State, State Police, and Transportation, in identifying an 'ideal' traffic crash data process, and strategies to accomplish that 'ideal' process.

This week-long process included various planning agencies, non-state police agencies, and representatives of the insurance industry at various times to clarify what their uses were of the data, and to garner their view of what was important about the crash data they received.

As a result of this effort several decisions were made about the future of crash data processing and distribution, and efforts have been started to accomplish these. Each of these is intended to speed up processes to improve timeliness and accuracy. This also involved re-assigning some tasks across the agencies to take advantage of the strengths and advantages.

Process Assignments in the New Order
Michigan State Police

Initial data assembly and processing will remain the responsibility of the State Police. This is because MSP has existing relationships with Michigan's many police agencies, and it would be expensive and duplicative for another agency to establish and maintain a separate relationship for the sole purpose of obtaining crash report forms. The State Police will however establish a feedback process with police agencies to correct crash reporting errors, and to provide quicker turn around to local police agencies.

The crash location function will also remain as a state police function.

Michigan Department of State

The MDOS will receive information from the state police as it is entered into the system. In return the MDOS will validate vehicle and driver information live, to improve the quality of the crash data, as well as to provide better and To receive information as it's entered.

Michigan Department of Transportation

MDOT will be responsible for maintaining the statewide crash database, as well as the software developed to execute the crash processing and distribution function. This was decided because MDOT has had extensive experience with establishing and maintaining large Oracle databases, and in maintaining client-side code.

MDOT will also be responsible for distributing the crash data to crash data users.

Adding another Agency

After the software and database development effort started Michigan formed a Department of Information Technology to manage and operate all of the state's technology efforts and activities. As this is affecting this project and its longer term execution DIT staff will be responsible for the execution of changes to code and databases, while we anticipate the MDOT will be managing the DIT efforts after rollout and when we enter a production state. This is a new aspect to the project that was not anticipated. Many of the operational details have not yet been worked out.

Project Status

Phase I ($1.7 million±). This phase consists of developing the databases necessary to enable processing, as well as to distribute to crash data users. Data will be stored in Oracle databases and the software being written to assist in the processing and editing of crash data is being written in PowerBuilder. This is slated to roll out in late 2003, along with re-written software.

This effort also includes code modification to existing Management System and CRIS applications to reference and use the new databases. All other existing versions or permutations of crash data will be eliminated at that time.

Phase II (900K ±) will include web capabilities, and will enhance data distribution. This phase will take approximately 9 additional months to complete. This phase is fully funded at this point.

Pennsylvania Department of Transportation
Thomas TenEyck, Pennsylvania Department of Transportation

Tom TenEyck presented PENNDOT's perspective on Intergovernmental Data Partnerships.

Cultural and Institutional Barriers: Working with MPO and RPOs.

Data partnerships between Departments of Transportation and Metropolitan Planning Organizations (MPOs) and Rural Planning Organizations (RPOs) would seem to be a natural, and mutually beneficial.  Many goals are common - Transportation Improvement Programs (TIPs), Long Range Plans, transportation project development and implementation, and land use planning.  Still barriers exist:  bureaucracies, data quality software, technical skills and abilities, funding, etc.

As a follow-up to PENNDOT's annual conference with MPO and RPO Executive Directors, a Planning Partners GIS Work Group was formed to explore ways that the Department and the local planning agencies could enhance data partnerships and GIS efficiencies.

The Planning Partners GIS Work Group has been meeting quarterly for two years and has three main success stories to date.  First, the Work Group has become a forum for sharing GIS "best practices" as well as technology transfer.  Seventeen of the twenty five MPOs/RPOs in Pennsylvania are active members, participating in roundtable meetings.   Second, the Work Group identified key PENNDOT data items that would enhance MPO and RPO planning and program development efforts.  Sharing is via a secure File Transfer Protocol (FTP) server.  PENNDOT converts the data to ESRI shape file format because most of the planning partners use ESRI software.  About twenty tables that include data such as traffic information, roadway characteristics, bridge inventory data, crash data, etc. have been made available to MPOs/RPOs.  Third, PENNDOT is funding uniform GIS training for the MPOs and RPOs.   One of the MPOs is doing the contract management, and a subgroup of the Work Group developed the curricula and contract scope of work.

While the Work Group is still a new initiative, the cooperation developed here has shown benefits in other cooperative efforts such as data collection, project development, TIP approval, and long range planning.  Barriers remain, however.

  1. PENNDOTs mission generally and PENNDOT GIS's mission specifically may not always coincide with the Planning Partners', so work flows, processes, and data often fit one side better than the other.
  2. Largely because of differing business requirements, data quality (and data precision) requirements at the state level may not be on a par with local requirements.  Similarly, the GIS software platform at PENNDOT differs from the Planning Partners'.   This is not a data sharing issue, but it does matter in the area of technical support capabilities.
  3. Planning Partners sometimes view PENNDOT as a resource pool; as a result, Planning Partners' support and funding expectations may not be consistent with PENNDOT's GIS resources.
Resources, Funding, and Cost Sharing

Funding issues are always at, or near the top of the list when it comes to inter-

agency partnerships.  Two recent Pennsylvania examples will be shown here.

PENNDOT has established a partnership with the Pennsylvania Historic and Museum Commission.  The partnership involves a sharing of expertise and cultural resources data.  PENNDOT receives cultural, archaeological, and historic data which is critical to project development.  In addition, since this data is shared, the review process has been streamlined.  Environmental managers now share maps across the PENNDOT Intranet; data items are quickly available and in GeoSpatial form.

The PHMC used PENNDOT expertise to take paper maps and other documents, many of which were deteriorating, and create a cultural resource relational database and a web-based GIS application to view and analyze the data.  The PHMC and its clients can now examine preservation from a broad perspective, asking questions on importance, effort to preserve, and long term serviceability of the property, all with spatial tools.

PENNDOT provided funding support for software and hardware acquisition, software development, and cultural resource data processing and database creation.  In addition, PENNDOT manages and supports the cultural resources database on its GIS server.  The PHMC provided in kind services as part of this cost sharing partnership.

PENNDOT also has a spatial data partnership with the Pennsylvania Department of Conservation and Natural Resources (DCNR).  This relationship does involve a financial arrangement.  DCNR acquires aerial photography for the Commonwealth and solicits funding assistance from various agencies.  PENNDOT is now participating in this program.  The orthophotography supports a statewide mapping effort that will increase the accuracy from 1-24,000 to 1-2400.  The funding arrangement is accomplished through an interagency Memorandum of Understanding (MOU).

Management Leadership and Support

Management within PENNDOT has been very supportive of interagency data partnerships, with participation in several organizations serving to promote interagency efforts.  Examples include the Planning Partners' GIS Work Group, the PA GeoSpatial Information Council, and the PAMap I-Team.

However, management and leadership support at the Commonwealth level is   in its relative infancy.  Data and the systems that manage it are in Department stovepipes and although data sharing is easily accomplished, turf issues remain largely unresolved.  The Commonwealth today struggles with creation of data and systems management mechanisms to deal with homeland security and emergency preparedness.

Within PENNDOT, GIS and data sharing projects are brought to the Department's leadership through a business planning process.  The GIS service targets all areas of the Department through the budgeting process.  It is important for all modes and functions to benefit from the technology.

Partnerships are tied to strategic objectives identified by PENNDOT leadership, and funding requirements are made part of the base budgets to the extent possible.

Florida Department of Transportation
James Golden, Florida Department of Transportation

James Golden presented a summary of Florida DOT's Transportation Information Development and Distribution Plan.

The development and distribution of transportation information is one of the most critical issues the DOT and Transportation Statistics faces in the near future.  In a political climate of financial and budgetary shortfalls created by a sluggish economy and global economic uncertainty, both government and private industry share the constant burden and expectation of being able to do more with less.  All government sectors are faced with downsizing, outsourcing and reorganizing to meet the rapidly changing demands for increased customer service and cost-efficiency.  However, opportunities are created from difficult times and decisions.  It is important for TranStat be proactive in responding to these issues.  This response should be aggressive in formulating an innovative, cost-effective, customer-driven plan that manages, maintains and distributes its technical resources to an expanded customer base.  These resources should be distributed as information and not just as data.  The development and implementation of a responsive plan and strategy for transportation information development and distribution is fundamental in focusing the future direction, organization and energy of TranStat.

The formulation of the Transportation Information Development and Distribution Plan (Business Plan) is comprised of two basic steps.  The first step is the implementation of an improvement phase.  Once the improvement phase is finalized, the second step includes initiation of the enhancement phase.

Improvement Phase Actions

The first action step in the development of the improvement plan is the formation of a TranStat Steering Committee.  This committee, composed of key TranStat and FDOT managers and users from both within and outside FDOT, will be charged with several tasks designed to improve the overall quality and delivery of transportation information.

The first task of the Steering Committee will be to identify transportation information customers inside and outside FDOT and to develop key customer focus groups. Potential focus groups include Department of Transportation data users (Central Office groups and the Districts); other governmental users (Emergency Management, DCA, MPOs, County and City governments); the tourism industry (major attractions); the economic development and business communities; and modal groups (representatives from the seaport, airport and freight movement industries).

Once constituted, the TranStat Steering Committee, with the involvement and input of the customer focus groups, will review existing TranStat information products and formats.  From this review, suggested methods for improving the products, making them more accessible and relevant to customer needs, will evolve.  New TranStat information products, supported by existing data, will also be developed in response to the needs expressed by customer focus groups.

Concurrently with the development of new TranStat information products derived from existing data, the TranStat Steering Committee will proceed with a review of all TranStat and related databases. A major focus of this task will be avenues to increase communication and coordination between the Districts and Central Office, the identification of national, statewide and regional transportation data needs, data owners, collection and analysis procedures, reporting requirements, user accessibility, user application and value of the data to the customer.  This effort provides a fresh look at all TranStat and related databases to determine their adequacy, quality and cost-effectiveness.  Data sources will also be analyzed to determine if similar data could be compiled, or if higher quality data could be made available from other sources to save time and money. 

Ensuring Department-wide consistency for the collection, analysis and reporting of data regarding the extent and usage of the Florida Transportation System is imperative.  FDOT is faced with the loss of many key staff in this area and the development of a plan that has universal buy-in is extremely important.  The development of this TranStat data improvement program will provide the foundation for a TranStat Business Plan. 

As the Districts increasingly outsource data collection, analysis and reporting, the future role of TranStat will change.  This role will place a greater emphasis on data management, quality control, staff training, establishing standards, disseminating FDOT resource data and developing and distributing cogent transportation information products.  

Enhancement Phase Actions

Once the improvement phase is completed, the expanded search for TranStat information product customers and strategic partners will extend beyond the limits of the FDOT, and beyond government.  There is a documented need for transportation information and applications in many diverse governmental agencies, as well as the private sector.  The transportation system is critical to the State of Florida and its citizens, from local government infrastructure planning and resource management, to tourism, to emergency services, to the movement of people and goods.  Accurate, timely system information can be a vital business asset to our customers who are the residents, businesses and visitors to Florida.  There is a market for transportation information reporting on the existing system and its operation and use.  Many organizations, both public and private, could benefit by broader accessibility to TranStat information products.  Conversely, the Department may benefit from cross platform sharing and access to valuable resource data from other groups and agencies.  By serving this market in a focused manner, the role of TranStat can be positively redefined.  Acting as a broker for FDOT data, TranStat can leverage its data and information assets to obtain access to other data and information resources.

To insure that the Business Plan is customer focused, a select volunteer core group composed of key transportation leaders from the State in the areas of general business, tourism, freight and goods movement, government and the modal areas (air, water, rail, trucking, passenger, and bicycle and pedestrian) will serve as a sounding board during the enhancement phase.  This select volunteer core group will initially be charged with assisting TranStat in the development of a plan defining customer needs and benefits for a broader dissemination and sharing of transportation data and information.  Once the enhancement plan has a solid foundation, support organizations, such as the American Automobile Association, Florida Trucking Association, Florida Chamber, Metropolitan Planning Organizations, and Emergency Management Organizations, that have direct business and customer needs for good information on the utilization, condition and performance of the transportation system will be surveyed to broaden the potential customer base and improve the enhancement program.

An intense 4-5 month effort to develop new and imaginative ways to improve the collection and utilization of transportation data and provide transportation information to an expanded customer base will be needed.  As the various ideas and concepts emerge from the review process, customer focus groups and volunteer core group, TranStat will be working to ensure the goals of the plan are met in a user-friendly, efficient and cost-effective manner. The principal goal of the Business Plan is to enhance FDOT's access to improved transportation data and result in providing the information needed to advance the cost-effective implementation of Florida's transportation program. The successful delivery of expanded transportation information to the customer is the best measure of success for the plan.

The final challenge is the access and distribution of this information to an expanded customer base.  TranStat will build upon the success that has begun with the dissemination of its Traffic CD, video logging and website development.  These efforts have grown and are well supported by many customers.  This process will be improved and expanded to other relevant transportation information. 

Kentucky Transportation Cabinet
Rob Bostrom, Kentucky Transportation Cabinet

Rob Bostrom presented his observations on data partnering in Kentucky. 

Partnering is a crucial part of the Kentucky Transportation Cabinet's (KYTC) daily business paradigm.  For instance, an annual partnering conference is held by the design function of KYTC that attracted over 600 people in 2002.  Partnerships have also proven to be useful in the planning arena.  This paper will highlight one planning data partnership in detail and give glimpses into two other data partnerships that have been successful.

The planning data partnership that we will spend the most time on is the ARTIMIS (The Advanced Regional Traffic Interactive Management & Information System) intergovernmental agency data partnership, which primarily involves the states of Kentucky and Ohio, the FHWA, an MPO and a private sector firm. ARTIMIS is an advanced traffic management system in greater Cincinnati.  It covers 88 miles of highway in Ohio and Kentucky.  It is the first major ITS effort in Ohio and the second in Kentucky.  There are 80 cameras, 57 miles of fiber, 1,100 detectors, 40 fixed CMSs, 2 HARs, 5 patrol vans and a traffic control center in downtown Cincinnati.  More information about ARTIMIS can be found at: http://www.artimis.org/index.php.  ARTIMIS is best known as the first ITS system to implement 511 Traveler Information Hotline.

This paper will use the ARTIMIS data partnership to look at the following partnering issues identified by the Peer Exchange Steering Committee.

  • Cultural and Institutional Barriers;
  • Partner roles and responsibilities;
  • Data definition and standards;
  • Technology, equipment and connectivity;
  • Archiving and managing large data sets; and
  • Resource, funding and cost sharing.
Cultural and Institutional Barriers

Cultural

The Kentucky Transportation Cabinet is a mission-oriented organization with a positive and diverse culture (see web page:  http://www.kytc.state.ky.us ).  It is very difficult to identify the "culture" of such a complex and large governmental organization.  Nevertheless, it is not a stretch to state that KYTC's highest priority is getting highway projects to letting and then getting them completed on time.  In this emphasis on design and construction, planning data might seem somewhat out of place.  In practice, the contrary is true.  Efforts to collect planning data including traffic counts, GIS mapping, traffic modeling, air quality analysis, GPSing and other traditional planning efforts are prospering.

So planning data is not a cultural barrier.  The cultural barrier is the marriage between Planning and Operations necessary to obtain planning data from a system mostly run by Operations personnel.  It has taken several years (ARTIMIS started archiving data in 1999) for these two functional areas to achieve understanding of the needs and priorities in respect to intelligent transportation systems.  After several years of meetings and false starts, the Cabinet now has excellent cooperation of the personnel in Planning and Operations in respect to archiving data.

Institutional

The institutional framework for using data coming from ITS systems for was nonexistent when ARTIMIS began.  There are several stakeholders in data archiving for this system that are listed below along with some subunits in the organization involved and with their initial involvement/interest in the data archiving.

ARTIMIS Stakeholder Organizations

  

 

Organization

Subunits

Interest In Project

  

 

KYTC

Planning

Responsible for Traffic Volume Counts on State Roads in KY

Multimodal Programs

User of Volume, Class and Speed Data

  

Operations

Responsible for Operation of ARTIMIS

  

ODOT

Tech Services

Responsible for Traffic Volume Counts on State Roads in OH

District Office

Responsible for Operation of ARTIMIS

  

OKI (MPO)

Modeling

User of Volume, Class and Speed Data

  

Data

Compiler of Traffic Volume Counts on Cincinnati Roads

FHWA

Division Office

Source of Funds for ARTIMIS

  

National Office

Interested in Successful Archived Data Projects

Contractor

Project Manager for Daily Operation of ARTIMIS

Perceived strengths and weaknesses of these organizations follow:

KYTC and ODOT: 

Strength: States are the focal point of the transportation process and so they should have the ability to make things happen.

Weakness:  States historically haven't worked well with each other which isn't a good option in a project that is in two separate states.

FHWA:

Strengths:  Program oriented and source of funds.

Weakness:  Not real familiar with local issues.

OKI (MPO):

Strength:  Strong on local issues.

Weakness:  Weak on data management.

Contractor:

Strength:  Strong on mission and timeliness.

Weakness:  Weak on big picture.

Partner Roles and Responsibilities

In order to overcome the disparate goals/strengths/weaknesses of the organizations involved, a new partnership had to be forged.  The leaders of this partnership were the Ohio DOT (Tech Services), the Kentucky Transportation Cabinet (Multimodal Programs and Planning) and the consultant.   Relationships were formed at initial meetings and strengthened via conferences, phone calls, and emails.  In time the following roles emerged (it must be mentioned that as in all partnerships, the roles are very evolutionary and will change significantly over time):

  • FHWA: mission, encouragement, and money
  • OKI: initial guiding light
  • Contractor: daily management
  • Ohio: project manager of ARTIMIS, collaborate on archiving decisions, data analysis lead.
  • Kentucky: initial project manager, collaborate on archiving decisions, research study.
Data Definitions and Standards

From the outset of the project, both KY and OH felt like the ARTIMIS project should serve as a template for future ITS data archiving in their two states.  Initially the data definitions used were borrowed from the FHWA's Traffic Monitoring Guide.  Data was put in the CARD 3 (traffic volume) and CARD C (vehicle classification) formats by the contractor (TRW now Northrop Grummond).  Additional data formats used by TRW were used for raw data formats.  The TMG formats were chosen since it was deemed to be useful to be consistent with FHWA standards and the TMG standards were the only traffic data standards available.

As the archived data partnership evolved, it became clear that the TMG standards didn't provide adequate detail or flexibility needed by customers of the data.  Thus ODOT and KYTC developed new data standards as following:

Card V: 5-minute volume data patterned upon the TMG Card 3;

Card S: speed data in 15 five mph bins; and

Card L: Vehicle length in 15 bins, to be used to develop length-based vehicle classification data.

It is expected that standardized software can be written using these new data formats that will produce easy to use statistics and performance measures from ARTIMIS and from other ITS systems in the future in Kentucky and Ohio. 

The ARTIMIS data archiving partners think that it would be useful to FHWA to use these new data formats (or something similar) to allow the development of standardized ITS data analysis software.  Of course, use of these new data formats doesn't preclude the use of other formats. 

Technology, Equipment and Connectivity

The technology and equipment initially used in ARTIMIS had an emphasis on off-the-shelf usability.  Loops were the main sensor along with radar detectors and video.  Loops were chosen based on a University of Cincinnati study on sensor accuracy.  However, problems in installing loops delayed the deployment of ARTIMIS by one year.  The traffic recorders used were 170 controllers.

TRW (the project contractor) was the only entity with direct connection to the raw data.  Initial data archiving amounted to data logging only with all data files being kept and put on an ftp site with annual data CDs being provided to key partners.  TRW also maintained a web site that gave information on delays/incidents.  Of note is the development of the 511 Traveler Information Hotline that was developed by ARTIMIS and has since been used by other ITS organizations.

As the data archiving partnership evolved, questions arose about the suitability of the 170 controllers for collecting vehicle classification data.  The 170 controllers were chosen due to their common usage in with traffic signals and their capability to gather occupancy data (which is the most important data needed for advanced traffic management systems).    However these data recorders are not designed for planning purposes and thus consideration was given to using a commercial traffic recorder used for traffic counting. 

A commercial traffic recorder has several advantages over the 170 controller:

Designed to collect volume and vehicle classification data needed by planners;

More RAM memory and overall technology is more up to date than 170s;

Capable of being remotely accessed (polled) with interrupting data collection;  and

Pre-designed traffic reports and data processing is available.

The one drawback to commercial traffic recorders is that they don't collect 30-second occupancy data.  Peek Traffic - due to having an ongoing contract with KYTC - was asked to modify their ADR 3000 traffic recorder firmware to allow the collection of the occupancy data which they have done.  After a period of testing, it is expected that the commercial traffic recorders will be installed in many freeway sections, thus providing planning forces the ability to provide better quality control for the ITS data.

Archiving and Managing Large Data Sets

ITS systems produce large amounts of data.  For instance the 82 Kentucky sites in ARTIMIS (which is only 20% of the overall system) produce about 3,000,000 15-minute volume records annually and this is not the only type of data available.  ARTIMIS logs all of this data on CDs and also makes it available via a ftp site: ftp://208.237.57.131. 

The data processing for this data initially has been rather ad hoc.  The data is not of ATR (automatic traffic recorder) quality but does have ATR quantity.  Another data processing problem (other than sheer size) is the lack of clear responsibility for the data.  ITS systems are the responsibility of operations staff but the data can be used by planning forces.  Another data processing problem is how to choose an appropriate sample size.  Should you use 48 hours or 365 days or something else?

ARTIMIS was selected as a Mobility Monitoring System site by FHWA in 2000 (http://mobility.tamu.edu/mmp/).  This program - which is using ITS data to develop a

framework for mobility and reliability analyses - served as a jumpstart for processing the ARTIMIS data.  Not only did FHWA's consultant (Cambridge Systematics) provide some quality review for the data, they showed that many of the average daily traffic volumes were consistent with historical planning traffic volumes.  This provided the impetus to pursue even better data processing procedures.

An Archived Data Management System (ADMS) research study by the Kentucky Transportation Center of the University of Kentucky has been initiated.  The advantages of using a university to process ITS are two-fold.  First, they are an outside entity (as discussed earlier, archived data doesn't neatly fit in either operations or planning) and secondly, they can find uses for the data beyond the needs of operations and planning.  The goals of the ADMS research are:

      To analyze volume, speed and length-based classification data;

      To establish quality standards (started with Texas Transportation Institute's standards);

      To provide feedback to operations;

      To create a spatial database (a GIS system); and

      To create a permanent ADMS in Kentucky.

This research study funded by KYTC and will focus on ARTIMIS data and also data from TRIMARC (a Louisville-based ITS system, see: http://www.louisvilletraffic.com/cgi-bin/home.cgi ).  The study will last 2 and one-half years and cost $190,000.  Ohio DOT and FHWA have people on the study advisory committee to help ensure that the study stays in the mainstream of current ITS data archiving.

Resources, Funding and Cost Sharing

ARTIMIS system costs have been borne by ODOT, KYTC and FHWA (using CMAQ funds).  The data archiving costs have been by the same entities with the addition of:

  • Mobility Monitoring funds.  $25,000 was given to KYTC for both the ARTIMIS and TRIMARC projects.  This served to jumpstart the research study and initial data processing although it is clearly not enough to anything substantial.
  • Research funds.  The ADMS study will tap traditional research funds that are available from the FHWA and KYTC.

It is clear that archived data will require innovative financing to continue.  It is hoped that the data will be of sufficient quality for use for planning purposes.  If that is the case, then money used for traffic monitoring can be diverted to the ADMS.

OTHER DATA PARTNERSHIPS IN KENTUCKY

Air Quality Conformity

Kentucky has many areas that have ozone nonattainment status.  The data needed (speed and vehicle miles traveled) for the EPA mobile source emissions model, MOBILE6, required coordination between many KYTC divisions and outside agencies.  Two key features of the successful partnerships that have emerged here are:

  • Monthly meetings and regular email updates; and
  • he data collection has led to two special research studies (on VMT and average speed estimation).

More information can be found at:  http://www.kytc.state.ky.us/Multimodal/air_quality.htm .

Traffic Model Users Group

Traffic Demand Models are another area where the jurisdictional boundaries and number of users don't always fit in one neat organization.  The Kentucky Traffic Model Users Group was started to provide a vehicle to choose new modeling software.  This partnership has two key features:

  • The user community involves MPOs, multiple states, consultants, vendors and academics.
  • ince models are used for many key decisions, the MUG is used to facilitate training and to improve the state-of-the-art of the regional modeling practice.

More information on the MUG can be found at:  http://www.kytc.state.ky.us/multimodal/kytraffic_mug.htm .

Conclusion

As can be seen, data partnerships are a critical part of KYTC's way of doing business.  Some lessons learned are:

  • Partnerships take extra effort but the payoff is large.
  • The DOT's normal organization structure is not as important in partnerships.  The importance of people in partnerships is not their position but what they can do.
  • Partnerships may exist for only a short time in response to a current need.
  • People are the important thing!  In order to overcome organizational barriers, good communication and trust must be cultivated.
Colorado Department of Transportation
Tim Baker, Colorado Department of Transportation

Tim Baker presented an evaluation of methods, used by the Colorado DOT, for updating geometric data for the state highway system.

The Colorado Department of Transportation (CDOT) has recently taken significant strides in updating and improving the quality of the State Highway Database (IRIS).  An area that has been identified as needing significant work is in the data stored in the Geometric Data File.  Stored within this file are most of the geometric data attributes that are used by the Department, local agencies and the public for analysis.

In an effort to better understand the need and scope of the data quality and methods to update the file, the Department hired a consultant in 1999 to conduct a preliminary check of IRIS geometric data.  The results indicated that updating of the inventory was needed in at least the urban areas.   In addition, the Department has been involved in the development of performance measures and a new Statewide Transportation Plan for 2030.  As part of this process we are taking a closer look at need, partnering in collection resources, and type of data update needed for the IRIS geometric data table.

The following is a summary of the evaluation conducted by CDOT's Consultant, Carter & Burgess and the Colorado Department of Transportation regarding updating the geometric data.

IRIS Database

The IRIS database was developed in the late 80's.  It is a relational database that is comprised of a number of active tables, which include geometric, classification, HPMS, Traffic, Off-System and many other files.  It is maintained by the Division of Transportation Development and relies on various partners within CDOT to update the data.  This issue has resulted in a problem with consistent data quality.  Other factors that have also affected quality include: reduced field staff, inconsistent reporting of new road and construction changes, staff retirements, and standardized methods of data collection.

Users and Needs

The IRIS database is used by the Colorado Department of Transportation, Federal, local agencies and the public in general.  A consistent question from the users is what is the level of granularity of the data.  As expected, the customer needs vary from very detailed to aggregate summary data.  Depending on the IRIS file, there can be as many as 29,000 records for attributes in the State Highway tables or as few as a couple of thousand.  This has a direct impact on the granularity of the data.  It has been an issue in determining the needs of our data partners.   Some of the issues include: defining user needs, data update issue, format, common data collection methods, cost sharing and common data formats.

Geometric Evaluation Project

In order to address these issues the CDOT conducted a project with the goal to evaluate various methods of geometric data collection, in order to look at options for geometric data updates.  Four methods were chosen for evaluation: Video Observation, Field Observation (direct measurement), Windshield Surveys and Aerial Photography. 

For the study, four State Highway Segments were chosen as representative of Urban Interstate, Urban Arterial, Rural Arterial, and Rural Minor Arterial.  In addition, we looked for areas that had new construction and unimproved geometrics.   

The study was conducted over a two-month period in the spring of 03.  As project budget was an issue, we did not evaluate the video observation option.  It was felt that in-house staff could reasonably ascertain this.  The overall study went well, with the contractor reporting findings in April 03.

Findings

Some of the more significant findings of the study:

  1. Need for better attribute definition and coding criterion.
  2. Clear understanding for the need to create a new geometric record.
  3. Historical information of the segment would be helpful to collector
  4. How to deal with missing data.
  5. To develop procedures on uniform collection and staff training
  6. Additional geometric fields should be included like auxiliary lanes.
  7. Clear understanding of granularity and needs of data partners

In addition, the contractor evaluated the costs related to these methods of update.  It was found that the costs for updating the inventory ranged from $40 per mile for the probe vehicle, to over $2000 for some forms of aerial photography.    Overall it would cost the CDOT: 1.6 million for field observation, 18 million for aerial photography and about four hundred thousand dollars for probe vehicles.  These costs are general in nature and could be more or less depending on granularity issues. 

The results of these collection costs have caused us to consider the options for funding the geometric data update.  Some of the options that could be considered include:  using the departmental budget, a special one time request from the CDOT Commission, shared cost from data partners within CDOT, user fees, charges for special data collection to group requesting collection. 

Next Steps

Based on the results of the study, CDOT is in the process of preparing a contract to move forward with improving geometrics.  The plan is to:

  1. Survey partner levels of need.
  2. Determine level that CDOT is willing to support.
  3. Evaluate the effect on the database.
  4. Develop a data collection procedural manual
  5. Explore cost sharing alternatives
  6. Test new procedures on State Highways
  7. Develop a long-term data maintenance plan to leverage partnerships with other data users.

Illinois Department of Transportation


James P. Hall , University of Illinois at Springfield

James Hall of the University of Illinois at Springfield presented an example of an intergovernmental data program at the Illinois Department of Transportation (IDOT).  His prior background included 25 years experience with IDOT including management of the roadway inventory databases for the Office of Planning and Programming.  His views do not represent the official views of the IDOT.

Rail/Highway Crossing Databases

The integration of the rail/highway grade crossing information databases for the Illinois Department of Transportation (IDOT) and the Illinois Commerce Commission (ICC) provides a good example of a functioning intergovernmental data program.  Both the ICC and the IDOT historically operated separate rail/highway grade crossing databases.  In addition, IDOT typically reported inventory data changes to the Federal Railroad Administration (FRA).  For many reasons, over time, the data contained in these three databases were significantly different, even as to the identification of open crossings.

In 1998 a comprehensive effort was undertaken to update and integrate these files. Activities included an on-site survey of each crossing to verify data and to collect new data.  In addition, six on-ground photographs were taken at each crossing from different perspectives.  Aerial photographs were also acquired for each crossing.

The ICC and IDOT still had a need to operate separate rail crossing databases.  However, data is now updated on a first to know basis for any changes in crossing information.  There is nightly file compare and integration of data from each database with a report to each agency of any changes.  As a result, both the ICC and IDOT rail crossing databases now contain the same data at the start of each day. 

Significant benefits have resulted in the ready availability of more accurate data for program development activities such as the identification of dangerous crossings.  Individual crossing information, including photos, are now available on IDOT's Intranet. 

Alaska Department of Transportation and Public Facilities
Jack Stickel, Alaska Department of Transportation and Public Facilities

Jack Stickel presented the Alaska Department of Transportation and Public Facilities' (ADOT&PF's) data integration partnership for an asset management system.  ADOT&PF's Maintenance and Operations Division is deploying an asset management system, the Maintenance Management System (MMS).  Statewide Planning is developing an interface that will link the Department's transportation database and the MMS.

Maintenance Management System

The MMS will focus on the traditional maintenance activities of planning, budgeting, and resource management for a statewide multi-modal transportation system.  Additional capabilities include maintenance needs and quality assurance assessments.  A pilot project MMS will be deployed in spring 2004 with a full statewide deployment in late 2004.  The pilot project inventory will be limited in both the number of asset types and maintenance station areas.  The Division of Maintenance and Operations (M&O), in association with Booz.Allen and Hamilton, is leading the MMS development.

The MMS will link with seven of the State of Alaska's legacy databases, including ADOT&PF's transportation database, the Highway Analysis System.  The MMS will also integrate with other existing information systems managed by Statewide Planning: Road Weather (RWIS), Alaska Traveler (ATIS), and Geographic Information Systems (GIS).

The Highway Analysis System (HAS) will be the primary data archive for the MMS data.  The HAS contains road network data, highway features, and transportation data such as traffic counts, vehicle crashes, and pavement condition.  Statewide Planning and M&O jointly established the data definitions and standards for the data fields that will support the MMS.  The HAS and MMS will link with a data element key.  The HAS - MMS interface will provide asset inventory locations in both linear (route/milepoint) and coordinate-based reference systems.

Statewide Planning is collecting the MMS pilot project asset inventory and providing an MMS data archive.  The HAS asset inventory and road network data will be exported to an Oracle relational database to support MMS reporting.  Statewide Planning will develop HAS online query capability and customized asset reports to support the MMS.  Statewide Planning is developing a comprehensive Geographic Information System (GIS) that will fully integrated with the MMS when fully deployed in 3 - 5 years.  Also proposed is a real-time HAS linkage that will allow M&O personnel to update asset information through a GIS interface.

A number of challenges surfaced during the first year of the interface development.  The top three challenges were: establishing robust data definitions, developing capability to handle multiple location reference systems, and getting a strong management commitment to support MMS development costs.  This support includes both work authorization and funding for full-scale MMS deployment (field data collection, data storage, hardware/software upgrades, and the GIS).

Significant Issues

The MMS working group consists of M&O directors and supervisors, the MMS contractor, and Statewide Planning staff.  Statewide Planning participants included the GIS Mapping, database, and transportation planner staff as required.  Participants' background and interest in the MMS project presented challenges and opportunities for data definitions, standards, and integration. 

  • ADOT&PF M&O Project Manager - needs a solid background in inventory procedures and database principals.
  • MMS Contractor - needs flexibility to tailor a system to the state's specific requirements.
  • Maintenance Directors - need to appreciate the long-term, total cost of data collection and data archive.
  • Maintenance Supervisors - need to be open to new ways of tracking asset location (wants location by route/milepost, not the route/milepoint of the Highway Analysis System transportation database).
  • Database Group - need to be included early in the system development for anticipated changes in the database and in data processing. 
  • Transportation Planners - need to be prepared for the total cost (time, money) for data collection, data archive, and database changes.
  • GIS-Mapping Staff - need to be included early in the system development for efficient and technically correct data collection and processing.
Data Definitions and Standards Issues

Four key issues impacted the data definition and standard development for the MMS inventory items:

  • Working group knowledge about the other participant's specialty area
    • Planning had to learn about M&O procedures.
    • M&O had to learn about the Highway Analysis System transportation database and data collection procedures.
  • Deficiencies and inconsistencies between the legacy databases, including:
    • M&O Station Files out of date
    • Accounting System Codes inconsistent between legacy databases
    • Bridge information in other systems did not agree with PONTIS bridge management system.
  • Planning and M&O started out with different perceptions on the type of system to be developed:
    • M&O wanted a stand-alone MMS system with no real-time data linkage to other systems.
    • Planning wanted to avoid costly (time and funding) changes to the Department's legacy database, the Highway Analysis System.
  • Planning and M&O had considerable discussions on the data collection standards, especially the desired data fields and what could realistically be done within personnel, time, and funding limitations.  GIS-Mapping helped focus on three areas:
    • Location Accuracy - required versus what is achievable 
    • Safe and reliable measurements of asset attributes.
    • Equipment capabilities.  The MMS was a strong selling point in ADOT&PF's purchase of NAVSTAR Mapping Corporation's RoadMapper III Log/Mile Data Collection System.  RoadMapper III collects single point, segment, and road network a combination of Global Positioning System (GPS) spatial coordinates and log mile linear reference locations and attributes
Data Integration Issues

Four key issues impacted data integration for the MMS pilot project and full scale deployment:

  • Multiple Data Collection Projects: Statewide Planning will integrate the new MMS requirements into the existing highway inventory project.  This task will be simplified with the new Navstar Mapping Corporation's Roadmapper III LogMile Data Collection System.  Statewide Planning will pursue integrating other agencies' data collection projects such as the Alaska Department of Fish & Game's culvert inventory. 
  • Multiple Reference Systems:
    • Planning uses route/milepoint.
    • M&O use route/milepost.  Alaska's highways are missing mileposts and not all state routes have mileposts.  Additionally, the interval between the historic mileposts is almost never a mile.
  • GIS Development:
    • Unify the processing, managing, and output of road features and centerline network into a single integrated system
    • Full capability in 3 to 5 years
  • Management Commitment
    • Field data collection equipment procurement
    • Data collection contracting
    • Data processing & storage hardware/software procurement      
    • GIS development (funding and personnel resources)
Value of Data Partnerships

ADOT&PF hopes to leverage the Maintenance Management System data collection, archive, and access to benefit other Statewide Planning work and the data interests of other agencies.

  • Leveraged Planning Functions: 
    • Alaska Traveler Information System (CARS/511)
    • Vehicle Crash Reporting
    • Highway Inventory
    • Legislative Support
    • Federal Reporting
    • GIS Development
    • State Transportation Improvement Program (STIP)
    • Highway Safety Improvement Program (HSIP)
  • Leveraged Agency Benefits:
    • DOT - Maintenance and Operations

    • DOT - Statewide Planning

    • DOT - Engineering and Operations Standards

    • Alaska Department of Fish and Game

    • Alaska Department of Natural Resources

    • Alaska Department of Environmental Conservation

    • Alaska Department of Veterans and Military Affairs

    • Alaska Railroad

    • US Department of Agriculture

    • US Geodetic Survey

        

Texas Department of Transportation
Kim Hajek, Texas Department of Transportation

Kim Hajek presented Texas DOT's experience with Data Partnerships between Management Information Systems.

The focus of this presentation is on certain key challenges which many state DOTs face when developing or integrating data partnerships between Transportation Management Information Systems.

There are multiple layers of system interfaces and business processes to consider when developing these data partnerships. 

There are interfaces between:

  • Federal, state, and local transportation information systems
  • Existing Legacy Systems and Newly Developed Systems
  • Multi-Modal Systems including several types of transportation  

Whether the goal is to develop these partnerships within or among any of the 

categories listed above, consideration should be given to the complexity surrounding integration of data and determining the level of data accuracy required to be useful, without being cost prohibitive.  

This presentation will focus on the two key issues or challenges of how to deal with (1) Data Integration and (2) Different Spatial Data Accuracies and offers some "prototype solutions" based on Texas DOT information systems.

The first issue, Data Integration, requires an understanding and a determination of Data definition, Data file structures and Data Conversion requirements.

Consider, for instance, the definitions of pavement width vs. surface width when examining the physical characteristics of a segment of roadway.  While it might appear to some that these two terms are equivalent and interchangeable, this does not necessarily translate into the same "data definition" when these terms are used as data elements.  One definition might require "shoulder width" included with "surface width" (of mainlanes) in order to determine "total pavement width".

Data also resides in many file structures, including "flat files", Mainframe databases, PC databases, Relational databases, etc.

Data Conversion when migrating data from one system to another must take into account changes in units of measurement (i.e. metric to English, data code values, etc.) .  A misunderstanding of data conversion requirements can result in catastrophic depending on the intended use of the data and information system.   

When designing data conversion applications, especially for transportation systems, it is reasonable to assume that a common data "file key" will need to be established and a likely candidate for this "file key" is a location data field.

Consider for a moment, multiple location referencing schema which includes a control-section milepoint (c-s-mpt) location, mile-marker or reference-marker location, or a latitude/longitude/elevation coordinate location.th multiple location references, the file key must be converted through a translator.

Consider the use of something similar to the Milepoint-Reference-Marker-Equivalency file developed at the Transportation Planning and Programming Division of TxDOT.

By merging the c-s-mpt location with the ref-marker location, any system which is developed using one of these file keys can "talk to" or share data between systems by developing software which uses such an equivalency file to extract data.

In the case where the reference marker system is also a physical marker on the road, this location system can then be matched to a latitude, longitude, elevation location on the earth.

Once data conversion programs are written or better yet, a data key, is developed using all three methods of location, the access to legacy system and new system data becomes very efficient and the multiple information system interfaces are transparent to the user.

In integrating data for management information systems consideration must also be given to the appropriate hardware/software architecture to be designed for the integration.  Many State DOTs currently have a mixture of mainframe, PC, client-server databases and interfaces.  It is a technological challenge to design an efficient system which integrates all of these types of architecture.  It is not impossible to do and many states already have or are starting to meet this challenge.

One of the ways in which our state is addressing this issue, is through the use of Geographic Information Systems (GIS) which are built upon a relational database architecture.  The abundance of available GIS tools is making the job of state DOTs easier in designing new systems, which must integrate or convert legacy data for use with the new system.  Establishing the "data warehouse" or central repository of data which is extracted from legacy data bases and is loaded into a relational database makes the job a lot easier for building new applications. 

The second issue to be discussed in this presentation concerns the use of "GIS data" or "spatial data" with different data accuracies and resolutions of data layers.

All GIS data sets should require a minimum level of accuracy and a minimum scale for data collection/creation.  The value in determining the "minimum" acceptable level is that this will limit the amount of manual data correction required when integrating data from external sources into the geo-database.

If a minimum accuracy tolerance of +/- 25 ft. is required for data in a management information system and a minimum scale of 1:24,000, is established for data collection, then data overlays with a smaller than minimum scale, such as the 1:100,000 data would require extensive manual correction for use.  Data at a scale of 1:12,000 would be okay to use because the overlay points should still fall within acceptable accuracy limits.  Determining the minimum acceptable accuracy tolerance and resolution is key in integrating spatial data sets and limiting the amount of manual work required to "correct" the data to within the desired accuracy tolerance.

The data requirements and level of accuracy and tolerances are variable, depending upon the use of the management information system.  Some applications, such as state road inventory systems may require a centerline based system and an accuracy tolerance of +/- 30 ft. to satisfy the majority of its federal reporting requirements, such as for the Highway Performance Monitoring System.

Other Management information systems may require a roadbed based "centerline" network with lower minimum level of accuracy such as:

  • Pavement Management (+/- 10 ft.)
  • Bridge Management (+/- 5 ft.)
  • Safety Management (Crash Records location) (+/- 20 ft.)
  • Oversize, Overweight Permit Routing (+/- 30 ft.)
  • Hazardous Material Routing (+/- 30 ft.)
  • E911 Routing (+/- 30 ft.)

In some cases, information systems must use a lane level "centerline" network for location purposes.  In these instances, the lane level would be the base layer on which the other layers would be built.  Once the acceptable tolerance level is defined, the data collection and integration requirements can be established.

In summary, even though the challenges are great in integrating data and establishing partnerships between management information systems, the challenges are not "impossible" if much consideration is given in the design and analysis phases to:

  • Data Conversion requirements between systems (data definitions, file definitions)
  • Integration of New and Old Technology (mainframe, client-server)
  • Establishment of Minimum level of accuracy needed (GIS applications).

 Peer Exchange Summary

The complex and information intensive nature of transportation planning decisions require increasing access to relevant, accurate and timely data.  Often, this data necessitates partnering with internal and external entities for data collection, integration and transmittal.

Unfortunately, there are often significant organizational issues to overcome when undertaking a data partnering project, especially when there are external data partners such as local agencies and other state and federal agencies.  On the plus side, technology is providing more powerful data integration tools and methods.

KEY ASPECTS TO DATA PARTNERSHIPS

During the presentations, participants reiterated the following key aspects to successful data partnerships:

  • Overcoming cultural and institutional barriers
  • Clarifying roles and responsibilities of partners
  • Agreeing on data standards, and managing potentially conflicting data definitions and currencies
  • Resolving equipment and connectivity issues and taking advantage of enabling technologies (Internet)
  • Integrating data from different data sets 
  • Utilizing data with varying spatial accuracies and resolutions
  • Archiving and managing large data sets
  • Securing resources and funding and sharing partnership costs
  • Quantifying and qualifying the value, utility and benefit of data partnering investments
  • Addressing privacy and security concerns
  • Obtaining management leadership and support
LESSONS LEARNED

After each state presentation, the speaker summarized his/her most important "lessons learned" on successful data partnerships (see below). 

  • "There are sophisticated local partners; go and see them!  Sell the benefits of integration." (Minnesota);
  • "Don't go directly to the solution.  Identify problems and achieve joint ownership of the problem and the solution." (Michigan);
  • "Talk to them like customers.  Everybody wants something.  Find this out and barriers can come down quickly." (Pennsylvania);
  • "Use technology to make it happen.  Take advantage of available resources.  Need for a Top-down, Department-wide business plan to foster relationships and trust." (Florida);
  • "People are great.  The organizational structure goes out the window.  If you wait for the organization, it won't get done quickly." (Kentucky);
  • "If you don't make the commitment to update, the costs will be huge.  Determine who wants to help and pay versus who wants to use the data." (Colorado);
  • "Keep an eye on advancing technologies.  Communication with external agencies is critical." (Illinois);
  • "Educate, educate, educate." (Alaska); and
  • "Talk to other systems integration people at the same level." (Texas).
DATA PARTNERSHIP STRATEGIES

Through the Peer Exchange, the following emerged as effective strategies for the implementation of data partnerships. States with specific examples are referenced in parentheses.

Starting Up Data Partnerships for Data Integration

  • Identify potential data partners by determining interested users (e.g., several groups should be interested in pavement data).  Also identify who currently controls the data;
  • Look for windows of opportunity, timing is key (Florida);
  • Need leadership backing and/or a champion (Texas);
  • Articulate clearly the benefits of the data partnering investments, in specific numbers if possible (Minnesota); and 
  • Face potential problems up front; don't solely focus on the final result/benefits.

Outline Common Benefits of Data Partnerships

  • Saves money - elimination of redundant data entry;
  • Emphasizes accurate and timely data with availability to a larger number of users;
  • Prevents data entry repetition (a significant benefit when several agencies previously hand entered the same data);
  • Provides consistency in data reports (elimination of conflicting answers);
  • Assists in standardizing procedures (e.g., clarify data definitions);
  • Improves quality of public information (e.g., data that identifies a particular intersection as dangerous can help explain the need for a project); and
  • Leads to better data and better planning/programming decisions.

Getting it done: Data Integration

  • Focus on marketing the benefits to potential partners and management;
  • Identify who is specifically responsible for data integration activities;
  • Plan the data integration activities. Planning enables the linkage of data integration to larger objectives/goals;
  • Coordinate with the planning office since the planning area is often better positioned to identify key focus areas for data integration and partnerships.  Planners also interact regularly with stakeholders so they are better situated to communicate the benefits of data integration;
  • Ensure close coordination with the Information Systems office to help address software, hardware, and communications issues;
  • Form partnerships with universities when feasible;
  • Focus on data integration and access, not changing data ownership; 
  • Identify specific quantifiable benefits since funding and personnel resource allocations are typically scarce;
  • Attempt to spread the cost and activities of data integration projects across multiple partners;
  • Keep in mind the characteristics of the data partners, and work within their characteristics (e.g., state police typically operates under a command and control structure and will likely have different agency goals); and
  • Emphasize continually the benefit to all the partners but note the benefits will not apply to all partners equally.

Next Steps in Data Partnering

  • Quantify and qualify the value and utility of data partnership investments;
  • Investigate  how data partnerships can help meet the need for integrated data as a result of new transportation legislation;
  • Leverage benefits from successful data partnerships to create future partnerships;
  • Identify how the success of a data integration effort can provide evidence for data integration in another data area; and
  • Determine how the lessons learned from a data partnership success in one state can be effectively communicated to other states and agencies.
Participants
Tim Baker


Unit Manager
Colorado Department of Transportation
4201 East Arkansas Avenue
Denver, Colorado 80222
(303) 757-9757
tim.baker@dot.state.co.us


Niels Robert Bostrom
Transp Engrg Specialist
Kentucky Transportation Cabinet
125 Holmes Street
Frankfort, Kentucky   40622
502-564-7686   502-564-4422 (Fax)
rob.bostrom@mail.state.ky.us

Edward J Christopher
Metropolitan Specialist
Federal Highway Administration
Midwest Resource Center
19900 Governors Drive
Olympia Fields, Illinois   60461
708-283-3534   708-283-3501 (Fax)
edc@berwyned.com
 

James Golden

Manager, Transportation Statistics
Florida Department of Transportation
Transportation Statistics Office
605 Suwannee St MS 27
Tallahassee, Florida 32399-0450
 (850) 414-4736
james.golden@dot.state.fl.us

Judith Kim B Hajek
Director-Data Management
Texas Department of Transportation
Transpo Plng & Programming Div
P O Box 149217
Austin, Texas   78714-9217
512-486-5052   512-486-5099 (Fax)
khajek@dot.state.tx.us

James P. Hall
Assistant Professor
University of Illinois
One University Plaza CBM-115
Springfield, Illinois   62703
217-206-7860   217/206-7543 (Fax)
Jhall1@uis.edu

Patricia Hendren
6008 Onondaga Road
Bethesda, Maryland   20816

Patricia S Hu
Dir-Ctr for Transpo Analysis
Oak Ridge National Laboratory
P O Box 2008 Bldg 3156 MS-6073
Oak Ridge, Tennessee   37831-6073
865-574-5284   865-574-3851 (Fax)
hups@ornl.gov

Anthony R Kane
Director - Engineering & Technical ServicesAASHTO (American Association of State Highway and Traffic Officials)
444 North Capitol Street NW Suite 249
Washington, District of Columbia 20001
202-624-5812  202-624-5469 (Fax)
akane@aashto.org

Jonette Kreideweis
Director-Transpo Data & Analysis
Minnesota Department of Transportation
395 John Ireland Blvd MS-450
St Paul, Minnesota   55155
651-215-1854   651-296-3311 (Fax)
jonette.kreideweis@dot.state.mn.us

Thomas M. Palmerlee
Transportation Data Specialist
Transportation Research Board
Technical Activities (Div A)
500 Fifth Street NW
Washington, District of Columbia   20001
202-334-2907   202-334-2030 (Fax)
tpalmerlee@nas.edu

Roger G Petzold
Team Leader
Federal Highway Administration
Ofc of Intermodal & Statewide Programs
400 7th Street SW HEPS-20 Rm 3301
Washington, District of Columbia 20590
202-366-4074  202-493-2198 (Fax)
Email: roger.petzold@fhwa.dot.gov

Jack R Stickel
Mgr-Hwy Database Group/Statewide Plng
Alaska Department of Transportation & Public Facilities
3132 Channel Drive Suite 200
Juneau, Alaska   99801
907/465-6998   907/465-6984 (Fax)
jack_stickel@dot.state.ak.us

Thomas TenEyck
Director
Pennsylvania Department of Transportation
Bureau of Planning and Research
400 North Street
6th Floor East
Harrisburg, Pennsylvania   17120-0064
717-787-5796   717-783-9152 (Fax)
teneyck@dot.state.pa.us

Anita Vandervalk
Director - Florida Operations
Cambridge Systematics Inc
1820 East Park Ave
Suite 203
Tallahassee, Florida   32301
850-219-6388   850-219-6389 (Fax)
avandervalk@camsys.com

Ronald L Vibbert
Manager Asset Management Section
Michigan Department of Transportation
P O Box 30050
Lansing, Michigan   48909
517-373-9561   517-373-9255 (Fax)
vibbertr@michigan.gov


 Appendix A
 Issues and Challenges to Data Partnering Survey
TRB Statewide Data and Information Systems Committee (A1D09)

Peer Exchange - Data Partnerships - Making Connections for Effective Transportation Planning

May 21 8:00am - 5:00pm, Hawks Cay, Duck Key, Florida

Data Committee Survey

This peer exchange will share best practices in data partnerships for statewide transportation planning.   From the discussion, a synthesis of effective strategies, methods and tools will be identified for addressing factors that influence capabilities to share spatial and other data between and within federal, state and local governments.

We are sending this survey to members of A1D09.  If we find the results to be useful, we may survey all individuals in state DOTs who were identified as being responsible for the management of statewide data management activities.

Whether you intend to attend the Peer Exchange or not, please take a few moments to complete this survey to help make the Peer Exchange as effective as possible.

If you are not attending, please complete Part 1 only.  If you are attending, please complete both parts of the survey.

We would appreciate your completion of the survey by May 1   If you have any questions regarding the survey, please email James Hall at jhall1@uis.edu or Anita Vandervalk at avanderalk@camsys.com.

Thanks for you valuable contributions!

PART I

The purpose of these questions is to (A) To determine which issues associated with data partnering are the most critical for you in your present situation and (B) To indicate your areas of need for further guidance.

The eleven items listed in the table are issues and challenges related to data partnering.  Please rank each item on a scale from one to five with respect to:

A. (Areas of Importance) On a scale from 1 to 5, please indicate the item's importance to you in implementing data partnering (i.e. a value of 1indicates that the item is not relevant or important to you in achieving successful data partnering, a value of 5 indicates a high level of importance)

B. (Need for Assistance) On a scale from 1 to 5, please indicate your degree of need in terms of assistance, guidance or advice in addressing the item (i.e. a value of 1 indicates that no assistance is needed and a value of 5 indicates that you need help with the issue)

Issues &

Challenges to Data Partnering

Areas of Importance

1 = Not Relevant

5 = Extremely Important

Need for Assistance

1 = No Assistance Needed

5 = High Interest in Support

Cultural and institutional barriers

Roles and responsibilities of partners

Data definitions and standards

Technology, equipment and connectivity

Data integration

Data with different spatial accuracies and resolutions

Archiving and managing large data sets

Resources, funding and cost sharing

Quantifying and qualifying the value and utility of the data partnership investments

Data privacy and security

Management leadership and support

PART II

Please complete Part II only if you plan to be a participant at the Peer Exchange.

At the Peer each participant will share a specific example of a project or initiative that involves integrating and/or sharing data in one of the following four categories of data partnerships:

  • Planning and safety data partnerships
  • Management systems data partnerships (e.g. pavement, bridge, asset management)
  • Federal, state, MPO, local government data partnerships
  • Planning and operations data partnerships

Presentations will include a discussion of the one to three most significant issues, challenges and opportunities encountered in data partnering within the chosen category and how they were overcome or resolved. 

The presentations should last no more than fifteen minutes.

Please indicate which areas you intend to present by choosing one column and indicate one to three of the topics listed in the rows (in your chosen column).

             Data Partnership

Issues &                    Categories

Challenges

Planning and Safety Data Partnerships

Management Systems Data Partnerships

Intergovernmental Agency Data Partnerships

Planning and Operations Data Partnerships

Cultural and institutional barriers

Roles and responsibilities of partners

Data definitions and standards

Technology, equipment and connectivity

Data integration

Data with different spatial accuracies and resolutions

Archiving and managi