This is going to be a confusing post, because we’re going to talk about SIRI, the Service Interface for Real-Time Information, and Siri, Apple’s new app for the iPhone 4S with an uncanny ability to listen, answer questions, and do things on the iPhone. But there’s a point here, and that’s that open standards like SIRI make it easier for software like Siri to work well. Siri knows what it knows because it’s able to tie into services on the Web, like Wikipedia, Wolfram Alpha, and Yelp. It’s not magic; it’s just a matter of having the right data.
Of course, with more data, Siri can do more: imagine being able to stand at a bus stop and ask when the next bus is coming, and get an answer without having to know who runs the local public transit services, or what routes serve that stop, or what the stop code is, and so on.
Building such an app, an app that lets you stand at any bus stop and ask “When is the next bus?” is a lot easier if public transport operators around the world release their data in a common, open format. Doing so means that developers don’t have to write custom software to support every city’s transit system, nor do they have to pay licensing fees to use proprietary protocols.
When every public transport operator uses a common, open format to release their data, developers can build support for a single standard, and know it will work everywhere. It means that they can tap into repositories of open data (like the GTFS Data Exchange) and use every feed they find there, without writing any additional code.
Fortunately, we have those standards, both for static schedule data and real-time data. A huge number of transit authorities release their static schedule data using GTFS, and there is growing traction behind SIRI. Hopefully, MTA New York City Transit’s adoption of SIRI will help to improve its traction in the US, where proprietary formats currently dominate.
The other major aspect to this—and what we lack right now to make this a reality—is a geo-enabled database of real-time feeds, a Web service that would allow you to pass a latitude, longitude, and radius, and get back pointers to feeds for every transit authority in the area. Without this kind of auto-discovery, developers must manually catalog feeds, and either build their own infrastructure for associating feeds with geographic areas, or, more likely, display a huge list of feeds and ask the user to pick their transit authority from the list. This, of course, brings us back to the original problem: what if you know that there are buses where you are, but not who operates them or where to get information?
You might think you could use Google Transit for this, but you actually can’t; Google doesn’t offer an API for the information they store for Google Transit. It seems like a simple proposition, considering the amount of transit data Google ingests from various transit providers, but despite continuous clamoring from developers, transit data at Google is still a one-way proposition. However, sites like the GTFS Data Exchange have developed to fill the void, and I expect eventually there will be a site that will provide a similar function for real-time data.
In short, the technology to make public transit information easier to access is all there; Siri is remarkably adept at understanding natural-language queries, and many, many transit authorities have adopted open standards to release their data. All that remains is to put the two together, and then you’ll be able to ask your phone the same kinds of questions you ask of your resident public transit wizards: “What bus do I take to…” or “Where do I catch the bus to…” or, everyone’s favorite, “When is the bus coming?”