In recent years, the largest U.S. public transit systems have begun releasing their schedule, fare, station, real-time vehicle location, and other data to the public in easy-to-use open digital formats. Using that open data, third-party developers have created a bonanza of new mobile and web applications for customers—everything from a signal that a specific bus stop is approaching to a multimodal trip planner that integrates bus, train, and bike.
“Open data is one of the biggest and most important innovations in public transportation in over 30 years. It is a key component in improved service for customers,” said Chuck Kamp, general manager of Metro Transit in Madison, WI. The agency credited its open data program for achieving a 40-year ridership record in 2011.
But the innovation potential of open source data brings with it associated challenges, not the least of which are cost and developing a sound process for releasing data and maintaining oversight of its use. Any public transit system interested in jumping on the bandwagon of open data—or expanding existing open data programs—could learn valuable lessons from the experiences of other agencies making the transition.
“You want to be in a position where you’re giving information, you’re supporting ideas, and you’re encouraging creativity,” said Ron Hopkins, assistant general manager of operations for Philadelphia’s Southeastern Pennsylvania Transportation Authority (SEPTA), which collects 1.5 million data points each month to measure on-time performance. “The concern was, how do we manage all that?”
What Is Open Data?
At its simplest, the term open data refers to information that is publicly available either from a government agency, a private company, or a community--supported resource such as OpenStreetMap.
For public transit, the term includes information about train and bus schedules, fares, station locations, ferry or trolley schedules and interchanges, bike share locations, and even turnstile usage or logo design specifications. While all this information may be available in numerous places, the key is putting it into formats that are easy for software developers to access and use on an ongoing basis—and for transit agencies to incorporate in their published application programming interface (API).
More than 200 agencies release data in the General Transit Feed Specification (GTFS) format, initially developed around 2005 by Google in partnership with Portland’s Tri-County Metropolitan Transportation District of Oregon (TriMet). The format’s widespread adoption in recent years has stimulated tremendous innovation in open data use.
“GTFS has been a huge part of making data more available, not just to the public, but also other systems,” said Tim Quinn, executive vice president for RouteMatch Software in Atlanta. “That’s been a game changer over the past two to three years.”
The next frontier is GTFS-realtime, a feed specification that incorporates the real-time location of trains, buses, and other vehicles. Fewer than a dozen transit agencies have advanced to using GTFS-realtime, including New York’s Metropolitan Transportation Authority (MTA) and TriMet.
“Real time is a little more difficult because it typically does require some type of infrastructure—tracking hardware and software on the vehicles themselves,” said Sean Barbeau, principal mobile software architect for research and development at the Center for Urban Transportation Research at the University of South Florida (USF).
The Power of Open Data
Many public transportation agencies are already tapping into the potential of open data.
The Massachusetts Bay Transportation Authority won a 2011 APTA Award for Innovation for its Open Data Initiative, which allows third parties to use the agency’s data to develop dozens of apps at no cost to the agency. The apps improve the rider experience by delivering real-time -information on schedules, locations, and other conditions.
New York’s MTA first released GTFS formatted raw data in January 2010 when the agency redesigned its website. Previously, MTA had mailed compact discs to developers on a quarterly basis, a cumbersome process that reached only a segment of the possible users.
“They were beating down our door, trying to access data they could find online in PDF files or ways that were useful for our customers, but not easily parsable and manipulatable in a digital way,” said MTA spokesperson Aaron Donovan.
“We want a lot of apps to be out there. They help our customers navigate the system. We’re in the business of providing a service and it helps us to do that,” Donovan said.
In addition to developing in-house apps—like the Weekender app displaying weekend service changes and track work—MTA sponsors contests and hackathons to stimulate developer interest. The second app contest, known as MTA App Quest, offers $50,000 in prizes and began with a hackathon the first weekend in May. MTA collects all the known apps on its website.
As a result, New York public transit riders can use multimodal trip planners to go from train to ferry and from subway to bus, taxi, or foot; find real-time bus and subway information; and even discover commissioned artworks within the subway system.
In the Minneapolis/St. Paul region, the move to open data has facilitated real-time trip planning across several public transit systems despite a variety of agencies and vendors managing different pieces, said RouteMatch’s Quinn.
RouteMatch provides fixed route computer automated dispatching/automated vehicle location (CAD/AVL) in real time for the Minnesota Valley Transit Authority in Burnsville, MN, while -Trapeze provides CAD/AVL for Metro Transit, serving the Twin Cities. Because both vendors are writing to the same open API, the systems will easily interoperate.
“In the old days, it would be a systems integration issue that wouldn’t have happened from a competitive business perspective,” Quinn said.
In Portland, TriMet customers can use apps to find the nearest bus stop, access real-time arrival information, and even create a strobe light to alert drivers to stop after dark. Another app, called iNap, lets a passenger daydream or snooze during the trip but alerts the person when the specific stop is nearing—also handy for visually impaired riders.
“I can’t justify developer resources to develop something like this and keep it up to date and maintained on all these different platforms,” said Bibiana McHugh, TriMet’s geographic information systems (GIS) manager, about the iNap app. “It’s something that’s very useful. It’s not something that a transit agency could really develop.”
TriMet does develop certain core apps, such as a multimodal trip planner and schedules, to ensure delivery of key customer information. Otherwise, third-party changes might disrupt service, such as Apple dropping Google Transit from the new iPhone operating system.
For their apps to be posted on the TriMet app page, developers must meet three requirements, McHugh said: They must use the developer resources, use the terms of agreement correctly, and create an app that works as advertised.
“We don’t want them getting data and information from someone else,” she said. “They can scrape your site for schedule information—and that’s when bad information starts getting out to the customers because those links break and they’re no longer current.”
If public transit agencies release data in the GTFS format and want rider apps like those in New York or Portland, they should contact developers to ask them to add another city. It’s often an easy matter to expand geographically, once the app is already created and user tested.
Best Practices to Use; Pitfalls to Avoid
Indeed, leaning on the open data work of other public transit agencies is a clear best practice for systems just getting into the area, rather than forcing them to reinvent the wheel. A Google group of public transit developers regularly shares information, ideas, and code.
When TriMet developed a timetable publisher, the agency released the source code to the public. SEPTA happily adopted the code for some internal uses and is eager to “pay it forward” by releasing source code to an iPhone app in development, said Mike Zaleski, director of emerging and specialty technology.
SEPTA benefits from the goodwill and interest of the developer community and has sponsored two hackathons to promote the development of transit apps. A third hackathon is coming up at the end of the summer.
Developing strong relationships with the local software community and universities has also worked well for -Madison Metro. The agency began its open data program because undergraduates at the University of Wisconsin asked for better data access. Once public transit officials satisfied concerns about the data’s accuracy and whether the apps would be maintained, they launched the current open data program. It’s now spreading beyond public transit to other departments, said Mick Rusch, transit marketing and customer service manager.
“The city of Madison is really embracing open data and one of the main reasons is the benefits we saw in the transit department,” Rusch said. “Our advice would be to do your best to work with the developers ahead of time. Tell them your concerns and make sure to impress upon them the needs of your riders and the need for it to be accurate.”
After all, third-party developers aren’t public transit employees or vendors, so system employees need excellent communication and a shared understanding of the goals and considerations in public transit if the project is to succeed. One of the students who developed a Madison Metro app continues to maintain it even though he’s been hired by Google and moved to California, Rusch said.
“It’s about fostering relationships with these people because they don’t work for you directly and you’re not purchasing a service from them,” he said.
For some public transit agencies, the cost of creating the information that developers want is the biggest challenge. The Birmingham-Jefferson County Transit Authority (BJCTA), Birmingham, AL, is in the midst of upgrading its 117 buses to include annunciators and automatic passenger counters—equipment that will create the data needed to begin to track passenger loads and bus movement.
BJCTA Executive Director Ann August has set a goal of reducing current one-hour headways to 15 or 30 minutes. Then the agency will be able to start giving information on the time of the next bus on electronic signs and for riders to access via smartphones.
“One of the most important things is to have the vision. Number two is to ensure that you have a system that you can get good clean data out of,” she said. “That way, when you’re moving forward to get the apps, you can provide efficient service.”
What the Future Holds
Over the horizon, developers are playing around with a range of innovative ideas. In Madison, the university is experimenting with tablets on buses for customer use or kiosks at transfer points to display real-time information and help with trip planning.
At USF, developers created a trip planner that integrates public transit, biking, walking, driving, and the campus shuttle. “That’s a huge project that I think is going to see huge adoption in the future,” Barbeau said.
Similarly, an app called Rome2Rio tells users how to cross continents and oceans via a combination of airplanes, rail, and bus, and the Parkio app incorporates rideshare, vanpool, and corporate shuttles. Mapnificent helps people find the closest location in a desired category, such as the most quickly accessed museum or restaurant that is in the middle point of two friends’ current locations.
Another important new frontier is open data for internal use by public transit systems. Imagine being able to produce a new timetable with a few clicks of a button or using a free and openly available trip planner analyst to weigh decisions around new route service.
Even getting the dispatch system and scheduling system to easily interoperate would be a huge step forward, said Rob Ayers, president of Ayers Electronic Systems, a transit systems integrator focusing on standards-based solutions, based in Richmond, VA.
“You have some pretty large and complex data sets that are exchanged within business units within an agency,” Ayers said. “A goldmine for the future is to standardize that data and reduce the cost of managing that data.”