Enabling Cost-Effective Multimodal Trip Planners through Open Transit Data

(Center Identification Number: 77926)

This project will lay the groundwork for a multimodal trip planner that will use open, publicly available data to link bicycling, walking, and transit. The project will design such a trip planning system, and then work with an open-source system to develop relevant coding standards and tools to support the integration of new multimodal trip data, including transit data.

Principal Investigators:

Edward L. Hillsman, Ph.D., Co-Principal Investigator
Phone: 813-974-2977
E-mail: hillsman@cutr.usf.edu

Sean Barbeau, Co-Principal Investigator
Phone: 813-974-7208
E-mail: barbeau@cutr.usf.edu

Center for Urban Transportation Research
University of South Florida
Fax: 813-974-5168

External Project Contacts:     

Thomas M. Kelly, PLS GISP
District Seven GIS/EDMS Coordinator
Florida Department of Transportation
District Seven, OIS
11201 N. McKinley Drive
Tampa, Florida 33612
(813) 975-6774 (Office)
(813) 975-4851 (Fax)
tom.kelly@dot.state.fl.us
 

Amy W. Datz
State Transit Environmental Facilities Design Program Manager
Public Transportation – Transit Office
Florida Department of Transportation
605 Suwannee Street, MS 26
Tallahassee, Fl. 32399-0450
(850) 414-4239 (Office)
(850) 414-4508 (Fax)

 

I.  Project Objective/Problem Statement

The integration of multimodal data and information systems, including Global Positioning Systems (GPS) technologies and mobile devices (e.g. cell phones), is the next evolution of advanced traveler information systems and has been identified by the Federal Transit Administration Intelligent Transportation System Program as part of their 2009–2029 Strategic Plan. However, most transit information is currently locked into proprietary formats and systems and cannot be easily shared, viewed, updated, or co-mingled without permission from the vendor and expert data analysis. This limits the ability of transit agencies and others to provide information resources, such as trip planning tools, that support the use of transit or other alternatives to driving. As examples of some of the obstacles:
• A transit agency that wants to integrate walking, bicycling, and park-and-ride access with its Google Transit routing application must either wait for Google to decide to do the work (Google has not indicated that it has any plans to add these data or capabilities to its system); or else it must bear the expense itself of recreating the same type of system to add the functionality it desires.
• A recent multimodal trip planning system, Goroo.com, developed for the Chicago metropolitan area, cost $1.0 million. Although the Goroo.com system is truly intermodal for walking, driving, bus transit, and rail transit—meaning that it plans trips that allow the user to walk or drive to transit, and then walk from transit to the final destination—it has significant limitations. It does not include bicycling (although this is planned); it is not clear that it actually has data on sidewalks; and its present coverage is limited to the Chicago area for which it was developed. Developing a comparable system for another area would be expensive, whether this is done from scratch or done by acquiring the Goroo.com software and populating it with data for the new area.
• Other multimodal trip planning systems exist but have limited functionality. For example, OpenRouteService.org, which provides coverage in much of Europe, can provide information about how to get between two locations by bicycle, or by walking, or by driving, but it does not work with transit, and it was not designed to plan a trip that begins using one mode (e.g. walking) but needs to switch to another (e.g. transit) to reach the destination. The service uses publicly-available data, but the software is not publicly available and would have to be duplicated elsewhere.
There are three major barriers to developing multimodal trip planning services that can work in more than a single U.S. metropolitan area.
• The available high-quality data on street networks is provided by private vendors, such as NAVTEQ or Tele Atlas, to whom one must pay licensing and use fees.
• Although there is an evolving standard for recording transit route and schedule information ( discussed below) there is not yet a comparable, uniform, dataset of infrastructure for multiple modes such as transit, bicycling, or for walking, or for some of the infrastructure (benches, shelters, bicycle parking) that supports use of transit.
• Even if standards existed for the walking, cycling, and supporting infrastructure, it would be expensive to collect, code, and maintain the necessary data using conventional approaches managed by a single entity (e.g. private company, transit agency).
A promising strategy for overcoming these barriers is to take an “open” approach for providing data and information services. Open-sharing of information, advocated by transit agencies such as TriMet, encourages the improvement, evolution, and innovation of services to the general public since the data is available to everyone without copyright restrictions or licensing fees. For example, OpenStreetMap, maintained by the non-profit OpenStreetMap Foundation, is an open, freely available international repository of geographic data. The public, or organizations such as transit agencies with public-domain data, can add geographic information to the system that can be easily shared and viewed by others through a simple webpage-based map. Anyone with an interest in providing and using data about an area is free to do so. Anyone who finds an error in the data is free to correct it. A significant difference between this option and the closed proprietary systems (e.g. Google Maps, Google Transit) is that anyone can export data from OpenStreetMap and use this information to build new information services without paying licensing fees to a company. The OpenRouteService.org referred to earlier uses OpenStreetMap to obtain data for its routing service, as does another open-source multimodal trip planner, OpenTripPlanner. Such an open information resource thus enables a transit agency or other organization to focus on adding the functionality it desires to an existing open-source trip-planning system, rather than on bearing the cost (including licensing fees) to obtain data and recreate a service such as multimodal trip planning from scratch.
The Google Transit Feed Specification (GTFS) has encouraged over 110 transit agencies in the U.S. to put their data into a common format in exchange for a free online trip planner that Google Transit provides. Google imports this data into their proprietary system to provide the Google Transit service (http://www.google.com/transit). However, correcting the data in any existing closed, proprietary systems or updating it (e.g., to reflect damage from natural disasters) requires long lead times and adherence to special procedures established by the vendor of the information system. A transit agency that puts its data into the GTFS format for the first time can wait for months before Google incorporates it into the Google Transit service. In fact, the following message is currently displayed on the Google Transit Partner website :
Due to overwhelming interest in the Transit Partner Program, we are currently experiencing a significant volume of partner requests. Although we are unable to accept new partners at this time, we encourage you to sign-up in order to be placed on the waiting list.
This means that the transit agency can put their data in the GTFS format, but that the Google Transit service will not be immediately available for that agency. Google Transit also does not offer multimodal data or services that integrate transit, walking, cycling, and park-and-ride lot information; although it offers walking routes, it does not have complete data on the availability of sidewalks, and warns that the routes it suggests may be missing sidewalks or pedestrian paths. Furthermore, although the GTFS format is open, Google Transit does not serve as a common data repository where the underlying information can be freely shared without licensing fees or copyright restrictions. OpenStreetMap, on the other hand, is designed to be a common data repository for freely available multimodal information.
So far there has been no significant effort to support transit in the OpenStreetMap system in the United States, or to develop a multimodal trip planner that can be implemented easily and inexpensively in multiple urban areas. OpenStreetMap originated in the United Kingdom, and efforts to add U.S. geographic data to the system only recently began in 2007. This presents a unique opportunity to establish solid guidance and tools for integrating U.S. transit information in OpenStreetMap (OSM) before fragmentation in data formatting conventions emerges. Additionally, a standard protocol and software tools are required in order to facilitate the automated update of the OpenStreetMap data system whenever a transit agency releases a new GTFS dataset. Also, there must be some method of conveying edited information from OSM to the transit agency so the agency could review and vet the edits before integrating the changes into their datasets. These tools will reduce the amount of time and effort required by the transit agency to participate in the OSM community.
Creating a tool to translate GTFS data into the OpenStreetMap format will enable over 110 transit agencies to import their transit data into OpenStreetMap and share this data with each other, the general public, and open-source software developers. Transit agencies can then leverage contributions from this community to improve the accuracy of their bus stop and route information, as well as the nearby locations of amenities that enable multimodal transportation including bike racks, sidewalks, crosswalks, traffic signals, etc. Some of this information about amenities will be available for upload from public domain data files maintained by local governments. The rest would be contributed by citizens, neighborhoods, or local communities interested in having better trip planning and, ultimately, better transit service available.

II. Objectives/Tasks

 

This project will lay the groundwork for a multimodal trip planner that will use open, publicly available data to link bicycling, walking, and transit. The project will design such a trip planning system, and then work with an open-source system to develop relevant coding standards and tools to support the integration of new multimodal trip data, including transit data. The project will demonstrate the ability to upload data that Florida transit agencies have prepared into the open-source system, and develop a simplified working prototype of the larger trip planning system that can link walking, bicycling, and transit to compute routes between origins and destinations. The data, conversion software, and working prototype developed by the project will be available to anyone to use, modify, or improve.   When possible, open-source software from existing projects such as the OpenTripPlanner project will be utilized, as well as data from existing Florida data repositories such as the Florida Geographic Data Library (FGDL), Roadway Characteristics Inventory (RCI) data, and other relevant data repositories from the FDOT Transportation Statistics Office.  This should make it substantially easier and less expensive for transit agencies in Florida, and for trip planning service providers (e.g. Google Transit), to provide intermodal trip planning information to potential users of Florida transit systems.

This project has the following objectives:

  • Develop performance specifications for a fully-operational multimodal trip planning system (a high-level description of how the system will work and what it will do); include in these specifications the ability for a user to emphasize pedestrian and cyclist safety, rather than simply the length of the route or the time it takes to complete the trip.
  • Develop coding standards for recording data about bicycling, walking, and transit infrastructure in OpenStreetMap, to support intermodal routing, and work with the OSM community to get the standards adopted.
  • Prepare software to transform transit data stored in the Google Transit Feed Specification format into OpenStreetMap, and to convert transit data stored in OpenStreetMap back into the GTFS.
  • Develop a simplified working prototype routing engine that uses data stored in OpenStreetMap, which conforms to the data conventions outlined in this project, to compute routes between points, with links between walking, bicycling, and transit as needed to accomplish the trip.  When possible, existing open source software from projects such as the OpenTripPlanner project will be utilized.

Work not included in this scope of service is not to be performed and will not be subject to compensation by the Department.

The following are the anticipated tasks necessary to achieve the above objectives.

Task 1: Kick-off meeting (required of NCTR projects) and project management

CUTR will conduct a netconference kick-off meeting within 30 days of beginning the project. At a minimum, the project managers and principal investigators will attend. CUTR also will advise the following persons of the meeting and offer the option of attending in person or via netconference. Other parties may be invited, as appropriate:

  •   FDOT Research Center staff
  • FDOT state bicycle and pedestrian coordinator

The meeting will review and discuss the project’s tasks, schedule, milestones, deliverables, reporting requirements, and deployment plan. Task 1 will also include project management by CUTR, including preparation of quarterly progress reports, and internal review.

Task 2: Coordinate with Outside Agencies

CUTR will coordinate with outside organizations who have an interest in the project. During the project, CUTR will seek advice and perspective from members of outside organizations to improve the effectiveness and usefulness of the project’s results. However, because the project scope ranges from database design all the way to user perspectives on software designs, it is unlikely that CUTR will convene all members from involved groups at once, even by netconference, or ask all members from outside organizations to comment on any particular part of the project. CUTR will coordinate with the following organizations:

  • TriMet, the public transportation in Portland, Oregon, because they have made some data available for open development and have experience with the benefits and challenges of doing so
  • 1-2 public transportation agencies in Florida with experience in preparing data for use by Google Transit, partly because they have experience with any difficulties in doing so, and partly because we would want to use one of them as a setting for demonstrating prototype software. In addition, one agency not currently providing their data in the Google Transit Feed Specification (GTFS) format, to get their perspective
  • A public transportation agency, firm, or organization with an intercity bus perspective
  • Google’s routing/mapping/trip-planning unit, because Google has expressed some interest in working with open data, and may be willing to share experience in planning and developing the multimodal trip planner
  • A business such as Trillium or CloudMade which is active in using open transportation data as part of its business plan
  • Someone with a strong background in bicycling, possibly a bicycle researcher, possibly someone from an organization such as the League of American Bicyclists or the National Center for Bicycling and Walking
  • Someone with a similarly strong background in pedestrian issues, possibly someone from the National Center for Bicycling and Walking
  • 2-3 from the OpenStreetMap community, most likely from Europe, both to offer guidance on how to accommodate differences between U.S. and European conditions and practice within OSM, and to help with the process of extending OpenStreetMap to use transit data

CUTR will advise members of outside agencies of the scope of the project, request input in tasks 4 and 5, and request advice from various members of outside agencies as needed throughout the project.

Task 3: Review literature, OSM data structures, and related work

CUTR will review literature and current practice in multimodal trip planning (mostly portions focused on individual modes, which would need to be integrated to yield a multimodal trip planning application).

CUTR will ascertain ability of present OSM data structures, protocols, and institutions to host timetable and other transit, cycling, and walking infrastructure data necessary for multimodal trip planning. If possible, CUTR will ascertain the present ability of Google data structures, protocols, and institutions to host cycling and walking infrastructure (given that they already do so for transit data).

CUTR will review the following for their ability to link with each other (each includes references to transit stops), and for consistency with OSM (including copyright issues):

  • GTFS
  • the FDOT-supported Florida Transit Information System (FTIS) Automated Transit Stop Inventory (ATSIM)
  • Route information stored in FTIS for coverage of needed data
  • FDOT District 7 enterprise GIS system
  • Florida Geographic Data Library (FGDL)
  • FDOT’s Roadway Characteristics Inventory system
  • Other data from the FDOT Transportation Statistics Office, as relevant

CUTR will identify overlap, gaps, and potential centralized sources of data to populate missing data fields. It is always possible to use OSM’s crowd-sourcing approach to collect and record data. However, this is not always the most efficient way to get new data into the system, particularly when a transit agency or someone else has already collected it and is willing to make it available.

Task 4: Engage OSM community for integration of transit data

Subtask 4a: Engage OSM community to determine a methodology for integrating transit data

CUTR will engage with the OSM community to broaden or develop protocols to accommodate needed data that falls outside OSM’s current data structures and protocols. OSM has developed collaborative, consultative processes for modifying how it stores and uses data; these appear to take 2-3 months even for small changes, and something as different as timetable data may take longer. Knowing the need to work with timetable data, CUTR will begin this part of the task shortly after beginning work on the project. CUTR also will disseminate information about the project to the OSM community early in the project, to identify additional resources, possibly including persons interested in contributing software code or data to the project. If possible, CUTR will undertake similar discussions with Google for expanding their driving and transit route planning service to work with infrastructure for cycling and walking. However, this will be as far as the project goes with Google, other than to share the results of the project with them. Google knows its software and data and is in a better position to modify it than is CUTR, and the company has private resources available for the task should it choose to do so.

Subtask 4b: Develop protocol and software tool for data management between transit agencies and OSM

Once transit data is uploaded into OSM, it becomes available for anyone to review and edit. CUTR anticipates that, initially, little editing will occur, and that most editing will be to correct errors in the transit data (such as the location of transit stops). Periodically, agencies will change routes, stops, or service, and they will update their data and reload the revised data into OSM. CUTR will work with OSM and the transit agencies to develop a protocol for working with corrections made to agency data by OSM users, so that true corrections are preserved and fed back to the agency, and that errors introduced by OSM users can be identified as such and replaced with correct data when the agency replaces the data stored in OSM with updated data.

Based on the developed protocol, CUTR will create translation software to convert data from selected formats (e.g. GTFS) into formats suitable for upload to OSM, and demonstrate upload of Florida transit data to OSM. Selection of supported formats will be based on the review conducted in Task 3 and the feasibility of implementation under this project. CUTR will make the translation software available to the OSM community as open-source software for download from their affiliated servers. In order to facilitate the entry of new geographic information into OSM, CUTR will also integrate support for the OSM-compatible GPX format into the TRAC-IT GPS-enabled cell phone data collection system. This support will allow data collected using TRAC-IT to be easily uploaded into the OSM system.

This task, and especially subtask 4a, may run concurrent to earlier tasks in order to maximize the available amount of time to develop the coding protocols and software under this task.

Task 5: Develop performance specifications and supporting data requirements for multimodal trip planner

CUTR will develop a high-level description of how the multimodal trip planner should work (performance specifications). This task may run concurrent with earlier tasks as information about the various systems is gathered. These specifications will include high-level functions such as transferring (interlining) between different organizations operating the same transportation mode (such as neighboring transit agencies) and between modes, as well as buffering to retrieve data on supporting infrastructure. Based on current understanding of the literature on bicycling and walking, they are also likely to include explicit treatment of the ability to cross streets, rather than to just traverse them. CUTR will also prepare a list of data requirements (e.g. timetable data, transit stop data, supporting bicycling and walking infrastructure such as crosswalks or traffic signals) needed to support such a trip planner. CUTR will submit a working draft to relevant members of outside organizations for its review, suggestions, and comments. CUTR anticipates extensive revision of the draft following this review, and will submit the revised draft to members of outside organizations for further comment if warranted. CUTR will submit the final draft as a deliverable to FDOT.

Task 6: Implement a simplified prototype multimodal routing engine

CUTR will review open-source routing software developed for use with OSM and GTFS data (e.g., OpenTripPlanner) to determine whether it needs any features or data beyond what is in the performance specifications developed in Task 5. CUTR also will identify what changes will be needed to the software so that it can meet the performance specifications. For example, software that now uses OSM data may not have been written in anticipation of working with timetable data; it may also requires modification to work with proximity buffer data (for example, to determine whether there is bicycle parking or a crosswalk “at” the bus stop). CUTR will determine which of these can be handled by processing the data before routing, and which, such as working with timetables or other trip planning criteria, will require changes to the routing software itself. CUTR will use this information, and any existing relevant software tools, to implement a simplified working prototype routing engine that uses data stored in OSM to compute routes between points and links walking, bicycling, and transit as needed to accomplish the trip. This task may run concurrent to earlier tasks in order to maximize the available amount of time to develop any necessary software under this task. Results of this task will be made available to bike/pedestrian planners and transit agencies for review and feedback.  As the prototype is developed, refinements to prototype will be made based on comments from the review agencies.

Task 7 Deliverable: Prepare draft final report

CUTR will prepare a draft final report documenting work on the project and its results. CUTR will submit the draft final report to Sandra Bell, sandra.bell@dot.state.fl.us, at the FDOT Research Center 90 days prior to the end date of the contract. FDOT will have a 30-day review period before providing recommendations, then an additional 15 days for a second review before final approval of the draft report. The submission also will provide an electronic copy of the draft final report (in Microsoft Word), and a printed double-sided copy of the draft final report. to be forwarded to the FDOT co-Project Managers for their use in the review.

Task 8 Deliverable: Final report

Upon FDOT approval, CUTR will finalize the report from Task 7, and prepare a PowerPoint presentation summarizing the project. CUTR will transmit both to Sandra Bell, sandra.bell@dot.state.fl.us, at the FDOT Research Center in Tallahassee, in electronic format. CUTR also will provide an electronic copy of the draft final report (in Microsoft Word), and a printed double-sided copy of the final report, to be forwarded to the FDOT co-Project Managers.

III. Deliverables

Project Kickoff Meeting: A kick-off meeting shall be scheduled to occur within the first 30 days of execution by the university. The preferred method for the kick-off meeting is via teleconference or video conference. As a minimum, the project manager and the principal investigator will attend. The Research Center staff must be advised of the meeting and given the option to attend. Other parties may be invited, as appropriate. The subject of the meeting will be to review and discuss the project’s tasks, schedule, milestones, deliverables, reporting requirements, and deployment plan. A summary of the kick-off meeting shall be included in the first progress report.

The description of Task 1, earlier in the scope, notes parties who will also be invited to participate in the kick-off meeting.

Progress Reports: The University will submit quarterly progress reports to the Research Center.   The first report will cover the activity that occurred in the 90 days following the issuance of the task work order.

Reports should be submitted within 30 days of the end of the reporting period.  Reports are due even if little or no progress has occurred (in which case, the report should explain delays and/or lack of progress). Progress reports should be sent in MS Word to Sandra Bell, Sandra.bell@dot.state.fl.us.

Progress reports must include the following information:

1.       Contract number, task work order number, and title

2.       Work performed during the period being reported

3.       Work to be performed in the following period

4.       Anticipated modifications (i.e., to funding, schedule, or scope).  This section is for reporting/informational purposes, not for officially requesting an amendment.
 Note:  To request an amendment to a contract, the contractor must provide the project manager with the appropriate information (i.e., what is being requested with justification) in the required format.  If the project manager concurs with the request, he/she shall forward it with his/her approval and commentary, as appropriate, to the Research Center for administrative review and processing (pending available funds, etc.)

5.       A progress schedule updated to reflect activities for the period being reported.

Failure to submit progress reports in a timely manner may result in termination of the work order.

Draft Final Report: The Draft Final Report is due 90 days prior to the end date of the task work order.  The draft final report will be submitted to Sandra Bell, sandra.bell@dot.state.fl.us.  It should be edited for technical accuracy, grammar, clarity, organization, and format prior to submission to the Department for technical approval.  The Research Center expects contractors to be able to provide well-written, high-quality reports that address the objectives defined by the scope of service.  Draft final reports must be prepared in accordance with the “Guidelines for Preparing Draft Final and Final Reports” posted at http://www.dot.state.fl.us/research%2Dcenter/Program_Information/Guidelines%20for%20Preparing%20a%20Final%20Report%2012-07.pdf.  This document provides information on all report requirements, including format, the technical report documentation form, disclaimer language, and so forth.

CUTR also will provide an electronic copy of the draft final report (in Microsoft Word), and a printed double-sided copy of the draft final report, to be forwarded to the FDOT co-Project Managers for their use in the review.

Final Report: Once the draft final report has been approved, the university shall prepare the final report.  The university will deliver a minimum eight (8) copies of the final report in MS Word on CD or DVD.  The CD/DVDs should be labeled in a professional manner and include at a minimum the contract number, task work order number, project title and date.  

The final report is due no later than the end date of the task work order and should be delivered to the following address:  

The Florida Department of Transportation

Research Center, MS 30

605 Suwannee Street

Tallahassee, FL 32399-0450

CUTR also will provide an electronic copy of the draft final report (in Microsoft Word), and a printed double-sided copy of the final report, to be forwarded to the FDOT co-Project Managers.

IV.  Project Schedule

Start Date:  February 2010               Expected End Date: June 2011

V.  Project Budget

The proposed budget for this research project is $100,000.

VI. Use of Graduate Student(s) and Other Research Assistants

A graduate student will assist in reviewing literature and in the review of open-source software and OSM data structures and protocols. The student also will assist in developing the conversion software, the working prototype and its specifications, and the final report. The student will have background in computer science and/or geographic information systems, ideally including experience in programming and working with geographic and network data.

CUTR will not pay tuition for the graduate student working on this project. The hourly rate it offers is intended to be high enough for a student to pay his/her own tuition.

VII. Equipment

No equipment will be needed.

Leave a Reply

Please complete the simple math problem prior to submitting your comment. This reduces spam. Thanks! * Time limit is exhausted. Please reload CAPTCHA.

This site uses Akismet to reduce spam. Learn how your comment data is processed.