Real-time transit information, if Google likes your phone

Last week, Google announced the availability of real-time transit information in Google Maps. In the US, they’ve initially made information available from MBTA, San Diego MTS, TriMet, and BART. In my (admittedly brief) testing, the service seemed to work, but the results available from Google Maps did not always match those available directly from the transit agency (this was the case with BART, for example).

You might think that this would be fantastic to have available on-the-go, but as with everything, there’s a catch. The announcement indicates that real-time transit information is available with the “latest version of Google Maps for mobile (requires Android 1.6+), as well as Google Maps on all supported desktop and mobile browsers”. What about iOS, the BlackBerry OS, WebOS, Symbian, MeeGo, or Windows Phone 7? What about older devices? What about feature phones that only have a web browser? What about feature phones that can run J2ME MIDlets?
Continue reading Real-time transit information, if Google likes your phone

Locational privacy in open payment

Locational privacy has long been an issue with automatic fare collection systems; when a system evolves beyond cash and tokens to using a stored-value card, inevitably someone asks a simple question: what happens to the records? Most computerized automatic fare collection systems keep a record of every swipe or tap. These records can make it possible to piece together a picture of a person’s movements, particularly on systems with a zonal or distance-based fare, where data is collected on entry and on exit. When the STM introduced the OPUS card in Montréal, for example, I remember the vehement complaints about privacy, the people complaining that they couldn’t be tracked with a paper ticket, while an OPUS card would contain their entire journey history.

With a conventional stored-value card, an AFC system’s records may be used by the transit agency for operational and planning purposes, and may also be released to law enforcement agencies, upon receipt of a valid court order. There’s also the risk of inadvertent disclosure, such as through an attack on the agency’s systems. For privacy advocates, this risk of information disclosure, whether inadvertent or pursuant to a court order, raises concerns.

How does open payment change the situation? What happens when you throw mobile payment into the mix? Unfortunately, and perhaps predictably, the privacy situation has the potential to get worse. It’s hard to say precisely, with so few open payment systems operational. But we can certainly envision what may happen. There’s a possiblity, depending on how rules for transaction aggregation are established, that card issuers may not see each trip as a discrete transaction. Aggregation has yet to be fully explored by the industry, so for now we’ll assume that each transaction is reported separately. Add a mobile payment network like Isis into the mix, and they’ll end up with data when riders pay by phone. As more companies become involved in paying for transit, the privacy risks increase.
Continue reading Locational privacy in open payment

Rider feedback for transit systems: the good and the bad

In July 2010, I attended a briefing for developers put on by WMATA, in advance of the launch of WMATA’s open data initiatives. One of the points expressed by developers at the meeting was a desire to give riders an easy way to provide feedback to WMATA from within mobile transit apps. So, while I was browsing the MBTA‘s developer resources page recently, I was interested to see that they have a pilot program to allow developers to communicate rider feedback to the MBTA from within apps. The program, called Commuter Connect, offers a web service which accepts text and images from riders. It looked great to me, until I checked the documentation. Rather than offering riders a simple free-form comment field, riders must give their full name, email address, home city, state, and ZIP code (what about non-US residents?), among other fields. Worse, riders must select a ‘topic’ and ‘subtopic’, choosing from dozens of cryptically-named options, like “Insensitive to Cust Needs” and “Passenger Bypass”.
The FAQ for the program says:

Why so many required fields? Commuter Connect is built as a part of customer care center′s management system. For us to follow-up on comments, we need all required fields. For full details of how to use the system please closely review the documentation.

Simply put, the problem with Commuter Connect is that it communicates with riders in the vernacular of the transit system, and expects them to do the same. There’s no absolute reason that riders have to classify the problem they’re submitting (least of all in the transit agency’s specialized vernacular); that can be done by the transit agency’s staff. More to the point, it exemplifies the sort of tone-deafness which perpetuates communication with riders by mass transit agencies—an inability to use plain language and communicate clearly. WMATA’s customer comment form exhibits the same problem—essentially ignoring rider feedback if the rider cannot be bothered to jump through all of the transit agency’s hoops—along with an expectation that riders will describe their problems in the same terms the transit agency would use. Perhaps the only redeeming factor for the MBTA’s Commuter Connect program is that it makes it easy to upload a photo (but accepting video as well would be even better).

By contrast, the approach taken by DDOT with the DC Circulator is a model for making rider feedback easy. Every Circulator bus has stickers prominently applied with a QR code and URL which allow riders to provide feedback; the feedback form is simple and uncomplicated:
DC Circulator feedback form
The mobile site requires no specialized software, and works on any device with a Web browser. Riders are not required to provide their personal information, nor are they required to categorize their comment according to the narrow confines of the transit agency’s schema. At the same time, if a rider wants to provide their contact information, there’s nothing stopping them from including it with their remarks. DDOT’s approach is designed to accept as much feedback as possible, rather than rejecting potential valuable feedback based on technicalities (like failure to include one’s home ZIP code, or classify one’s comment into arcane categories).

In short, transit agencies should be responsive to rider feedback even though it may come in a range of forms, and they should make the process as straightforward as possible—more like the DC Circulator, less like WMATA and the MBTA.

On smartphones in fare collection

From Kytja Weir of the Washington Examiner comes a brief article on smartphones and fare payment. The main thrust is this: “[i]f the U.S. starts to follow the rest of the world, subway riders could soon be using their mobile phones to pay for their transit trips”. The article cites a report by Juniper Research claiming that “500 million people worldwide will be using their cell phones to buy bus and subway tickets by 2015”. I’m not in a position to evaluate the veracity of that claim, but it may nonetheless be useful to look at the technical background. Just how, exactly, will riders pay their transit fare with their cell phones? What are the technologies involved, and who are the players?
Continue reading On smartphones in fare collection

Your smartphone is not an AVL solution

I attended TransportationCamp East this past weekend, and one of the technology themes which kept coming up was the use of smartphones to provide an inexpensive AVL solution for smaller transit agencies which do not presently have real-time vehicle location information. The concept of operations is simple: the smartphone is loaded with an application that fetches the phone’s location at a set interval, and reports it over the phone’s cellular link to a central server. Theoretically, it’s a good, clean solution. Unfortunately, the reality is not quite as attractive. Conventional AVL systems are expensive, and while I agree that to a certain extent they’re more expensive than they need to be, a smartphone isn’t an appropriate replacement. Here’s why:
Continue reading Your smartphone is not an AVL solution