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.