Improving Access to Transit through Crowdsourced Information

(Center Identification Number: 77969-00)

Principal Investigator:

Sean J. Barbeau, Ph.D., Principal Mobile Software Architect for R&D
National Center for Transit Research (NCTR) at the
Center for Urban Transportation Research (CUTR)
University of South Florida
4202 E. Fowler Avenue, CUT 100
Tampa, Florida  33620-5375
(813) 974-7208

DSR Contact:

Sharon Pinson, Sponsored Research Administrator
Office of Research and Innovation
University of South Florida
3702 Spectrum Blvd, Suite 165
Tampa, Florida  33612-9445
(813) 974-0360

Project Manager:

Elba Lopez, FDOT Project Manager
Regional Transit/Intermodal Systems Planning
FDOT Dist. 7 – Intermodal Systems Development (ISD)
11201 N. McKinley Drive, MS-7-500
Tampa, FL 33612-6403
(813) 975-6403

Purpose and Benefit of Research

The purpose of this research is to facilitate the ongoing collection of information about potential areas of multimodal service and infrastructure improvements from the public that can be easily shared with transit agencies, departments of transportation, and city and county governments. This research will enable the capture of various types of data from actual users of public transportation via a real-time transit information system. Using this data, transit agencies, departments of transportation, and city and county government will be able to better target improvements to bike and pedestrian infrastructure for access to transit based on actual transit use and issues reported by the general public.

Background Statement

Riders must first take on the role of pedestrians or bicyclists to gain access to transit. The safety of these riders is at risk if bicycle and pedestrian infrastructure (e.g., bike lanes, sidewalks) are missing or inadequate. In 2009, Florida had the highest per capita rate of pedestrian fatalities in the nation[1]. In 2011, 4 of the 5 top most dangerous metro areas were in Florida[2]. Understanding the true nature of multimodal trips planned by the general public, especially the “first mile” and “last mile” of these trips, is critical to providing safe and accessible transit service and planning improvements for supporting pedestrian and bike infrastructure.

Transit agencies, local governments, and FDOT must prioritize costly infrastructure improvements based on limited data and analysis. Prioritization is often based on a simple “buffer” surrounding the planned transit route and calculations of the number of people in a particular area. Typically, little information about the origin and destination of transit riders beyond the transit stop is known. Additionally, actual access to the transit stop via sidewalk or bike infrastructure beyond the bus stop, as well as the current condition of this infrastructure, is not usually considered due to lack of data and tools to perform this type of analysis.

[1] Shaw, Rob. “Tampa Bay Area sees high number of pedestrian deaths,” March 28, 2011.

[2] Transportation for America. Dangerous by Design 2011.

Project Objectives

This project will modify a real-time transit information tool, based on prior research conducted for FDOT and the recent deployment of OneBusAway by Hillsborough Area Regional Transit (HART) (, to collect information from the general public that can aid in the identification and prioritization of infrastructure and service improvements. This technique of collecting data from users of a system is typically referred to as “crowdsourcing” information.

HART launched OneBusAway in mid-August 2013 as the primary customer-facing real-time information tool for HART transit riders, which provides real-time estimated arrival information via mobile apps. OneBusAway currently contains a feature that allows users to report errors in estimated arrival times.

As part of this project, OneBusAway will be enhanced to allow users to contribute additional data useful for improving multimodal service and infrastructure. Examples of types of data that could be collected include:

  • Transit user travel behavior (e.g., origin and destination, transit boarding and alighting locations, and travel path)
  • Missing or damaged infrastructure near transit service (e.g., lights that are out, broken sidewalks preventing access to a bus stop)
  • Requests for new infrastructure near transit service (e.g., missing sidewalks and bike lanes that are needed for direct access to a bus stop)
  • Survey information (e.g., perception of safety, desired new transit service, quality of transit service)
  • Other issues with transit service or multimodal infrastructure (e.g., constantly full bike racks near bus stop or on bus)

The integration of crowdsourced data collection abilities into OneBusAway will be unique for several reasons:

  1. OneBusAway can be deployed to any community – OneBusAway is open-source software, which means that anyone can download and deploy OneBusAway in a community. Other issue reporting systems only cover one or two geographic areas, and don’t provide access to the underlying source code to allow deployments to new communities. Additionally, because OneBusAway is open-source, communities can share software improvements and collectively implement new features faster than a single city could alone.
  2. OneBusAway naturally attracts transit riders – Transit riders use OneBusAway multiple times a day to answer the question “Where is my bus?” Therefore, OneBusAway already has an engaged user-base with a natural incentive to continuously interact with the system. Other issue reporting sites don’t provide useful information back to the user that incentivizes them to repeatedly return to the site. Additionally, since many riders use OneBusAway while they are waiting for a bus, these users may be more inclined to contribute information (e.g., answer survey questions) while they are waiting vs. other tools (e.g., a survey email or phone call) that reach the user when they are busy with other tasks throughout the day.
  3. OneBusAway can passively collect other types of data – In addition to issue reports (e.g., a sidewalk is broken), the OneBusAway mobile apps can automatically collect usage and location information from users (with the user’s permission) that will give agencies insight into how riders are using the transportation system, which can aid in multimodal service improvements.
  4. OneBusAway has a suite of mobile apps for all popular smartphone platforms with an active developer community – Open-source OneBusAway mobile apps are available for iPhone, Android, Windows Phone, and Windows 8, allowing OneBusAway to reach users on a large number of mobile devices. Other issue reporting sites typically only support one or two mobile device platforms. Additionally, OneBusAway has a constantly-growing developer community with deployments in several cities, which can support the long-term evolution of the system, including bug fixes and new features.

As mentioned above, the system and methodology developed in this project could be deployed to any community that has transit data in the General Transit Feed Specification (GTFS) format and real-time transit information. To demonstrate this ability, this project will also seek to expand the coverage of the OneBusAway system through deployment to an additional transit agency.

Certain tasks for this project may occur in parallel, and will be iterative in nature.

The proposed scope of work will consist of the following tasks:

Supporting Tasks and Deliverables

Task 1. Review existing crowdsourced data collection systems

Some existing systems include the ability to collect issue information from users, although none of these systems include the advantages of data collection integration into OneBusAway as outlined above. However, the implementation of data collection abilities with OneBusAway may be informed by a review of existing systems to identify what types of data are being collected. This task will review existing systems that include a crowdsourced data collection component, such as Tiramisu ( and Street Bump ( Mystery rider programs that silently audit the transit experience from a rider’s perspective ( will also be reviewed to determine what type of data is typically collected.

The research team will participate in monthly meetings organized by FDOT D7 throughout the project so that FDOT D7 staff and regional agencies can provide input on what types of crowdsourced data would be useful to support their operations, and how to best reach users that could provide valuable information to the agencies. Agencies’ marketing staff will also be encouraged to participate so that there is a seamless transition from the design stage to the deployment and testing stages of the project. The research team will also provide updates on the progress of the project and provide demonstrations of software when possible.

Task 1 Deliverable: Document describing existing crowdsourced data collection systems. Deliverable will be sent to

Task 2. Prepare for expansion of OneBusAway to a new agency

Review schedule and real-time data and information systems for agencies willing to participate in the project to determine if they are compatible with OneBusAway. A strategy for exporting real-time information from the agency and importing this information to OneBusAway will be formulated. The location of OneBusAway server hosting will also be determined in coordination with HART, to evaluate if HART’s existing server can be utilized for this project.

In order for a new OneBusAway deployment to be created, the real-time transit information from the agency must be made available to the OneBusAway system in a compatible format. The research team will implement any software necessary to convert the format of the participating agency’s real-time data from the agency’s format to a format compatible with OneBusAway. The team will leverage existing software for this task when possible. The selected agency will need to work with their vendor to ensure that the appropriate data is available to the project team. For example, real-time data will need to be matched to schedule data in the General Transit Feed Specification (GTFS) format (e.g., trip_ids). Some real-time systems may not provide sufficient data to do this matching as they were originally deployed. In this case, the agency will need to work with vendor to modify the data so that the match can be made and the proper data can be retrieved via the public real-time data Application Programming Interface (API). In another example, the research team will need to pull data for the entire real-time state of the transit system in a single request. Some APIs limit the number of records that can be retrieved in one request. Other data/API requirements may arise as the team works with the data.

OneBusAway Tampa was primarily designed to disseminate information to transit riders. The research team will review the current architecture to determine if changes need to be made to support the collection of information from transit riders and other citizens, as well as the sharing of information with administrators who wish to review collected data. Modifications will be made if necessary.

The research team will continue to meet with FDOT D7 and transit agencies to provide updates on the progress of the project and provide demonstrations of software when possible.

Task 2 Deliverable: Upon completion of Task 3, the university will submit to documentation summarizing the planned expansion of OneBusAway to a new agency. For any software that is developed, a link will be sent containing source code for data processing software uploaded to Github (a source-code sharing site), along with instructions for how the software can be configured and executed on the Github wiki.

Task 3. Design and implement software to collect data from OneBusAway users

Using the results of the Task 2 review and feedback from the data discussion forum, in conjunction with the FDOT project manager, the research team will identify and prioritize the data to be collected from users as part of this project. The OneBusAway community and OneBusAway Board of Directors will also be consulted to ensure that selected data and collection processes aligns with the overall goals of the OneBusAway project, including user privacy protection. The USF Institutional Review Board procedures for data collection from human subjects as part of a research project will also be followed, including the filing of proper documentation with USF as required.

The software that will collect this data from OneBusAway users and submit it to a server for data storage and processing will be designed and implemented. Various methods of data collection will be examined based on the type of data being collected (e.g., background software execution for location data collection, multimedia data collection based on pictures of broken bus stop infrastructure).

The research team will continue to meet with FDOT D7 and transit agencies to provide updates on the progress of the project and provide demonstrations of software when possible.

Task 3 Deliverable: Upon completion of Task 4, the university will submit to a link to software source code to collect data from OneBusAway users uploaded to Github, as well as documentation summarizing the data that is being collected, including any IRB documentation.

Task 4. Design and implement software to receive and visualize data from OneBusAway users

This task will design and implement the software that will receive collected data from OneBusAway users, and visualize this data. This task will include a review of methods and tools to view the data, including the OneBusAway website, open-source tools such as those surrounding the Open311 specification (, existing websites such as SeeClickFix (, and existing FDOT systems. When possible, open-source software, existing open specifications and protocols, and existing sites will be leveraged. The ability to display information to the general public, as well as two-way communication with the public on reported issues (e.g., via discussion threads), will likely be high priorities in the choice of the visualization system. If possible, anonymous submissions should also be allowed to protect user privacy when the user does not want to disclose their identity. Another high priority will be the ability to replicate the system in another city deploying OneBusAway software. Therefore, the use of proprietary software and libraries should be avoided when possible.

The research team will continue to meet with FDOT D7 and transit agencies to provide updates on the progress of the project and provide demonstrations of software when possible.

Task 4 Deliverable: Upon completion of Task 5, the university will submit to a link to software source code to receive and visualize data collected from OneBusAway users uploaded to Github, or documentation for system configuration if existing sites or software is used.

Task 5. Deploy and test OneBusAway with data collection software for the participating agencies

Deploy and test OneBusAway for the participating agencies, including the software necessary to support OneBusAway (e.g., Apache Tomcat, XWiki, MySQL, data processing and collection software). If HART’s existing OneBusAway server can be used for the selected agency’s deployment, then this task will include configuring that server to include the new agency’s schedule and real-time data. This task will also involve directing the agency to perform a data accuracy evaluation. Both the scheduled and real-time data will need to be thoroughly checked for accuracy. This includes the accuracy of estimated arrival times, in that the amount of time remaining that is shown to the transit rider waiting for the bus matches the actual amount of time until that bus arrives. Participating agencies will be expected to perform accuracy evaluations under the direction of the research team to ensure that the data being used in OneBusAway and being shown to transit riders is accurate. This will include field testing where agency representatives will wait for buses to arrive, measure the amount of time between the estimated arrival time and the actual arrival time, summarize the results and share with the research team. Acceptance testing plan will also be developed to ensure that the test results are sufficiently accurate. The system may be launched for a select group of users before being made available to the general public. The participating agencies will be responsible for recruiting users to test an early version of the system. The agency will be expected to reply to customer service requests by users of the OneBusAway system. During the duration of the research project, the research team will assist in resolving OneBusAway issues. However, there may be some issues that are outside the research team’s control (e.g., an internal agency AVL database going offline). Participating agencies will be expected to respond quickly to technical support requests from the research team to ensure real-time data is consistently online and available to OneBusAway. If the transit agency wishes to extend the operation of the OneBusAway system beyond the end of the research project, they will be expected to identify, and if necessary procure, technical support. One regional strategy for long-term support is to join with other agencies, including HART, for a single regional OneBusAway support RFP. The research team will connect participating agencies with HART and facilitate joint RFP discussions.

The research team will continue to meet with FDOT D7 and transit agencies to provide updates on the progress of the project and provide demonstrations of software when possible.

Task 5 Deliverable: Upon completion of Task 6, the university will submit to a link to the new OneBusAway deployment, along with the source code for the OneBusAway deployment uploaded to Github.

Task 6. Merge improvements back to the main OneBusAway project

For this research to be immediately useful in other cities, the improvements to the OneBusAway Tampa software should be merged back to the main OneBusAway project on Github ( This task will ensure that other Florida cities, and cities around the world, will have immediate access to the research results at the end of this project. Information about the availability of the new tool will be disseminated to multimodal agencies via various channels such as trade conference and email distribution lists so these agencies are aware of the OneBusAway system.

The research team will continue to meet with FDOT D7 and transit agencies to provide updates on the progress of the project and provide demonstrations of software when possible.

Task 6 Deliverable: Improvements to the OneBusAway Tampa software are merged back into the main OneBusAway project. Link to deliverable will be sent to

Task 7. Draft Final and Final Report

Ninety (90) days prior to the end date of the task work order, the university will submit a draft final report to The draft final report will summarize the deployment of OneBusAway to a new agency, as well as the collection and visualization of data from OneBusAway users. The draft final and final reports must follow the Guidelines for University Presentation and Publication of Research available at

The report will be well-written and edited for technical accuracy, grammar, clarity, organization, and format.

The research team will continue to meet with FDOT D7 and transit agencies to provide updates on the progress of the project and provide demonstrations of software when possible.

Deliverable: Upon Department approval of the draft final report, the university will submit the Final Report on two (2) CDs and source code for OneBusAway improvement upload to Github. Both CDs shall contain the report in PDF and Word formats. CDs will be labeled in a professional manner and include contract number, task work order number, project title, and date.

The final report is due by the end date of the task work order and should be mailed to the Florida Department of Transportation, Research Center, 605 Suwannee Street, MS 30, Tallahassee, FL 32399-0450.

Software enhancements to the OneBusAway project will be made publicly available under an open-source software license on Github.

Use of Subcontractors

No use of subcontractors is anticipated for this project.

Use of Graduate Students (s) and other Research Assistants

Students will be used to assist with data analysis and software design and implementation.


No equipment will be purchased for this project.


Long-distance phone calls and teleconferences to communicate with the participating agencies, members of the data discussion forum, project manager, and OneBusAway Board of Directors about matters directly related to this scope of work are included in the project budget.


This project will include local travel to the selected agency for data collection and testing. The table below outlines the estimated travel expenses. All travel shall be in accordance with Section 112.061, Florida Statutes. FDOT employees may not travel on research contracts. Travel must only be requested when teleconference and web meetings cannot achieve the purpose of the travel. The maximum amount of travel is limited to $700.00. The maximum amount of indirect cost on travel is limited to $70.00.

Project Oversight and Peer Review

This NCTR project will solicit feedback from the OneBusAway Board of Directors and OneBusAway community throughout the project to ensure that the project goals align with the OneBusAway community objectives. There will be no travel related expenses associated with the activities of the expert advisory panel.

Project Kickoff Teleconference

The Principal Investigator will schedule a kickoff teleconference that shall be held within the first 30 days of execution. The project manager, principal investigator, and research performance coordinator shall attend. Other parties may be invited if appropriate. The purpose of the meeting is to review the tasks, deliverables, and deployment plan. Teleconference/web meeting should be used.

Project Closeout Teleconference

The principal investigator will schedule a closeout teleconference that shall be held during the final 30 days of the task work order. The principal investigator, project manager, and research performance coordinator shall attend. Other parties may be invited, if appropriate. The purpose of the meeting is to review project performance, the deployment plan, and next steps.


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

Financial consequences for unsatisfactory performance are referenced in Section 10 and Section 11 of the Master University Agreement, Form 375-040-64.

Publication Provision

If at any time during a TWO the University desires to publish in any form any material developed under the TWO, the University must submit to the TWO Manager a written abstract and notification of intent to publish the material and receive the TWO Manager’s concurrence to publish. Such approval to publish shall not be unreasonably withheld. If the TWO Manager does not provide a written response within 30 days after receipt, the University may publish. The publication must include the following language:

“The opinions, findings and conclusions expressed in this publication are those of the author(s) and not necessarily those of the Florida Department of Transportation or the U.S. Department of Transportation.”

Project Schedule

March 2014 to June 2015

Budget Summary

Total Project Cost $206,358

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.