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)

An object lesson in developer relations

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 auth_token parameter.
  • 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 vehicle_positions and 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.

WMATA to bidders: don’t innovate with real-time signs

Last week, I asked if WMATA would entertain the idea of using a modern, open-architecture, open source system to power real-time signs at Metrobus stops. Unfortunately, I can now conclusively say that that will not be the case. When I first read the RFP, WMATA had yet to post the complete technical specifications. They’ve now updated the RFP with the complete technical specifications (albeit in an inaccessible, untagged PDF which is itself a scan of a printout).

The specifications state, in part:

Because of the criticality of meeting the firm deadlines, WMATA wants only to procure standard, proven products, from a Vendor with successful existing and fully operational implementations, in multiple transit agencies.

WMATA specifically does not want to assist a Vendor in developing new products for its product line for this RFP.

Furthermore, WMATA wants to select a Vendor that has clearly made a long-term commitment to providing contemporary customer information systems to the transit industry.

So, that’s that. I could go on at great length about how MTA New York City Transit’s success with OneBusAway, and how we could do the same for real-time signs, but I’ve already made that argument.

I’ve long known that WMATA is an agency which is deeply suspicious of change and innovation, and it pains me to see the agency continue to behave in ways that are manifestly counterproductive and which will in all likelihood only deepen the agency’s budget deficit.

Continue reading WMATA to bidders: don’t innovate with real-time signs

No trip = no fare; it’s only fair

On Friday, the Washington Post’s Dr. Gridlock column featured a complaint from a Metrorail rider whose SmarTrip card was charged even though they’d entered and exited at the same station—in fact, they never went anywhere.

The rider entered the system at Foggy Bottom, intending to travel to Friendship Heights. With Metrorail delays mounting, due to both regularly-scheduled track work and a sick passenger, they decided to give up and seek alternate transportation, and that’s when they found that they were charged, even though they hadn’t actually gone anywhere.

Here’s what the Post’s Robert Thompson had to say about the rider’s plight:

For riders to get their money back when they give up in disgust and leave the same station, Metro officials would have to declare that extraordinary circumstances existed and authorize free exits at the affected stations. If free exits were routinely available, it would be easier for fare evaders to cheat the system.

Local bloggers and transit advocates routinely accuse Thompson (and the Post’s other transportation writers) of being shills for WMATA. I’d rather not use such strong language, but this is one case in which Dr. Gridlock should have stuck up for Metro riders.

There’s no need for WMATA to “authorize free exits”, or do anything that would encourage rampant fare evasion. On the contrary, all that is required is a simple change that ensures the fairness of the fare collection system for all: if a passenger enters and exits at the same station within a reasonable period of time, they should not be charged.

Riders should be free to change their mind and exit the system without being charged even if no “extraordinary circumstances” exist. There might be a major disruption, or there might not—either way, if a rider changes their mind, in a reasonable period of time, then let them out without charging them.
Continue reading No trip = no fare; it’s only fair

On WMATA’s RFP for real-time signs

WMATA recently released an RFP for real-time signs for bus passenger information. Since I don’t want to completely bore people with a series of thousand-word posts as I did for WMATA’s New Electronic Payments Program, I decided to package up my earlier tweets about the RFP, along with a few notes, into a post on Storify.

I’ve also embedded the post below:

Continue reading On WMATA’s RFP for real-time signs

Open payment: just how did the New York pilot fare?

Last Thursday, Fast Company published an article which revealed some statistics from MTA New York City Transit’s involvement in the 2010 tri-agency regional open payment pilot. This is the first time the agency has shared statistics from the pilot—and so far, the agency’s partners in the pilot, the Port Authority and NJ Transit, are keeping quiet.

At first glance, the stats look miserable: in such a large and tech-savvy city, how could so few people have used the open payment pilot? But as Fast Company points out, when you look at the released data, there are “few angles that offer apples-to-apples comparisons”. In fact, there’s a lot to keep in mind when considering the pilot’s performance.

The first point to consider—one which Fast Company does a good job of highlighting—is the small scope of the trial, considering the size of New York City’s subway and bus networks. In the subway, the only stations equipped for the pilot were those along the Lexington Avenue Line. While the Lexington Avenue Line may be the system’s busiest, there were still plenty of subway and bus riders left out of the pilot.

Beyond that, the pilot wasn’t just about convincing riders to give up their MetroCards. As the MTA’s Aaron Donovan explained, the point of the trial was not to convert huge numbers of riders to open payment, but simply prove the technology could be made to work in the harsh transit environment of New York City. As Donovan described, the pilot proved the viability of a regionally interoperable system, as well as that the system could be operated securely, and that the equipment would indeed stand up to the physical environment.

The next point to consider is that market penetration for contactless credit and debit cards, along with NFC-enabled mobile phones, is still generally poor. Worse, many associate contactless payment not with convenience and speed, as the industry would prefer, but rather fraud and “hackers stealing your credit card number right through your wallet”. The fraud concerns aren’t entirely unfounded; Kristin Paget’s recent demo has shown that. Logically, the risk of fraud shouldn’t stop people from using contactless payment cards—but who ever said consumers are logical?
Continue reading Open payment: just how did the New York pilot fare?