After close to a year of unanswered questions and rancor, Montgomery County Ride On finally has an API. Earlier this year, Montgomery County placed their real-time passenger information system into production, under the brand Ride On Real Time. But, there was still no API.
In late April, while clicking around on Ride On’s site, I stumbled across a poorly-advertised developer resources page. Lo and behold, Ride On finally had an API.
This is, of course, what I’ve been calling for since October 2011. But does that make Ride On an open data success story? Does that make Montgomery County a good steward of taxpayer money in planning IT expenditures? Unfortunately, no.
First, about the software behind the API. It’s not something built into OrbCAD, nor SmartTraveler Plus, nor is it part of some other COTS product. Instead, it’s generated by a custom product developed by Greenhorne & O’Mara.
I don’t have any objection to transit authorities getting involved in the design and implementation of custom software—but unlike MTA NYCT’s involvement in the development of OneBusAway, there’s not much reusable value here. The software developed by G & O hasn’t been released as open source, and even if it were, it would only help those transit agencies that run OrbCAD and have no other interface to it (and they’d be better off just running OneBusAway directly).
Now, on to the API itself. There are two major standards for real-time transit data: GTFS-realtime and SIRI. Unfortunately, even some of the newer real-time transit APIs, like the Metro Transit NexTrip API and the OC Transpo Live Next Bus Arrival Data Feed, use neither of these standards. These APIs are harder for developers to use, because they require custom code which will only be useful in a particular city. There are hundreds of transit systems in the United States, and thousands around the world, and eventually, hopefully, they will all have real-time data. Writing custom code for each one of them is simply unsustainable, and that’s why standards matter.
Does Ride On’s API support industry standards? Yes, sort of. In addition to a handful of custom methods, the API also has a method which returns GTFS-realtime output, although it’s not what you’d expect. The API’s GTFS-realtime output is in the text-based Protocol Buffers format (which is intended only for debugging, not for production use), rather than the binary format expected by GTFS-realtime tools. It didn’t take much effort for me to put together a little Python script to ingest the text-formatted feed and output a valid, binary GTFS-realtime feed which worked well with OneBusAway.
The API requires authentication, a nuisance that some agencies, like BART, have done away with:
We’ve never asked you to register for BART open data and our License Agreement is one of the least restrictive in the business.
Worse, the Ride On API gives you a token, and then doesn’t tell you what to do with it. Instead, you have to log in with your username and password on every call to the API—not an insurmountable challenge, but still rather peculiar.
In summary, I’m glad Ride On finally has an API, and I’m even more excited that I was able to get the feed working with OneBusAway. But on the whole it’s a disappointment. Xerox hasn’t built native SIRI or GTFS-realtime support into OrbCAD or SmartTraveler Plus. If they had, it would be a lot easier for every agency using those products to offer a standards-compliant real-time feed. Instead, the (idiosyncratic) implementation depends on yet more custom software.
It is a success for open data, but not an unqualified success—and certainly not a model to follow.