If you’ve ever taken a bus, you know just how fun it is to be stuck outside in the cold wondering when the next one will come. That’s why the state of Maryland spent $2.7 million dollars developing a real-time bus tracking system for Baltimore, so that riders would finally be able to overcome the city’s “notoriously unpredictable” bus service.
When reporters asked the MTA why they opted to only show the info on their mobile webpage instead of developing an app (or better yet, formatting the data for third parties like us), the MTA responded that it would have been too expensive.
We know in many cases, the information needed to create an application is made public so private firms can attempt to develop an application at their own expense. However, it would cost approximately $600,000 more to be able to format the data from our 25-yr-old CAD/AVL system into GTFS for use by outside developers.
You read that right. Baltimore’s MTA rolled out real-time bus tracking and neglected to provide it via an Open API, because it would have cost them another 600k USD. Luckily, transitapp came to the rescue, parsed the data and re-formatted it into GTFS-realtime, so that other App developers could make use of it. The code is on Github, of course 😉
Now, the US is not really public transit heaven. If there even is such a thing, it might be somewhere in Europe, D-A-CH specifically, where Verkehrsverbuende are plentiful and real-time data is the norm for urban areas rather than the exception. Still, transit agencies hold on to their data like dragons hoard their treasures – the only means of getting onto those sweet, sweet real-time data is their official APIs, which are one-size-not-really-fits-all-solutions which they attempt to open-wash by calling them “Open Service”.
Even worse, real-time AVL data is mostly restricted to transit operators who can afford them – and thus mostly to urban areas. The suburban and rural areas of Germany seldom get any of the benefits stemming from on-board IBIS computers on their transit vehicles – in-vehicle stop information as announcements and visual displays, reliable outer displays and, of course, real time data, to name only a few. These additional features would make suburban and rural transit not only more reliable for riders in general, but also more accessible to handicapped riders.
As the situation presents itself now, though, only well-off operators usually found in urban centres can afford to deploy on-board information systems such as the German IBIS model on all their vehicles. And even if they do, their implementation often leave you shaking your head – just as the in-vehicle stop display at the top of this article, which still can’t correctly implement an encoding standard written in 1984(!).
Sneer as much as you want on Baltimore’s MTA, which (admittedly) deploys solutions on their customers which look and feel like it’s the 1990s again – Germany is not that much farther.
It is time, we took a cue from the effort made in Baltimore and took matters in our own hand. There are people out there willing and capable to re-engineer displays like the one shown at the top of this article in their own time, as a hobby – and who, I dare say, propably do a better job than the “official” vendors in doing so. What if, through a collaborative effort, we developed low-cost solutions to enable small pop-and-mom transit operators in Back of the Woods, Bavaria, to provide not only the in-vehicle information that is already standard in urban areas within Germany, but also with real-time arrival and connection information?
The pieces are already out there. And I can’t be the only one willing to invest time in making this come true. Thing is, on my own, I can’t. If you’re into this kind of thing, please ping me. Please.
 for positive effects of real-time transit information on perceived service quality, see Dziekan, K., & Kottenhoff, K. (2007). Dynamic at-stop real-time information displays for public transport: effects on customers. Transportation Research Part A: Policy and Practice, 41(6), 489-501.