Google Summer of Code 2016

Enabling Rapid Deployment of Real-time Transit Information

Research has shown that providing transit riders with real-time arrival information has many benefits, including a shorter perceived wait time, shorter actual wait time, a reduced learning curve for new transit riders, and increased feelings of safety (e.g., at night) [1][2][3][4][5]. Transit agencies also benefit, as the deployment of real-time information has been linked to increased ridership [6].

The process of sharing real-time information with riders starts by producing good data. General Transit Feed Specification (GTFS) and GTFS-realtime have become two of the dominant formats for open data in the transit industry.

While the production of schedule data in GTFS format is currently well covered by many tools [7][8], this is not the case for real-time arrival prediction data in the GTFS-realtime format. As of today, expensive proprietary systems must be purchased from vendors to generate arrival predictions from raw vehicle locations for a transit agency. As a result, smaller systems often cannot afford to implement real-time information, and larger agencies are often locked into using a single vendor for their proprietary system, without any real opportunity for competition to lower costs.

There are two emerging open-source projects that promise to revolutionize the transit industry - TransiTime (http://www.transitime.org/) and OneBusAway (http://onebusaway.org/). TransiTime is able to take raw vehicle position (e.g., from a low cost GPS unit) and generate arrival predictions in the GTFS-realtime format. OneBusAway is able to consume this GTFS-realtime feed and provide arrival information to OneBusAway apps on many platforms, including Android, iOS (iPhone), Windows Phone, Windows 8 & 10, Amazon Fire Phone, Google Glass, and more. Because these systems are open-source, there is an opportunity for anyone to deploy and modify them, without any licensing costs. This allows for competition among vendors to maintain and improve the system, which in turn lowers agency costs to deploy such a system.

There are currently two significant barriers to using the TransiTime and OneBusAway open-source applications together that we would like to address in a Google Summer of Code project - 1) a complex setup process for TransiTime, and 2) the required ongoing maintenance of the TransiTime prediction engine.

1. Complex setup process - Currently, the setup of TransiTime is a very complex process, with little available documentation, which creates the first barrier to using TransiTime. The first goal of this project is to produce a “QuickStart” version of the TransiTime application, a function similar to to what is currently provided in OneBusAway. The TransiTime QuickStart application should take a GTFS file URL, a GTFS-realtime vehicle location URL and from there be able to start up a TransiTime instance. This instance by default should provide a GTFS-realtime trip updates feed as output so it can easily be consumed by the OneBusAway QuickStart application. Ideally, the necessary software/scripts/documentation would be created to set up and run TransiTime and OneBusAway with a single command-line statement or a double-click of an application to start TransiTime.

2. Ongoing maintenance of the TransiTime prediction engine - The second barrier is that once TransiTime is installed, it needs to have its historical data sets updated on a regular basis to improve the predictions. The second goal of this project is to automate this process as the software runs rather than as a manual step by the administrator. This automation could be achieved by introducing a caching mechanism to TransiTime such as Ehcache or Apache Commons JCS. This would allow the system update its historical data as it runs and in turn produce predictions based on this data. A historical average of the last three days trips on the same route would be one method. A more complex method such as a Kalman filter could also be used to calculate predictions based on the data in the cache. This is a stretch goal, and progress will likely depend on the complexity of realizing the QuickStart goal.

Questions about this project should be directed to the onebusaway-developers group.

References

1. Kari Edison Watkins, Brian Ferris, Alan Borning, G. Scott Rutherford, and David Layton (2011), "Where Is My Bus? Impact of mobile real-time information on the perceived and actual wait time of transit riders," Transportation Research Part A: Policy and Practice, Vol. 45 pp. 839-848.
2. C. Cluett, S. Bregman, and J. Richman (2003). "Customer Preferences for Transit ATIS," Federal Transit Administration. Available at http://ntl.bts.gov/lib/jpodocs/repts_te/13935/13935.pdf#sthash.jwn5Oltr.dpuf
3. Lei Tang and Piyushimita Thakuriah (2012), "Ridership effects of real-time bus information system: A case study in the City of Chicago," Transportation Research Part C: Emerging Technologies, Vol. 22 pp. 146-161.
4. Brian Ferris, Kari Watkins, and Alan Borning (2010), "OneBusAway: results from providing real-time arrival information for public transit," in Proceedings of the 28th International CHI Conference on Human Factors in Computing Systems, Atlanta, Georgia, USA, pp. 1807-1816.
5. A. Gooze, K. Watkins, and A. Borning (2013), "Benefits of Real-Time Information and the Impacts of Data Accuracy on the Rider Experience," in Transportation Research Board 92nd Annual Meeting, Washington, D.C., January 13, 2013.
6. Brakewood, Macfarlane and Watkins (2015). The Impact of Real-Time Information on Bus Ridership in New York City. Transportation Research Part C: Emerging Technologies, Volume 53, pp. 59-7
7. Google Transit Data Feed - "Other GTFS Tools" - https://code.google.com/archive/p/googletransitdatafeed/wikis/OtherGTFSTools.wiki
8. TransitWiki.org - "Creating and Maintaining a GTFS Dataset" - http://www.transitwiki.org/TransitWiki/index.php?title=General_Transit_Feed_Specification#Creating_and_Maintaining_a_GTFS_Dataset