consistent way to share their raw schedule data with outside developers, who would in turn repackage it for riders. Before that, each agency had taken its own approach to such data requests, and usually ended up having to reformat its data over and over, depending on the intended use.
“I was providing schedules in different formats to different people,” recalls Timothy Moore, longtime website manager for BART. “I was giving 511 Transit one look. I was giving some guy creating shopping-mall kiosks another look. I was thinking that if I could just release it in one format, it would make my life a lot easier. So when Google released GTFS in 2007 we were, I think, the first ones besides the originators to jump on.” Because BART was an early GTFS adopter, it was the only transit agency with a dedicated iPhone app on the day Apple turned on the iTunes App Store in 2008. (It’s called iBART and was developed by Embark, then known as Pandav.)
In truth, not every transit agency has been equally enthusiastic about standardization. “The default position of a transit agency is to protect its data and not open it up in a way that is accessible for developers,” says Embark co-founder Hodge. In some cases, agencies had relationships with outside vendors who claimed contractual rights to schedule data. In others, agencies didn’t want to give the data away for fear of losing Google Adsense ad revenue on their own websites.
But to Moore, selling or advertising against schedule data is like charging for menus in a restaurant. “I have watched transit agencies try to monetize schedules for years and nobody has been successful,” he says. “Markets like the MTA and the D.C. Metro fought sharing this data for a very long time, and it seems to me that there was a lot of fallout from that with their riders. This is not our data to hoard—that’s my bottom line.”
It took “the power of Google,” in Hodge’s words, to break the logjam. By 2009, so many transit agencies had begun to use GTFS—and the data was turning up in so many places other than Google Maps—that Joe Hughes, a U.K.-based software engineer working on Google Transit, proposed renaming the standard. “Given the wide use of the format…the ‘Google’ in GTFS is increasingly a misnomer, one that makes some potential users shy away from adopting GTFS,” Hughes wrote in a forum post for Google Transit contributors. And he wanted the change to be more than cosmetic: Hughes said it was time to hand ongoing development of the specification over to the larger community of transit agencies and app developers.
The Boys on the Bus
It’s safe to say there’s been more innovation in the world of public-transit trip planning in the last four years than in the previous four decades. Take the example of OneBusAway, a real-time guide to the Seattle-area transit system created by Googler Brian Ferris back when he was a graduate student at the University of Washington.
In its first, pre-GTFS iteration, OneBusAway was a mere side project for Ferris, something to fill his evenings during a summer research fellowship at Intel. The system used the old-fashioned File Transfer Protocol (FTP) to grab data from servers at King County Metro Transit. Riders could then get bus arrival times by keying in a stop number on their mobile phone.
But once Ferris decided to scale up the system to incorporate data from Sound Transit and other regional systems—and to base his whole PhD dissertation on the project—he needed to standardize. So he followed TriMet’s example. “The first major rewrite of OneBusAway for multi-agency support was to natively support GTFS,” Ferris says. “I didn’t want to have to keep reinventing the wheel.”
The change allowed Ferris to extend the system to the entire Puget Sound area. Today OneBusAway offers real-time bus, light-rail, and ferry arrival information for nine agencies in the region, and is accessible by Web, phone, and SMS, as well as smartphone apps for iOS, Android, and Windows Phone. Area commuters use it to plan 50,000 trips per week. While Ferris himself has
