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