Earlier this year, I attended TransportationCamp East 2011, an ‘unconference’ on transportation and technology. In one of the sessions, on open payment, the most common question from developers was a simple one: how can I get involved? Many developers were disappointed to hear that there was no good answer; that while these systems are intended to be open, little work has been done to define specific interfaces.
Now that WMATA has released the Step 2 RFP for its New Electronic Payments Program, we have a clear view of what WMATA expects from the system. As much as WMATA has pushed the use of an open architecture for the NEPP, open data does not feature heavily in the specification. There’s an entire section in the Technical Specifications devoted to APIs—but it deals with the APIs that will be used for the various components of the NEPP to interact with each other as well as with other WMATA systems. Evidence from transit systems around the world shows that there’s a great deal of interest in developing apps which interact with their data. Rather than being bolted on after-the-fact, public APIs should be part of the NEPP from the ground up, and the system should be designed to embrace the efforts of outside developers.
What might these public APIs include?
As an example, current fare tables can be exposed as a Web service, allowing third-party trip planners and mobile applications to calculate fares and display this information to their users. Fare information can be stored in GTFS feeds, but for transit agencies with more complex fare structures, it may make more sense to allow third-party developers to submit a query with the origin and destination stations, time period, and other relevant information (like whether the rider receives a reduced fare), and get a real-time response.
Other public data which can be exposed from a fare collection system includes aggregate statistics on ridership and fare media sales and use. MTA New York City Transit, for example, currently makes data available on MetroCard swipes and turnstile entries. By designing the system to make it easy to expose this data, developers might be able to get something that is more convenient to work with than a CSV file that is updated once a week.
More care must be taken with riders’ personal information, like journey history—but that shouldn’t keep the data from being made available to developers. As I mentioned in my discussion of Chromaroma, there’s a right way and a wrong way to expose this data to developers. Developers should not be put in the position of having to store clear-text passwords and screen-scrape a transit agency’s Web site; they should be able to use secure authentication methods like OAuth, and exchange data using open standards. When users authorize a third-party app to access their information, they should be given clear information on what they’re authorizing access to, and how it will be protected.
Once a framework has been put in place to allow developers to securely access user data, what might developers want access to? Journey history is the most likely place to start. There are many kinds of apps that can be built on top of journey history data, from statistical analyses and visualizations, to games like Chromaroma, to tools which show users when they’d save money by buying a pass instead of paying for trips individually.
Developers may even want to tie data from the fare collection system together with other applications: ride the Metro to a certain station and get a coupon for a nearby retailer delivered to your phone automatically. Or, it may work in the opposite direction: buy tickets for an event near the Metro, and automatically top-up your account with round-trip fare.
Application developers may also want to be able to offer users the ability to reload prepaid fare media online using emerging payment technologies; if not Bitcoin, then whatever comes along next. Mobile developers may also want to build apps for platforms for which WMATA chooses not to produce an official offering.
Open data and open interfaces are no longer a luxury; developers have come to expect that public data will be available in machine-readable formats through easily-accessed APIs. Where data is made available without a good API, developers will readily revert back to screen-scraping, an alternative which leads to the development of applications which are less flexible and which can be less secure. APIs for outside developers should be considered a core part of an open-architecture AFC system, right alongside the system’s turnstiles, bus fareboxes, data warehouses, and other key components.