Bringing OpenTripPlanner and OneBusAway to DC to improve rider experience

I want to bring OpenTripPlanner and OneBusAway to DC. Why? Simply put, because they’re a lot better than what we’ve got now.

WMATA’s trip planner has no API for developers, returns illogical and nonsensical results for some trips (which can be due in part to data quality problems), is based on a costly, proprietary product, and has a clunky, outdated-looking interface. As for leading-edge features like real-time and intermodal trip planning (including bicycling and bike sharing)? Dream on.

In addition to basic trip planning, OpenTripPlanner includes an interactive system map that makes it easy for riders to explore the transit system and learn about services near them. The closest we have to that here is a series of three large, difficult-to-use PDF maps published by WMATA.

OpenTripPlanner presently integrates with GTFS-realtime to display service alerts alongside planned trips, and will eventually support real-time trip planning—that is, providing trip plans based on the service that is actually operating, as opposed to what is scheduled. When riders access a trip planner from a mobile device, as they’re traveling, this provides a real advantage. Nobody likes being told to board a bus that just isn’t there.

OpenTripPlanner also supports intermodal trip planning for trips which combine transit and bicycling (see TriMet’s new regional trip planner here, and select “Transit & Bicycle” from the “Travel by” menu). In fact, OpenTripPlanner can even use data from bike sharing systems like Capital Bikeshare, integrating real-time bicycle availability data into the planned trip.

The case for bringing OneBusAway to DC is even stronger than the case for OpenTripPlanner. While we already have a regional trip planner, we have no regionally-integrated real-time data of any sort. Why does this matter?

As more agencies launch real-time passenger information systems, the last thing we need is for them to launch yet another proprietary product, incompatible with everything else in the region. I can imagine a (dystopian) future in which truly connected passengers have a half-dozen transit apps on their smartphones: one for WMATA, one for DC Circulator, one for ART, one for Ride On, one for Fairfax Connector (if it ever gets out of the Dark Ages), and so on.

You can stand on a street corner in Rosslyn and watch WMATA, ART, and Circulator buses come and go…but if you want to know when they’re coming, you’ll have to visit three different Web sites.

There’s no reason for it to be like this. We can, and should, provide a regionally-integrated real-time passenger information system. Passengers should be able to enter a stop number, or use their smartphone’s GPS, and see departure information for every transit authority that services that stop or station. Instead of spending considerable sums on custom-integrated real-time signs, we could instead use OneBusAway’s built-in sign mode; just add the hardware and you’re set.

This will be a considerably more difficult task, as only a few agencies in the region offer any sort of real-time data. There’s only one GTFS-realtime feed among them, and while some of the other APIs can be transformed to GTFS-realtime with some difficulty, others look hopeless. Worse, while WMATA long ago defined a regional bus stop numbering scheme, they’re the only one to use it. Where ART and Ride On stops are co-located with WMATA stops, the agencies use different stop numbers.

I’ve done some experimental work in generating a GTFS-realtime feed with TripUpdate, VehiclePosition, and Alert messages from WMATA’s APIs for bus data, but so far I am not particularly satisfied with the results (although, on a basic level, it works).

It has been exceedingly difficult to convince transit authorities in this region of the benefits of open transit data, and, more importantly, even harder to convince them to properly maintain their data. I would hope that being able to provide them with a concrete project with real, tangible benefits for riders—such as deploying OpenTripPlanner and OneBusAway—would give them a greater incentive to take open data seriously. Some of the transit authorities in the region who’ve yet to deploy an AVL solution may even be moved to adopt OneBusAway (using the location inference code developed for MTA New York City Transit’s Bus Time project) as their AVL system backend, rather than just a frontend to an existing AVL system (such as Orbital’s OrbCAD). For New York City Transit, doing so meant a cost savings of 70 percent compared to proprietary alternatives.

Yet even if area transit authorities steadfastly refuse to adopt modern software solutions, so long as they release open data in industry-standard formats, independent developers can still provide value for transit riders by setting up instances of software like OpenTripPlanner and OneBusAway—and that’s precisely what I’d like to do.

2 thoughts on “Bringing OpenTripPlanner and OneBusAway to DC to improve rider experience”

  1. I couldn’t agree with you more Kurt. I’ve read about the lack of an active developer contact at Metro to provide feedback on the data they provide and ways to improve the data as well as provide new data such as GTFS-realtime feeds for trip updates, vehicle locations, and service alerts. Since the greater Washington area is an interconnected region, it seems as though the connections only exist on paper and in reality, there is a juxtaposition in theory of truly integrating transit. I like how the Seattle area was quick to adopt OneBusAway as their real-time information system in linking all of the regions transit systems that provide open data for scheduling and real-time information feeds into a single program that can provide estimates for all the agencies in the area from one single site. That model can work here only if the local governments, boards, and transit agencies could pull together and listen to the riding public and developer community in improving transportation in the region together than just being shut out and in the dark. The dystopian future you referred to before seems to be what the DC area is going towards as there is no standard API to gather information from all of the area’s transit systems. I’ve seen a Powerpoint presentation from ITS VA about bringing GTFS, GTFS-RT, and SIRI to Virginia and having a common portal for this data in both schedule and real-time formats:Real-time Information. It has some potential, but with the lack of engagement with the public, it’s just another idea that will go wasted in Washington. I’d love to see OpenTripPlanner implemented in the region because I can see a huge demand for such a system plus it would be a great alternative to WMATA’s trip planner (which still lacks a mapping element to this day). OneBusAway would eliminate the need to visit 4 different sites to get real-time information for the same stop and also can be a great alternative to more expensive information system options (i.e sign infrastructure, maintenance costs, data flow, etc), and it will give another boost for the use of open-source software to provide beneficial information for the thousands of riders who use Metro, Ride On, Fairfax Connector, etc on a daily basis.

  2. Ken,

    I really appreciate the words of support—one of the effects of the absence of a transit developer community in the DC area is that there’s no group to use as a sounding board for ideas or to collaborate with. It seems like the Mobility Lab was intended to fill that role, but in roughly a year it seems like that hasn’t happened.

    It will be very difficult to change attitudes around here (as it has been over the past two years) but I hope this is the first step towards creating an environment in which transit is taken seriously instead of being seen as a cruel joke.

Comments are closed.