Regional mobility is no pipe dream

Robert Smith, former WMATA Board chair, calls WMATA’s proposed loop line a “distracting pipe dream”. For context, Smith was appointed by former Maryland Governor Bob Ehrlich in 2003, then fired in 2006 after making anti-gay remarks.

Smith assails WMATA’s proposal as being in “the realm of fantasy”. In reality, it’s anything but. Every recent analysis of the Metrorail network has highlighted the immense congestion and overcrowding in the core. Far from serving only the core, the proposed loop line connects key transit hubs, enhancing mobility in and out of the core, relieving some of the pressure on the system’s most heavily-congested stations (like Gallery Place).

Yet Smith continues his assault on sensible planning:

What possible benefit of this project would inure to the people of Maryland, particularly those who dwell beyond Montgomery and Prince George’s counties? While they would be spared the capital construction cost, the state would still be zapped with an increase in operating costs into eternity for the privilege of watching more of its residents spend entertainment dollars in the District.

This is reflective of the sort of small-minded thinking that advocates like Richard Layman rail against. When politicians think only of their county or their state, they ignore the fact that we are one region made up of cities and counties from two states, plus the federal city. We succeed together, or we fail together.

Practically speaking, though, what do Marylanders get out of the loop line? For the many Marylanders who commute through the core—whether they enter by MARC, commuter bus, or the Red or Green Lines, the loop line will ease congestion and provide connectivity to destinations in DC which presently have no rail service. Sound transit planning isn’t about politics; it’s about hard data. It may be hard for the suburbs to stomach, but solving Metrorail’s problems—including the problems suburban commuters experience—means increasing core capacity.

Smith’s true colors come out with his next complaint:

Even now, many Montgomery County riders suffer the indignity of being tossed from every other homebound train at Grosvenor-Strathmore station during rush hour, thanks to Metro’s lack of enough dollars — and a supportive vote from the District — to fund the full ride out to Shady Grove.

It seems as though in Smith’s world, Metro exists for the sole purpose of shuttling suburban commuters to and from far-flung park-and-rides. Looking at WMATA’s ridership statistics, though, we can see that that’s just not true. If Smith believes so strongly that the stations between Grosvenor-Strathmore and Shady Grove need the added service, then he should call on the State of Maryland and Montgomery County to fund the service. As a reimbursable project, the other jurisdictions wouldn’t have to contribute—though their Board members would have to vote to approve the service.

Smith describes Metrorail as “[lacking] the engineering simplicity to do the basic job of getting people where they want to go”. It’s true that today’s Metrorail is clearly collapsing under the strain. But that doesn’t signify any underlying engineering failure; rather, it’s the result of years of deferred maintenance, and a failure to plan and build new capacity to accommodate shifts in the region’s population. What WMATA intends to build by 2040 should have been built years ago. Had this been done, there’d be less pressure on the oldest parts of the network, reducing the pain of the sometimes-lengthy maintenance outages necessary to keep this aging rail system running.

So, what should we build? In his article, Smith says we should “build a line that effectively paralleled the Beltway and circled the city”. The Beltway Line isn’t a new concept; it’s something people have been pushing for years. But it’s an idea born out of auto-centric thinking. The fact that people spend hours every day in the parking lot that is the Beltway doesn’t mean that’s where they’re actually trying to go. We need to focus on moving people, not cars, and that means connecting activity centers, not just following existing paths of congestion and sprawl. This is more than just a gut instinct; WMATA has tested plans for a Beltway Line, and found that “[only] the segments that crossed the American Legion Bridge (between White Flint and Dunn Loring) and the Woodrow Wilson Bridge (between Branch Avenue and Eisenhower Avenue) had some promise”.

Smith closes by calling our region a “transportation basket case that needs to focus on reality”. That’s true, but without an increase in capacity it’s only going to get worse. Arguing that we shouldn’t build anything new because it’s too expensive, too unpalatable for the suburban parts of our region, or because WMATA already has operational problems will only prolong the pain.

Building Momentum with open data, open source, and open architecture

Max Gano, a Solution Architect with Sound Transit Research and Technology, describes his work in transit technology with the following catchphrase: “open data + open source + open architecture”.

WMATA’s ambitious new strategic plan, Momentum, includes a number of technology-related goals. How can the principles of open data, open source, and open architecture help us build Momentum?

As part of Momentum’s goal to “[m]eet or exceed customer expectations by consistently Delivering Quality Service”, WMATA seeks to “[m]ake it easy and intuitive to plan, pay, and ride”, with specific ‘strategic actions’ including to “[p]rovide readily-understandable and useful real-time information in stations, stops, and on vehicles” and “[p]rovide transit riders with a regional trip planning system that works for all systems and provides real-time information in vehicles, in stations, at bus stops, and on any device”.

These are high-level strategic goals, not detailed technical specifications, but the intent is still clear. Now, how do we achieve those goals? If past experience is any indication, they’ll be achieved by handing the contract off to a big-name vendor who will extract a significant sum from WMATA to deliver one of the major off-the-shelf transit passenger information systems; the project will probably come in late and over-budget, and when it’s done there probably still won’t be a usable API for developers.

This isn’t just an opportunity to take pot shots at government IT contractors; it’s a scenario which has played itself out over and over again. One of the latest and most visible examples has been—and while many of the criticisms leveled at the site unfairly neglect to account for the complexity mandated by the Affordable Care Act itself, the reality is that what was built could have been built better, faster, and cheaper. Take The Health Sherpa, for example. Using the same data which powers, they’ve built a bare-bones plan finder which (gasp!) actually works! Now, Health Sherpa doesn’t handle the enrollment side of the transaction, one of the largest pain points to date—but it still demonstrates that you can provide core functionality with a better, faster, cheaper alternative.

It’s the same way with transit data. Using proven open-source packages like OneBusAway and OpenTripPlanner, we can advance WMATA’s strategic goals, and we can advance them without the cost, delay, and dysfunction traditionally associated with government IT procurement. With open data, open source, and open architecture, we can deliver a cutting-edge product, while saving money and putting a better product in riders’ hands faster.

But to do this, we need the region’s transit authorities to fully embrace open data and open system architectures. Breaking free from the cost, inflexibility, and data silos traditionally associated with transit passenger information systems means fully considering open-source products alongside their proprietary counterparts, and demanding that agencies work with and alongside—not against—open-source developer communities, both locally and across cyberspace. Leveraging open standards like SIRI and GTFS-realtime, publishing high-quality open data, and collaborating with developers to enhance the quality and utility of data products all contribute to a better end product, and, ultimately, help advance the strategic goals which WMATA has outlined in Momentum.

With OneBusAway and OpenTripPlanner we already have the technology to deliver much of what WMATA seeks as part of Momentum. Are we completely there? No. Both of these projects are works in progress, with contributions coming in on a daily basis from a global community of software developers. But in terms of core features, OpenTripPlanner is already an outstanding package for trip planning (having proven itself in Portland), including real-time routing for transit and bike sharing systems, and OneBusAway provides a level of transit data integration yet unmatched in the region, as the Mobility Lab’s pilot shows. As these packages mature (including via support from forward-thinking transit agencies) the advancements benefit transit riders around the world, in every city where they’ve been deployed.

By using open-source software, agencies are no longer tied to a single vendor for service, support, and new features. No longer are they tied to costly service contracts, exorbitantly-priced change orders, or business-driven mandates to upgrade to a vendor’s latest-and-greatest (more expensive) product. Instead, agencies can hire their own staff developers, or contract with the vendor of their choice to build new features, maintain the system, and advance their strategic goals.

Similarly, because these tools are built around open infrastructure, there’s nothing stopping an agency from swapping out components of these systems with other alternatives built around the same data standards. Silos are non-existent in an open-architecture world. There’s no vendor lock-in, no fear of proprietary data formats, and no risk in experimenting with alternative tools.

Taking these tools from hundreds of thousands of lines of code on a server (or even just a conceptual plan) to a polished, production-ready service is a different kind of task than just writing a check to a vendor and walking away, but it’s hardly an insurmountable challenge—New York’s MTA has experienced extraordinary success in developing Bus Time on top of OneBusAway, saving money and delivering more features faster than proprietary alternatives. Along the way they’ve collaborated with the global developer community—this interactive list of routes was built not by the system integrator responsible for the Bus Time project, not by an MTA staff developer, but a member of the global developer community (yours truly, in fact).

Simply put, the model works, and the benefits are considerable. Can our region’s transit agencies overcome their technophobia and intransigence in time to avoid a disaster?

GTFS-realtime for WMATA buses

I’ve posted many times about the considerable value of open standards for real-time transit data. While it’s always best if a transit authority offers its own feeds using open standards like GTFS-realtime or SIRI, converting available real-time data from a proprietary API into an open format still gets the job done. After a few months of kicking the problem around, I’ve finally written a tool to produce GTFS-realtime StopTimeUpdate, VehiclePosition, and Alert messages for Metrobus, as well as GTFS-realtime Alert messages for Metrorail.

The tool, wmata-gtfsrealtime, isn’t nearly as straightforward as it might be, because while the WMATA API appears to provide all of the information you’d need to create a GTFS-realtime feed, you’ll quickly discover that the route, stop, and trip identifiers returned by the API bear no relation to those used in WMATA’s GTFS feed.

One of the basic tenets of GTFS-realtime is that it is designed to directly integrate with GTFS, and for that reason identifiers must be shared across GTFS and GTFS-realtime feeds.

In WMATA’s case, this means that it is necessary to first map routes in the API to their counterparts in the GTFS feed, and then, for each vehicle, map its trip to the corresponding trip in the GTFS feed. This is done by querying a OneBusAway TransitDataService (via Hessian remoting) for active trips for the mapped route, then finding the active trip which most closely matches the vehicle’s trip.

Matching is done by constructing a metric space in which the distance between a stoptime in the API data and its counterpart in the GTFS feed is defined as an (x, y, t) tuple—that is, our notion of “distance” becomes distance in both space and time. The distances fed into the metric are actually halved, in order to bias the scores towards matching based on time, while allowing some leeway for stops which are wrongly located in either the GTFS or real-time data.

The resulting algorithm will map all but one or two of the 900-odd vehicles on the road during peak hours. Spot-checking arrivals for stops in OneBusAway against arrivals for the same stop in NextBus shows relatively good agreement; of course, considering that NextBus is a “black box”, unexplained variances in NextBus arrival times are to be expected.

You may wonder why we can’t provide better data for Metrorail; the answer is simple: the API is deficient. As I’ve previously discussed, the rail API only provides the same data you get from looking at the PIDS in stations. Unfortunately, that’s not what we need to produce a GTFS-realtime feed. At a minimum, we would need to be able to get a list of all revenue trains in the system, including their current schedule deviation, and a trip ID which would either match a trip ID in the GTFS feed, or be something we could easily map to a trip ID in the GTFS feed.

This isn’t how it’s supposed to be. Look at this diagram, then, for a reality check, look at this one (both are from a presentation by Jamey Harvey, WMATA’s former Enterprise Architect). WMATA’s data management practices are, to say the least, sorely lacking. For most data, there’s no single source of truth. The problem is particularly acute for bus stops; one database might have the stop in one location and identified with one ID, while another database might have the same physical stop identified with a different number, and coordinates that place it in an entirely different location.

Better data management practices would make it easier for developers to develop innovative applications which increase the usability of transit services, and, ultimately improve mobility for the entire region. Isn’t that what it’s supposed to be about, at the end of the day?

Wireless for WMATA: what’s at stake?

Since late 2008, the Washington Metropolitan Area Transit Authority has been working to deliver modern wireless service throughout the underground portions of the Metrorail system. Unlike some mass transit systems, however, WMATA did not undertake this project simply out of a desire to improve passenger experience; they did so because of a few short sentences in the Passenger Rail Investment and Improvement Act of 2008 (hereinafter PRIIA), enacted on October 16, 2008:

No amounts may be provided to the Transit Authority pursuant to the authorization under this section unless the Transit Authority ensures that customers of the rail service of the Transit Authority have access within the rail system to services provided by any licensed wireless provider that notifies the Transit Authority (in accordance with such procedures as the Transit Authority may adopt) of its intent to offer service to the public, in accordance with the following timetable:
(A) Not later than 1 year after the date of the enactment of this Act, in the 20 underground rail station platforms with the highest volume of passenger traffic.
(B) Not later than 4 years after such date, throughout the rail system.

WMATA met the first deadline, turning up a new distributed antenna system and signing on the four major carriers (AT&T, Sprint, T-Mobile, and Verizon). But the second deadline has proved thornier. A recent Washington Examiner article described the contractor installing the system as being in “dire financial straits”. Anecdotal reports from riders have shown that cellular service has been spotty, even at stations which initially had good coverage.

With October 16 just over a month away, you might think that WMATA would be forthcoming with status updates. Unfortunately, WMATA has responded to the situation with its usual opacity:

So, what does WMATA stand to lose if they miss the deadline? As PRIIA states, “[no] amounts may be provided…”, and the amounts authorized under the Act are considerable:

There are authorized to be appropriated to the Secretary of Transportation for grants under this section an aggregate amount not to exceed $1,500,000,000 to be available in increments over 10 fiscal years beginning in fiscal year 2009, or until expended.

Clearly, this is not a deadline that WMATA should take lightly.

The Massachusetts Bay Transportation Authority, like WMATA, is in the midst of wiring its rail system for wireless service, and they, too, have experienced delays. However, they’ve been more upfront about the situation; an article published earlier this year distinguished between delays attributable to the MBTA’s contractor and those attributable to the cellular carriers.

Even if WMATA and their contractor manage to pull through and meet PRIIA’s October 16 deadline, there are still best practices they can and should adopt. In New York City, the contractor deploying wireless service on the subway, aptly named Transit Wireless, has established their own presence, rather than lurking in the shadows like the contractors deploying systems in DC and Boston. Through their Web site and Twitter account, Transit Wireless reaches out directly to riders, taking questions and helping them understand what services are available, and where.

By contrast, WMATA refers questions to the carriers, who tend to either deny knowledge of service in the Metro, or refer questions back to WMATA. After WMATA’s initial announcement of service at underground stations, updates have been spotty at best—and there’s no list of covered stations or timetable for future service rollouts.

Statement to the June 2012 WMATA RAC meeting

Earlier this evening, I delivered the following statement to the WMATA Riders’ Advisory Council during the public comment period of its June 2012 meeting:

As I hope you are aware, last week the NTSB released three reports into incidents on the Metrorail system, one of which resulted in the deaths of track workers Jeff Garrard and Sung Oh. I would hope that the RAC would request a presentation from WMATA on steps taken to improve safety in the wake of these accidents. Even more importantly, though, I would hope that the RAC would ask WMATA to publicly release documents to permit independent verification and oversight of the Authority’s claims on safety.

I understand that the RAC is not accustomed to conducting investigations, but for Jeff Garrard, Sung Oh, their colleagues, and the 1.5 million individuals who use Metro ever day, I ask you to consider the vital importance of holding WMATA accountable on such a serious issue as safety.

For reference, the NTSB reports mentioned above are the following:

  • RAB1205 (derailment in Farragut North pocket track)
  • RAB1204 (rear-end collision in West Falls Church yard)
  • RAR1204 (two track workers struck and killed by hi-rail vehicle outside Rockville)