Despite promises of transparency and efforts to create "open data" in the hopes of latching onto the "app economy"—words frequently used in government agency press releases—much of the data that would be of the greatest value to citizens often ends up out of reach. For example, if you want to plan a trip on public transportation in many cities (or even just find out when your bus will show up), you often have to turn to Google Maps or another transit-tracking application on your mobile device. In Baltimore, however, that data has been locked behind the firewalls of the Maryland Transit Administration (MTA).

But now a civic hacker has made that data available to app developers by doing what the MTA claimed would cost hundreds of thousands of dollars to complete—simply tapping into websites that the agency has already built. And the hacker did it without spending a dime of taxpayer money. The work took just a few man-days' worth of spare time and a commercial app development team's afternoon.

While the MTA released an early version of its own bus tracking application this month, it's a Web application and lacks tools like geolocation. It has the sort of byzantine interface that most people have come to expect from government websites, it makes accessing the data difficult, and the MTA isn't making the data available to Google or others to make finding the best route any easier.

As one reader of the Baltimore news blog Baltimore Brew commented, "Based on what I have seen so far, they seemed to have hired the finest transit technicians from 1989 Albania. This system might win 3rd place in a 5th grade science fair."

The reason the MTA gave for not doing a mobile app—or opening the data to third parties—was cost. "The data received from the bus [Computer Aided Dispatch (CAD) and Automatic Vehicle Location (AVL)] system to operate My Tracker is not sent in a format that can be easily used to create an application—called General Transit Feed Specification (GTFS). We know in many cases, the information needed to create an application is made public so private firms can attempt to develop an application at their own expense. However, it would cost approximately $600,000 more to be able to format the data from our 25-yr-old CAD/AVL system into GTFS for use by outside developers," the MTA said.

However, within days of the MTA's Web app going live, geo-data developer and open government data advocate Chris Whong had already done what the MTA refused to do. Whong took a look at the bus tracker Web app and found that its AJAX interface was polling the site every 10 seconds to get new location data. As it turns out, the app was retrieving JSON-formatted data from the MTA's servers, encoded in a format called the General Transit Feed Specification (GTFS). The MTA had already published the GTFS metadata describing bus routes. Whong wrote in a blog post that it took a few hours of trial and error to confirm the data feed format, but in the end he and a small team of "civic hackers" were able to construct a framework that would allow applications to pull, for free, the very data the MTA said would cost $600,000 to publish. The team also produced a live tracking site on the Heroku application hosting platform to demonstrate the framework and then posted the whole thing on Github to allow others to use it.

And use it they did. The Montreal-based developer Transit App was one team that grabbed onto Whong's project. "With Chris’ help, we were able to pull the real-time vehicle positions from the MTA system ourselves," the Transit App team said in a blog post. "Using that data, we generated approximate bus arrival times with our in-house prediction engine. We then compared those predictions with the MTA’s tracker to verify our accuracy. And—with just an afternoon of work—Baltimore finally has the real-time tracking app it deserves. $600,000 under budget."

The main problem remaining is the source of the data. MTA's CAD-AVL data comes in over radio from buses and is based on GPS data, so it has limited accuracy and can often drop off when a bus' radio signal is blocked (or the driver just doesn't turn the system on). In those cases, the data only provides scheduled arrival data, which in Baltimore qualifies less as an estimate and more as wishful thinking. MTA officials say that within 100 days, they will work out the live data feed issues so that data available to riders—whether they're using MTA's site or a mobile app that scrapes its data—will be more accurate.

Update: The MTA has posted a response to Transit App's blog post, explaining that the issue that the agency faced was the cost of moving to a real-time version of GTFS, and that the web app was just part of a larger system that allows passengers to get a voice response about bus status with a phone call or via email:

[T]he cost to convert our CAD/AVL data prior to the development of the interface was going to cost MD taxpayers an additional $600,000. This didn’t seem like a smart option to us since we are in the process of investing in a brand new real-time system (which uses GTFS data, by the way), which we hope to implement in a few years. That is why seeing the app delivered today through @transitapp came as such a pleasant surprise. We want nothing more than for our private sector friends to improve upon what we’ve already done. In essence, we have built the “real-time” foundation on which all other apps for our system can be designed, and we want to see that happen. So, to further those efforts (and yes, civic hackers have helped us speed this announcement up ) we are happy to report that our engineers have been working for weeks to figure out a way to move the data we made possible into a secure enough environment in which third party developers can safely make use of it without compromising our system. While we’re not ready to divulge the time-frame, we are getting close. And we look forward to seeing the results of that effort as much as our friends in the software development world do.

Read more: