Government

Transportation contracts should always require open data

by David Alpert   •   December 21, 2011 2:33 pm

Governments often hire private contractors to operate transportation services or build technology tools. When those projects provide open data as part of the program, customers can benefit at little or no cost. When open data is left out, governments are throwing money out the window.

Governments benefit from apps like Transit Near Me.

Capital Bikeshare, Zipcar, and many of the region's local bus systems and vanpools are all operated by private companies with varying contractual relationships with local governments. It's an efficient and flexible way to provide transportation services.

Generally, when a private company is hired to provide some kind of transportation service, the contract includes building a website and maybe a mobile app. That's fine, but those contracts should also require the vendor to create open data feeds, which let other people build applications that give users information about the transit service.

Capital Bikeshare is a successful example of how to do this right. CaBi has its own website, which is perfectly nice. But it doesn't do everything. It doesn't tell you if show visibly on the map which stations are empty or full, and it's not on your smartphone. Nor is it on a digital screen on the wall of your neighborhood bar.

A company called 8D has a relationship with CaBi and other Bixi-based bike sharing systems to create an app, SpotCycle, which provides many useful functions, but one app can't do everything either. What if someone else can do better, or do more than just that app can do?

Fortunately, there's a computer-readable XML file for Capital Bikeshare (and all other Bixi-based systems) which lists the real-time status of all stations in the system. The availability of that data allowed Daniel Gohlke to create CaBi Tracker, arguably a better system map than the official one. Many other mobile apps exist using the same data, each trying to be better than the next.

At the Mobility Lab, we're creating real-time digital displays that show buses, rail, and Capital Bikeshare all on one screen at the same time. That's never going to be something Capital Bikeshare funds itself, but it's potentially a very useful tool, and it's possible thanks to the feed.

It's great that Capital Bikeshare offers this, but not every service does.

As one of many examples, the USDOT and local governments have funded a research project at the University of Maryland to create a real-time traffic information site for the I-95 corridor. It's a good start, but very limited.

UMD could evaluate even more ways to assist travelers if someone could make an app, screen, or site that showed this information in even more ways. Unfortunately there appears to be no feed. The utility of this project is therefore drastically limited, and its funding is not going as far as it could.

Montgomery County spent a bunch of money for a web tool that lets riders to see the location and predictions for Ride On buses, but didn't include a feed or API (Application Programming Interface). The MARCTracker tool to see the location of MARC trains doesn't appear to have an API, either.

Now, no other apps can integrate the information and present it to more users. We can't put Ride On or MARC on the real-time screens, and mobile app developers can't add it to their tools. Plus, the Ride On tracking website already looks clunky and out of date, and it's still in a beta test phase. The county put their money into buying something that's already behind the curve and which can't accommodate future improvements.

Meanwhile, WMATA, DC Circulator, and ART all have feeds or APIs that allow apps and other services to retrieve their real-time information and show it to riders. This has all sorts of advantages, not the least of which is that their data can all be combined into a single website. For example, Transit Near Me, Mobility Lab's recent transit app, is only possible with the data from these transit services, but can't include Ride On.

These transit services are run by public agencies, but open data is equally important when the public is paying a private company for a transportation service. Governments should require open data in every contract with private providers.

For example, the one-way car sharing company car2go offers an API for integrating with other apps, but Zipcar and many other car sharing companies do not. When the city dedicates on-street parking spaces to car sharing companies, they are giving away a valuable resource. In exchange for that resource, the city should demand the company open its data, and require that feeds or APIs remain public in the future.

Open data offers absolutely tremendous opportunity for transportation providers to improve their service to users, and it is essentially free. All they have to do is put their data out there, and someone will take advantage of it to produce a useful tool.

Disclosure: I am leading a team at the Mobility Lab that is building Transit Near Me, real-time screens, and potentially other tools which take advantage of feeds from transportation providers.

David Alpert is the Founder and Editor-in-Chief of Greater Greater Washington and Greater Greater Education. He worked as a Product Manager for Google for six years and has lived in the Boston, San Francisco, and New York metro areas in addition to Washington, DC. He loves the area which is, in many ways, greater than those others, and wants to see it become even greater.