OneBusAway might be coming to Ride On, maybe?

Today on GitHub I came across this commit. I don’t quite know what’s going on, but it sure looks to me like someone at Greenhorne & O’Mara or Ride On has been experimenting with OneBusAway and Ride On’s data.

This is something in which I am keenly interested. But unlike in other cities, here there seems to be almost no interest in connecting transit agencies with each other and with local developers. There’s great value in doing both—connecting transit agencies together helps reduce duplicated effort and provide riders with harmonized, federated services. But even more importantly, connecting transit agencies with interested developers can provide transit riders with services that might have been cost-prohibitive or otherwise infeasible to for those agencies to develop in-house or through conventional procurement methods.

There are a lot of innovative developers out there, with lots of great ideas. It’s unreasonable to expect transit authorities to shoulder the risk of incubating all of those ideas, some of which might fail spectacularly, but it’s quite another thing for transit authorities to, on a best-effort basis, provide those developers with the data they need to bring their ideas to fruition.

I’d have thought that this would fall within the remit of the Mobility Lab, but more than a year after the launch of the Mobility Lab, that still hasn’t happened.

So, while there’s plenty going on, there’s not a whole lot of coordination, whether between agencies or between agencies and the community. Thus we have nearly a half-dozen real-time sign projects going on in the region—and who knows how much more duplicated work is being done, with everyone toiling behind closed doors!

Contrast that to New York City, where the MTA has been working—transparently—to develop MTA Bus Time, based on OneBusAway. When the agency began work on a GTFS-realtime feed for real-time subway arrivals from the IRT ATS system, once again, they turned to the community to get comments on the proposed specification. MTA developers are active on the agency’s mailing list to respond to questions and bug reports from developers.

In Portland, TriMet worked with OpenPlans to develop OpenTripPlanner, transparently, in full view of the community. OpenTripPlanner has proven to be a huge success, powering an first-of-its-kind regional, intermodal trip planner

Transit in the Washington, D.C. area isn’t all that different than in Portland or New York. Sure, the modes vary from city to city, and the Lexington Avenue Line by itself carries more passengers in one day than the Metrorail and Metrobus systems combined, but at its core, transit is transit. If it worked in New York, if it worked in Portland, it can work here.

This doesn’t have to be hard; in all seriousness, it takes about a minute to create a new Google Group.

When everyone works together, we can all help make transit better.

An object lesson in developer relations

Last week, I posted about some issues with Montgomery County Ride On’s new API.

A few days ago, I tried to re-start my test OneBusAway instance, including the translator I’d written to generate a proper GTFS-realtime feed for Ride On. To my surprise, I found that something had changed with the Ride On API, and my translator no longer worked properly. When I investigated, I found that the API endpoint for GTFS-realtime now correctly returned the binary Protocol Buffers format, one of the issues I’d mentioned in my earlier post.

So, I decided to review the API documentation and see what had happened. Since G&O (the contractor that built the system for Montgomery County) keeps the API documentation in a MediaWiki wiki, we can look at the recent changes quite easily.

Aside from a bit of Wiki-spam, we see a flurry of activity on May 22 and 23, documenting the following changes:

  • Release of source code: The code which powers the Ride On API has been released as open source, under the GPLv3.
  • Documentation on use of access token: As documented here, the supplied access token is intended to be included in API calls as the auth_token parameter.
  • GTFS-realtime endpoint fixed: Perhaps most importantly, the GTFS-realtime endpoint now offers a choice between the binary Protocol Buffers format (the default), and the text-based debugging output. As a result, the feed can now be used out-of-the-box with GTFS-realtime tools.

I am, of course, glad to see that these changes have been made. But where was the developer outreach? I’ve written before about the vital role that effective developer outreach plays in the success of open transit data initiatives, and this is a perfect example.

A quick email to a developer mailing list outlining the changes that had been made would have kept developers in the loop. More importantly, a developer mailing list also provides an excellent feedback mechanism, allowing developers to share their observations in working with the API, and distinguish genuine problems from transient failures or problems with their own code.

For example, right now it seems like the latitude and longitude in vehicle positions are being transposed. This appears to affect both the vehicle_positions and gtfs_realtime API methods, so I suspect it’s an issue with the underlying data, rather than any particular API method, or the clients I’m using.

It’s not clear how best to report this issue, so I’m blogging about it. It’s probably a quick fix—in working with geodata I’ve certainly transposed latitude and longitude fields many times before—but it is still something that needs to be examined. Better developer outreach would make it easier for developers to report these types of issues and get updates on their resolution.

Having said all of that, in case I’ve not adequately emphasized this point, let me be perfectly clear: in the span of a few months, Ride On has gone from providing no real-time data to providing some of the best real-time data in the region. Ride On currently has the only standards-compliant real-time feed in the region, and the only one that properly correlates static and real-time data, by using the same trip IDs across the GTFS schedule data and the GTFS-realtime feed. When it comes to providing data that can be used with existing passenger information systems, trip planners, and other tools, this is huge.

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.

A tale of two cities

Visit, and try to find out when the next bus will arrive at a stop. Is it easy? Is the interface clean, modern, and easy-to-use? Try out the mobile site, too—and on a variety of mobile devices, including the latest tablets. If you don’t know where you are, does the mobile site use geolocation technologies to find the nearest stops? Look around the site; is there an API for developers? Is the system built around the use of open standards?

Then start asking the hard questions. How much did the system cost (keeping in mind that the AVL infrastructure was already in place)? What was the implementation time? Is the system based on open-source software, allowing MCDOT to make in-house modifications without paying for change orders, or are they tied to a proprietary package, bound to pay for change order after change order?

Now visit Do the same tests, and ask the same questions. Consider that, unlike MCDOT, MTA NYCT had no pre-existing AVL infrastructure to leverage.

Is there an open API? Oh, yes, there is. It leverages open standards, too; the software you write for the BusTime feed can be made to work in other cities that support the SIRI standard.

The underlying software? Yes, it’s open source. There’s nothing about the BusTime deployment that ties MTA NYCT to a particular technology or service provider.

Now tell me which city got a raw deal.

Continue reading A tale of two cities

Montgomery County Ride On gets it wrong on real-time data

On Friday, Greater Greater Washington broke the news that Ride-On’s real-time passenger information system had at long last gone live. There doesn’t seem to have been an official announcement, and the information on the Ride-On site is scant at best. So, what’s going on?

The new service, apparently branded “Ride-OnTIMe” (who comes up with these names?), is driven by ACS SmartTraveler Plus. (Orbital, original creator of the product, was absorbed into ACS a while back, and more recently ACS was absorbed into Xerox; the result of this is that there’s very little information on Orbital’s products left on the Web.)

The scope of the project is actually quite narrow; Montgomery County has had the ability to track its buses for over a decade. According to this presentation to the MWCOG in 2010, deployment of an AVL system began in 1996 and was complete by the year 2000. From that point forward, bus dispatchers and other staff members had access to real-time bus position information.

What Ride-OnTIMe adds is the ability for the public to have direct access to that information, including bus arrival predictions, through a Web site and SMS services.

Continue reading Montgomery County Ride On gets it wrong on real-time data