Transit in the Baltimore-Washington D.C. metropolitan area is complex. More than a dozen agencies serve the region, with overlapping service areas, conflicting stop numbering schemes, and uncoordinated schedules.
For transit riders, it can be difficult to piece together intermodal journeys across the region because the information simply isn’t readily available. You can board an OmniLink bus in Quantico, Virginia, and – solely by transferring to other transit services with a SmarTrip card – travel all the way to Hunt Valley, Maryland, 75 miles away. Yet there’s no single source of information that would allow a transit passenger to get route and schedule information for all of the agencies they would encounter during that trip. Every transit agency maintains its own web presence, publishes its own maps and schedules, and puts up its own signs at bus stops.
While there is some regional integration, it’s sorely lacking. For example, WMATA publishes regional bus maps that show regional and local services. But they overwhelm would-be transit riders with a maze of routes. The maps are published as hard-to-navigate PDF files, and they make it needlessly difficult to answer questions like “where can the bus take me right now?”
Some of the region’s transit agencies share their data with Google Transit, while others provide only minimal schedule information online. Some agencies provide real-time passenger information, while others still lack the necessary infrastructure.
We can’t solve all of the region’s transit problems, but we can help improve the quality and quantity of regionally integrated passenger information.
This involves two major steps: first, preparing the underlying data, and second, launching a regionally integrated transit data portal.
Three of the region’s most forward-thinking transit authorities, ART, Montgomery County Ride On, and Virginia Railway Express (VRE), provide route and schedule data electronically in the General Transit Feed Specification (or GTFS) format, and provide real-time data in the GTFS-realtime format. These are both open standards which allow developers to build tools that are not specific to any city, any transit system, or any vendor. Leveraging standards like GTFS and GTFS-realtime makes it considerably easier for developers to deploy world-class transit technology.
Other regional agencies, including WMATA and DC Circulator, provide route and schedule data using GTFS, but provide real-time data using one or more proprietary formats. These proprietary formats vary in quality and the level of data provided, and some are not suitable for the most advanced applications, such as real-time trip planning.
Many regional agencies have not yet installed the necessary infrastructure to provide real-time data to their passengers, but they do provide their route and schedule data in the GTFS format. These agencies should be commended for their effort, but at the same time reminded of the considerable and proven benefits of real-time passenger information.
Finally, a number of regional agencies provide no open data whatsoever. They may make their schedules available to passengers on their websites as PDF downloads, or similar formats, but without data being provided in open, industry-standard formats, true regional transit data integration is impossible.
So, the first step is to elevate every transit agency in the region to that first group – those agencies that use open standards like GTFS and GTFS-realtime to provide their schedules and real-time data. For those agencies that anticipate significant difficulties in providing real-time data, work can still be done to release their static route and schedule data in open formats.
In addition, among the agencies that have already released their data in open formats, there are still significant data-quality hurdles to overcome. In many cases, agencies’ GTFS feeds are exported from internal planning databases that were never meant to see the light of day – they contain anomalies such as bus stops and routes used solely for testing and information that is out of sync with paper schedules. All of these problems must be resolved in order to produce a high-quality data source that transit riders and software developers can trust.
Once the data have been assembled, then we can go about building a regional portal that will allow transit riders to get real-time information, learn about routes and schedules, and plan trips using real-time information. This will allow trip planning to account for transit disruptions as they happen, and offer options like bike sharing using live availability data. To do this, we’ll use the open-source OneBusAway and OpenTripPlanner, best-in-class software packages that are at the heart of projects like MTA Bus Time and TriMet’s regional, intermodal trip planner. Because they’re open source, we’ll be free to modify them to suit our region’s needs, and we won’t get stuck paying licensing fees to a big, unresponsive vendor.
Not only will this provide desktop web and mobile interfaces for transit passengers, but it will also provide app developers with a single source of truth for every transit option in the region. Instead of having to source data from a dozen agencies and several different real-time formats, app developers bringing their transit innovations to the region will be able to benefit from some of the most advanced transit data infrastructure in the country.
Some might ask why we don’t just turn the data over to Google. Aside from the fact that some people genuinely prefer Bing, there are some good reasons for us to build a transit data portal of our own, even if it seems like that’s what Google Maps already does.
First, the reality is that this project will result in data that is cleaner than ever before being submitted for inclusion in Google Transit, including real-time data. The transit data infrastructure proposed here is a key step in making it easier for local agencies to get their data to Google.
In addition, Google Transit is a closed platform. Developers can’t get access to the data in Google Transit to use it as the basis for their apps; transit agencies that want to innovate can’t use Google Transit as the basis for their inventions. By contrast, OneBusAway and OpenTripPlanner are fully open platforms which serve as a launchpad for transit technology innovation. If a regional transit agency wants to experiment with an improvement in trip planning, or a better way to present real-time data, they’ll be able to do that.
Similarly, some may ask why we don’t just encourage all of the region’s agencies to use NextBus. It’s true, you can go to nextbus.com with any modern mobile phone and get a snazzy interface which tells you when the next bus is coming. But the reality is that NextBus is a subscription service, a closed platform with data interfaces that are not standards-compliant and that complicate life for app developers who seek to develop the most advanced transit applications. We don’t want to force transit agencies to use any particular vendor or service – by contrast, all we ask the region’s transit agencies for is data in open formats and using open standards.
You might also wonder about your favorite smartphone transit app: if they’ve got the schedules you’re looking for already, then why do we need all this infrastructure? The reality is that some of those app developers have had to do a lot of manual data scrubbing in order to bring their apps to this region, while others have given up entirely. We’re not looking to put app developers out of business – in fact, just the opposite. We’re looking to provide app developers with the cleanest-possible data, using industry-standard open formats, so that they can take the same apps they’ve built for forward-thinking cities like Portland and New York, and bring them here, plug in our local data, and launch without having to rebuild parts of their app or manually scrub data.
We can make transit in this region easier to use. But to do that, we’re going to need to make it easier for people to learn about the transit services around them, plan trips, and get updates on-the-go. We can do this without getting locked in to costly proprietary software, without tying our region to any one vendor’s solution. To make that a reality, we’ve got to start by cleaning up and harmonizing transit data from agencies across the region, and offering the necessary technical assistance to those agencies whose open-data efforts lag behind. Only then can transit data innovators begin to bring world-class solutions to the region.
Photos by Frans de Wit, Isuru Senevi, and Jason V