Google Transit Has Expanded

Google has updated their experimental Transit product to include 5 new cities. Now Seattle, Pittsburgh, Honolulu, Tampa, and Eugene, in addition to the original Portland, are available. To enable further expansion they have also published a feed specification that cities can use to share their data. I’m excited by this as I find the UI very simple to use, but when I ran the product by some fellow Seattle-ites they felt that they got better results from the local Trip Planner. I’m sure this will improve in time. WorldChanging, who helped with the product, has more.

  • One of the reasons that so few people in the United States use public transportation is that they have no easy way to learn how their local mass transit system works. This is why many transit agencies have made trip-planning tools available online. However, they generally suffer from poor interfaces, differ from city to city, and are limited to just one agency—even in large metropolitan areas where a single trip may require riding vehicles from multiple agencies. A universal interface, enabled by a universal data standard, would be a huge improvement—and it is starting to happen.

    About a year ago, Google launched Google Transit, a travel planner for mass transit systems, starting with Portland, Oregon, as a proof of concept. According to Avichal Garg, a product manager for Google Transit, Google chose to launch with the Portland metro area because Tri-Met, Portland’s transit authority, is “a technological leader in public transportation,” the team at Tri-Met “is a group of tremendously passionate people dedicated to serving their community,” and Tri-Met has “a wealth of data readily available that they were eager to share with us for this project.”

    Three weeks ago, Google expanded the application to cover five additional cities—Eugene, Oregon, Honolulu, Hawaii, Pittsburgh, Pennsylvania, Seattle, Washington, and Tampa, Florida— and laid the groundwork for a much greater expansion by releasing the specifications for transit agencies to submit their data. Last Friday, at the Government Open Source Conference (GOSCON) in Portland, Stephanie Hannon, Google Transit’s product manager, and Chris Harrelson, the application’s engineering lead, presented Google Transit to an audience that included engineers and managers from several transit agencies.

    Google allows its engineers to spend 20 percent of their time pursuing projects about which they are passionate. Google Transit—like Google News, Google Suggest, AdSense for Content, Orkut, and Gmail—was born as such a “20 percent” project. It was conceived by a few Google engineers from San Francisco, New York, and Zurich —all of whom regularly use public transportation—as a way to enable mass transit riders to plan local trips in an intuitive way, without having to go to multiple websites. It became a regular Google project shortly after the launch of the Portland pilot program, Hannon told me. She declined to discuss the size of the product engineering team, but told me that Google Transit is staffed “across many geographies, including Zurich, Switzerland, and Mountain View, California.”

    Hannon points out that the World Wide Web, the quintessential driver of globalization, has become increasingly localized, via websites set up primarily to serve local constituencies. Examples include craigslist, the sites of community organizations, and the Chicago Transit Authority’s trip planner. Trip planners that use Google Maps fall into two categories: mashups, developed using the Google Maps JavaScript API, and applications developed directly by Google in collaboration with the various transit agencies. An example of the former is Seattle’s “bus monster.” (Notice the disclaimer at the bottom: “This site makes use of Google Maps, King County Trip Planner, and UW ITS, but is not affiliated with any of these sites.”) An example of the latter is a map of London underground stations (go to, enter “tube stations in London” into the text box, and click on “Search Maps”), which has also been incorporated into Google Earth as an option in the transportation layer.

    During her GOSCON presentation, Hannon displayed a map of the Moscow subway, rendered using Google Maps. She pointed out, however, that the data had been provided by “a member of the community.” I asked her how users could tell that a Google Map of a mass transit system was not provided by the relevant transit agency and whether Google planned to post any disclaimers. She told me that, in this case, there could be no confusion because, in order to view this map, she had to download the data from a website and import it into Google Earth.

    Google Transit can be queried using plain English text—such as “from 1203 NE Thompson Street, Portland, Oregon to 5209 SE 28th Avenue, Portland, Oregon”—and returns the next four departure times, in the transit agency’s local time zone. It also gives the trip duration and cost, directions, and reverse directions.

    In his GOSCON presentation, Harrelson explained that Version 1 of Google Transit’s feed specification is based on three design principles. First, it is simple: it is in a human-readable, CSV format and uses the minimum number of features to represent the most important concepts. Second, it is compatible, both backward (“as similar as possible to other formats we have seen”) and forward (“ready to be expanded with more capabilities in the future”). Third, it is open: it uses a Creative Commons license, it is not controlled by Google, and it is available on the Web today.

    The specification allows transit agencies to represent stops, trips and trip metadata, route metadata, agency metadata, block transfers, trip validity calendars, and fares. According to Harrelson, wheelchair and bicycle access attributes and maximum walking distance will be added soon. The Google Transit team, he says, is working to make sure that the site is accessible to everyone and on every device. To this end, it recently added a new HTML-only (no Javascript) mode and a mobile phone version.

    To make their data available to users via Google Transit, transit agencies create files according to the specification and host them on an HTTP or HTTPS server. Google fetches the files on a regular basis and builds a preview of the agency’s data. The agency then reviews the data and iterates with Google to resolve issues. When the agency approves the data, it is posted. Live updates will be handled through a separate feed, says Harrelson, directly from each agency’s dispatch center. Agencies that want to participate should write to the Google Transit team.

    I asked Hannon which cities Google Transit plans to add next. She answered, diplomatically: “We look forward to working with more cities to bring their public transportation data online. We will add any additional cities that can provide data in a format we can parse.”

    I asked Harrelson why his team wrote a new data format rather than adopt one of the existing ones. “The main reason,” he told me, “is that we felt that these were highly technical and complicated formats and we would have more success starting out with something that is very simple.” What about creating personal profiles—so that, for example, a disabled person could specify the maximum distance he can walk to get to a stop or to transfer? According to Harrelson, his team will add that option by building on the “Saved Locations” feature of Google Maps.

    Hopefully, the next iteration of Google Transit’s feed spec will function as a universal translator for transit systems—allowing multiple systems to work together seamlessly and provide a complete itinerary to a user in response to a single query.