Montgomery County Ride On finally has an API—sort of

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).

So, strike one—building more single-use software. At least it’s built on top of a fairly modern software stack, including CouchDB and Ruby on Rails.

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.

One thought on “Montgomery County Ride On finally has an API—sort of”

  1. In these situations, I think it’s better for agencies and consultant firms to seek feedback from the developer community on creating an API. You might have professionals in the transit industry that have very little to no programming experience and come up with an API that is subpar. I do feel like if G&O had gone with NYCMTA for advice on using open standards for an API, including the right way to use an API token, Ride On could have had much success with an API that developers would have an easier time creating applications with the data as well as having a modular data source that would work with other systems (granted if they supported SIRI, WMATA I’m talking to you). Sometimes, I feel that they want to take the easy way out and reinvent the wheel to create already proven standards to make a proprietary API only used in one system. As I’ve said before, most commuters don’t use one system and having to consult different sources for real-time and schedules for one journey is not effective.

Comments are closed.