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.

Journey history as open data, and cooperation with developers

Last April, I blogged about Chromaroma and its use of Oyster journey data from Transport for London. Since then, I’ve continued to hold up Chromaroma as one of the best examples of what can be done with journey data, in spite of a lack of cooperation from the transit authority.

When I first covered Chromaroma, I pointed out that they were screen-scraping the Transport for London site in order to retrieve Oyster journey histories, and I discussed some potential options for avoiding what is an inherently inelegant process, including the use of OAuth for authentication, and the definition of a common format for journey history data interchange.

Now that I’ve proposed the development of a system based on journey data, I’d like to revisit how Chromaroma has been doing.
Continue reading Journey history as open data, and cooperation with developers

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?

A tale of two cities

Visit http://test.rideonbus.com/, and try to find out when the next bus will arrive at a stop. Is it easy? Is the interface clean, modern, and easy-to-use? Try out the mobile site, too—and on a variety of mobile devices, including the latest tablets. If you don’t know where you are, does the mobile site use geolocation technologies to find the nearest stops? Look around the site; is there an API for developers? Is the system built around the use of open standards?

Then start asking the hard questions. How much did the system cost (keeping in mind that the AVL infrastructure was already in place)? What was the implementation time? Is the system based on open-source software, allowing MCDOT to make in-house modifications without paying for change orders, or are they tied to a proprietary package, bound to pay for change order after change order?

Now visit http://bustime.mta.info/. Do the same tests, and ask the same questions. Consider that, unlike MCDOT, MTA NYCT had no pre-existing AVL infrastructure to leverage.

Is there an open API? Oh, yes, there is. It leverages open standards, too; the software you write for the BusTime feed can be made to work in other cities that support the SIRI standard.

The underlying software? Yes, it’s open source. There’s nothing about the BusTime deployment that ties MTA NYCT to a particular technology or service provider.

Now tell me which city got a raw deal.

Continue reading A tale of two cities

Transit mobile payment roundup

This is almost a month behind, but there were two fairly quiet announcements in October on transit payment integration with mobile phones:

  • NJ Transit and Google have announced a partnership to accept Google Wallet for fare payment as part of NJ Transit’s ongoing open payment program. Riders will be able to use their Nexus S phones with the Google Wallet app just like they would use a contactless credit or debit card to pay their fare on select NJ Transit bus routes and AirTrain Newark.
  • Nokia and MTA Long Island Rail Road have announced a very limited pilot in which 20 LIRR employees will use Nokia NFC-enabled phones. It’s not clear if this actually involves open payment; as it’s described, the employees in the pilot will tap their phones on NFC tags when boarding and disembarking, but no fares will actually be charged, at least in the first phase of the pilot. After this initial phase, the trial will be opened up to riders on the Port Washington Branch, the LIRR’s shortest line. But even then, the implementation won’t be quite as convenient as installing the Google Wallet app and getting on board; the article mentions “riders’ preregistered pay-as-you-go accounts or weekly or monthly passes”. This is an important contrast with the NJ Transit trial: once a rider loads the Google Wallet app, they don’t need to register separately to use the app to pay their NJ Transit fare.

The interesting point about the NJ Transit trial is that it’s based around existing standards for contactless payment; there’s nothing particularly specific to Google or NJ Transit happening here. All the Google Wallet software does is emulate a contactless credit or debit card; this is unlike using an NFC-enabled mobile phone to emulate a closed-loop card like SmartLink, SmarTrip, or Oyster.

This is, after all, what open payment is all about: paying for transit should be just like paying for groceries. The transaction that takes place when a Nexus S user taps their phone to the faregate at the Newark Airport AirTrain station is more or less identical to the transaction which takes place when I use my contactless American Express card to pay at the grocery store. This use of open standards reduces implementation time and cost; rather than developing NFC-enabled apps for many transit authorities, all phone makers have to do is support contactless payment by emulating a contactless card, and they’re set.

It’s less clear how the MTA LIRR trial is intended to work; there are very few details available, but it doesn’t seem to be an open payment trial in the conventional sense. It seems as though rather than installing active equipment at stations (which would require power and data connectivity), the LIRR would rather install passive tags at stations, and use the phone to read the tag and send the transaction data to a central server for processing. Of course, whereas riders on NJ Transit who have any contactless card or payment device can use it to pay, on the LIRR riders would have to have a supported NFC-enabled phone. Then again, mounting a few passive tags is a lot less expensive than installing platform validators and providing power and data connectivity at all 124 stations on the LIRR.