Turin and you click on the Google Maps icon for a public transit stop, you’ll see live departure times—meaning, the predicted time the next bus or train will leave, based on real-time location data for vehicles traversing the system.
If there are service alerts, detours, or system-wide delays, you’ll see those too. “No more waiting on the corner wondering when the bus is coming,” says Martha Welsh, a strategic partner development manager on the Google Transit team. “Having that information gives people a little bit more control over their lives.”
The real-time updates do make Google Transit far more useful. But there’s a reason Google hasn’t announced any new partners in the Live Transit Updates program since it was introduced eight months ago: the technology behind it is much more complex and expensive to implement. Observers say they doubt that the revolution Google sparked when it introduced GTFS will have a sequel in the realm of real-time data—or if it does, it will be much more gradual.
For starters, transit agencies that want to provide live updates need to collect live data—i.e., the latitude and longitude of every bus and train, logged at the most frequent possible intervals. This usually means installing a GPS device on every vehicle and wirelessly transmitting the data back to a control center. Agencies must then condense this data into files full of locations and timestamps, publish the files to the Internet, and republish them as soon as there’s new data, so that Google can crunch the numbers and continuously update its predicted arrival times.
To enable all that, Google introduced a new standard in 2011 called GTFS-realtime. It builds on GTFS, but is a different animal, since it includes new feed types for trip updates, service alerts, and vehicle positions, as well as provisions for constantly refreshing this data throughout the day. In an advisory to agencies, Google puts it this way: “Because GTFS-realtime allows you to present the actual status of your fleet, the feed needs to be updated regularly—preferably whenever new data comes in from your Automatic Vehicle Location system.”
That bland statement contains a world of hurt. “It takes a lot more to create and maintain a GTFS-realtime feed than it does for a GTFS feed,” says BART’s Moore. “It’s frankly a little complicated. I think it’s going to be interesting to see how agencies adapt to that standard.”
To get technical for a moment, GTFS-realtime is based on “protocol buffers,” a method for updating records in a dataset by sending short messages. Google engineers invented protocol buffers because they needed something faster and more streamlined than XML, the usual language for exchanging data on the Web. The problem is that it takes a real programmer to master the concept. A transit agency may be lucky enough to have a spreadsheet jockey like Tim McHugh who can generate GTFS files, but it probably doesn’t have developers trained in Google’s peculiar database philosophy.
On top of that challenge, many agencies outsource the problem of automatically determining vehicle locations and generating arrival-time predictions to commercial vendors. While they might be able to figure out GTFS-realtime, these vendors aren’t always eager to feed their data straight to Google. “In many cases, there are sticky contractual arrangements about who owns the data and the predictions,” says Moore.
When it comes to the future of GTFS-realtime, “the jury is still out,” says Embark’s Hodge. “There are expectations baked into it that would require transit authorities to track their vehicles in ways that most of them don’t, and to make predictions in ways that most of them can’t. I like the idea of a real-time data standard. I just think GTFS-realtime is too ahead of its time to be truly adoptable.”
The main concern that Hodge, Moore, and others seem to be expressing is that Google designed GTFS-realtime to suit its own ambitions, rather than the needs or capabilities of the transit agencies. It’s the first sign of friction in what, since the release GTFS in 2007, has been a virtual lovefest.
Ferris, the creator of OneBusAway, is now one of the lead engineers at Google responsible for maintaining and extending GTFS and GTFS-realtime. He says Google is doing its best to respect the limitations of transit agencies while still leaving room for future innovation. “Realtime is a whole order of magnitude more complex than static scheduling—there is just no way around it,” he says. “We wanted to push the envelope in what we support. We wanted something more complex in terms of using a protocol buffer definition optimized for streaming, which gets us a lot more data. But it’s always a tension. We don’t want the spec to be this massive thing that could take five weeks just to
