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.

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

WMATA to adopt Clever Devices for bus AVL

Last night, I was looking at a WMATA RFI for “GIS-based Transit Network Management Software” when I came across the following bit (emphasis mine):

Integrating data and providing support across several other enterprise applications, including…automated vehicle location tracking (Orbital, to be migrated to Clever)

That WMATA uses OrbCAD is a well-known fact, but what is new here is that WMATA intends to migrate to Clever Devices’ bus AVL offering. There was an RFP out earlier in the year for electronics upgrades for the Metrobus fleet, and I assume that this is the result of that RFP.

Aside from the fact that this move will result in substantially better tracking for the Metrobus fleet, it will be interesting to see whether WMATA continues to use NextBus to generate and disseminate arrival time predictions, or if they instead choose to use Clever’s own BusTime for that purpose.

I’m not sure if there’s any good reason for WMATA to continue using NextBus after they migrate to Clever for AVL; the split-system approach, with WMATA using one vendor’s technology for AVL and another’s (in this case NextBus) for predictions is somewhat unusual. WMATA must maintain extra infrastructure to send the raw AVL data to NextBus and then use the NextBus API to fetch predictions for internal use and dissemination through the WMATA developer API. With a BusTime server hosted internally, WMATA would have more control over the environment and internal use of the data.

In addition, unlike some competing AVL products, BusTime offers a fairly rich API (the link is to the CTA’s documentation, but the API is the same across BusTime instances). SIRI would be even better, but the Clever API is fine for now.

Plus, BusTime comes out-of-the-box with a fresh, modern-looking interface which agencies can customize with their colors and logos; see the CTA’s installation.

There’s a mobile site, too, and in case you were wondering, no, it does not expect you to know your stop code—in fact, there isn’t even an option to input a stop code. For riders who already know where they are, being able to input the stop code directly saves some work having to first find the route in the list, then select the direction, then select the stop from the list (and for systems with many routes and many stops along each route, those lists can get unwieldy). A good compromise might be to follow the lead taken by OCTO and DC Circulator, and post QR codes at stops which link directly to the predictions for that stop; that lets riders bypass the hierarchy of selections while still avoiding the manual input.

I’m glad to see that WMATA will be adopting Clever’s AVL system; there’s nothing intrinsically wrong with OrbCAD, but its performance here in DC has not been stellar, and for modern applications, frequent and accurate data updates matter. With more frequent data updates, predictions will be more accurate, and applications built on real-time data analysis (like those to detect bus bunching) will be able to generate better results.

WMATA also has a great opportunity to improve the usability of its bus predictions by adopting BusTime; while there’s really nothing wrong with NextBus, BusTime provides a more modern-looking interface, and would allow WMATA to bring prediction generation in-house, thus saving on NextBus service fees.

27 hours on the IRT: visualizing ATS data

Last night, while working on another project, I found that MTA New York City Transit had posted archived A Division ATS data for May 2011. Each file in the archive contains a single service day’s worth of train movements, with events logged each time a train arrives at or departs from a station in area tracked by ATS.

As soon as I saw the data, I knew I wanted to develop some kind of visualization with it; the result is the video above (best viewed large and in high definition). In the video, left-hand half-circles represent southbound trains, while right-hand half-circles represent northbound trains, and the points are colored according to route colors. Each frame represents 30 seconds of real-time data, so one second of video is 900 seconds of data.

The data covers one ‘service day’—in this case, May 31, 2011. Trains which entered service on May 31 and which are still in service after midnight are still considered part of the May 31 service day, so as a result there’s 27 hours of data for May 31. In reality, after midnight, trains scheduled for the June 1 service day would have begun to enter service, so for times after midnight this is not a complete picture of every train in the system.

Continue reading 27 hours on the IRT: visualizing ATS data