Last week, Steve Munro ran a post describing changes to the content of the TTC‘s NextBus data feed. The issue described in Steve Munro’s post doesn’t actually pertain to the XML format itself; the problem is with how routes are identified (in other words, it’s a semantic issue, not a syntactic one). But on the subject of syntax, I am going to take this opportunity to plug SIRI. SIRI, the Service Interface for Real Time Information, is a CEN standard which is to real-time transit data what GTFS is to timetable and route data.
Unfortunately, the NextBus XML format has become something of a de facto standard for AVL data, at least in the US, where quite a few transit agencies use NextBus—but that’s a sure route to vendor lock-in. Aside from the NextBus XML format, there are other home-grown formats, like the one used by WMATA to disseminate information from its OrbCAD installation. The Clever Devices system being used by MTA New York City Transit for their pilot on the M34 and M16 has its own proprietary API (link requires login). Then there are other AVL systems, like Xerox/ACS/Orbital SmartTraveler Plus, which don’t appear to have a public API (or at least Brampton Transit’s instance doesn’t). Of the systems which do have public APIs, each one is different, and with the exception of NextBus, there are few libraries available to help developers with processing and using the data.
Fortunately, there is some light at the end of the tunnel. OneBusAway, which is quite possibly the best open competitor to NextBus, supports the SIRI standard (although with a slightly non-standard implementation). The MTA has chosen to expose their SIRI-like endpoint as part of the OneBusAway pilot on the B63 line, and I would hope that other agencies would do the same if they adopt OneBusAway. Transit agencies with an existing public API should also be encouraged to adopt the SIRI standard, although there’s not much that agencies which use NextBus for both hardware and software can do (since in that case NextBus, not the agency itself, controls the software). By adopting SIRI, transit agencies make it easier for developers to consume their data—imagine an iPhone app (for example) which could display bus times for dozens of transit agencies, without writing a single line of code to add a new transit agency.
However, as astute readers will know, OneBusAway is only a software solution. AVL systems are dependent on their hardware; you can’t really know where buses are without some hardware on every bus. In the case of the MTA OneBusAway pilot, the MTA was able to cobble together a hardware AVL solution based on existing onboard hardware supplied by VeriFone for the open payment trial. For agencies with no AVL system, or those looking to upgrade from a legacy AVL solution, there isn’t yet a good solution for feeding data into packages like OneBusAway. The conventional proprietary systems, like those from Orbital, Clever, or even NextBus, are tied to backend packages from the same suppliers, as well as (in the case of some systems) subscription fees. What is needed here is AVL hardware which is purpose-built (that means no smartphones) but which is backend-agnostic, and which transmits data in open formats.
Finally, there is another point which needs to be reiterated, although it was covered well in Steve Munro’s post: no matter what format you use to release data to the public and developers, communicate with the community! When the data that you are conveying changes, it’s imperative that you work with the developer community, and let them know what’s going on, and how they can prepare. Even better, solicit developer input to help make your data products as useful as possible.