City-Go-Round is in many ways a successor this site’s own Headway Wiki, in that it makes it easier to find transit apps that people have built for a particular area or agency. However, CGR adds things like location-based search, screenshots, and better information about platforms and locations for each app. Even more importantly, it helps show how open data can really enable developers to build apps that help transit agencies and their riders, and provides a way for transit riders to tell their local agencies that they want open data.

The site came about because the guys at Front Seat started adding public transit information to their Walk Score site, and they started wondering how they could get access to more transit information to make their site more useful. So they rounded up some of the most passionate open data advocates in the Transit Developers community: Brandon Martin-Anderson, Jehiah Czebotar, Dave Peck, and Josh Livni, and put together a great resource in a few short weeks. (I also helped in an advisory role.)

The site has the most data about the US, but there’s already a bit of information about Canadian and Australian agencies. The site is also open source, and the team hopes that developers in other countries will help expand the site towards more global coverage.

Earlier today at the APTA TransITech conference, TriMet‘s Tim McHugh gave a heartening talk about their experiences with making their raw schedules and and real-time information available to developers. Here are the slides:

| View | Upload your own

Since you don’t get to hear the spoken half of the talk, here are a few points that he made that aren’t in the slides:

• Riders always want more ways of accessing transit information, but TriMet has limited development cycles; releasing schedule feeds and APIs is way to allow outside developers to close the gap.
• Chances are, outside developers are already scraping your transit site anyway, so why not give them a less error-prone direct feed of the information?
• In the future, they plan to release an API to their trip planner.
• Since they’ve launched their developer site, they’ve only received positive feedback on the resources; there’s been no negative impact on them from doing this!

The significance of this talk lay partly in the audience of technical staff from other agencies and transit vendors–this is the strongest endorsement that I’ve ever seen from an agency of the virtues of working with outside developers. In time, I hope that stories like TriMet’s will convince other agencies that they have much more to gain than they have to lose by sharing their data.

Case in point: Brett Warden in Portland is using TriMet’s GTFS feed to create a POI (points of interest) file for his dashboard-mounted GPS. This means that the very latest TriMet stop data now forms a clickable layer on his Garmin StreetPilot c580. Here are a few screenshots:

Bus stops are shown alongside driving directions.

Stop icons on the GPS map can be clicked on to show…

…the stop name and description, into which Brett has packed the stop ID, fare zone, and lines serving that stop.

Brett told me how he got started on the project:

At first I saw a POI collection, made by hand, of
all TriMet’s light rail stops. That got me thinking — if they made
the data available to Google, maybe they’d let me see it too, and make
a comprehensive map of ALL transit stops. They responded, and pointed
me to the GTFS developer site… by far the easiest experience I’ve
had getting information from a public agency.

To generate the file, he imports the GTFS feed into an SQLite DB and runs a few simple queries to generate the POI file. He plans to post the code soon, which will allow it to be used with other agencies’ GTFS feeds. In the meantime, the resulting TriMet stops POI file is available on the POI Factory site.

Last month, Portland, Oregon’s TriMet agency became one of the first transit agencies to open a dedicated site for third-party users of their data. This site (along with BART’s GTFS page) marks a milestone for the transit field, demonstrating that agencies are starting to understand the benefits of sharing their data with outside developers.

To be fair to the folks at TriMet, they’ve been making this information available more unofficially, on request, for quite some time now. However, it’s significant that they’ve chosen to invest the time to publish a dedicated site with the necessary CYA legal text and API key mechanisms; it will no doubt encourage developers who weren’t previously aware of TriMet’s forward-looking stance on data sharing.

Right now, TriMet is providing the following:

• Their entire schedule in Google Transit Feed Spec format, the open format used by Google Transit, Graphserver, PolyTransit, and others.
• Arrival estimates by stop (example)
• The current set of detours by route (example)
• Listings of routes and stops to enumerate the parameters for the other services (example 1, example 2)

They’re off to a great start. Applying for an API key is painless (I got mine within 5 minutes of signing up), and the fact that the services are in REST form makes it easy to experiment with them by just typing in different URLs. (Still, it would be nice to have more sample queries, or perhaps even an interactive web form, to demonstrate the expected query parameters and corresponding output before even having to sign up.)

Congratulations to TriMet on their launch—I’m looking forward to seeing what creative uses developers will have for these offerings!

So, this is my challenge to Google and to all of you transit buffs out
there: build us a very cheap or free database or other software that
will maintain schedule data and export to GTFS. There are products
out there on the market, but they cost an arm, a leg, and your
firstborn. There is huge market potential for someone to build an
excellent product, sneak into the market, and grab up all of the
smaller customers that wouldn’t touch one of the big companies (and
vice versa).

The first is clickable transit icons on the map:

When you zoom close enough into areas with transit coverage, you’ll see icons on the map showing where bus and rail stops are located. You can click on these icons to see which routes stop there, and if the agency has provided its schedule information in Google Transit Feed Spec form, you can see the next scheduled departures for that stop right in the bubble!

The other feature that will be of interest to transit riders is the new “Street View” feature, which lets you “travel” up and down some streets on the map, getting panoramic views of the surroundings all the while:

As you can see here, this feature can be handy for figuring out exactly where the bus stops are in relation to nearby landmarks. The image depicts a typical San Francisco Muni bus stop, indicated only by a stripe of yellow paint on a light pole (if you zoom in on this street view, you can almost read the route numbers that serve the stop). If you had been given directions to get on or off at this stop, Street View would allow you to figure out that you should look for the “Me Lindo Peru” restaurant as a landmark. (Beyond its usefulness, Street View is plain fun to play around with, especially using the arrow keys to pan and move.)

Both features are available in a limited number of cities right now, but you can expect them to spread to more areas as time goes on. (Disclaimer: I had a minor involvement in the new transit icons, and I, er, enjoyed playing with internal betas of Street View.)

Headway-based schedule support

The new frequencies.txt file allows you to specify that a bus or train trip happens every 10 minutes, rather than listing out exact times for each trip.

Multiple agencies in the same feed

Previously, you had to have a separate feed for each agency you were providing data for. Now you can have more than one agency in the agency.txt file. There’s also a new agency_id column in both agencies.txt and routes.txt that lets you specify which route is operated by which agency.

Per-route and per-stop URLs

Some agencies have web pages for individual routes and stops. In those cases, the new route_url and stop_url fields allow you to specify those in the feed.

Better printed schedule support

When generating static or printed schedules for a route, it’s helpful to be able to classify the trips into two opposing directions. The direction_id column allows you to assign each trip to one of two directions. The directions (0 and 1) don’t have pre-defined meanings—consumers of the feed are expected to use the trip_headsign fields to determine names for the directions.

Mid-trip headsign changes

Some transit vehicles change the information on their headsign depending on where they are in their route. For instance, a crosstown bus may display “To Downtown” for the first half of its route, and “To Suburbs” as it goes through the downtown area. To represent this, you can put the new value in the stop_headsign column for the stop at which the sign changes.

Route colors

In some cities, specific colors are associated with certain transit routes (like the MAX Red Line in Portland). The new spec has optional route_color and route_text_color fields for those cases.

Removed the ability to specify stops using street addresses

The previous version of the spec allowed you to give the location of a transit stop using a street address in the stop_street, stop_city, stop_region, stop_postcode, and stop_country columns. Now stop locations must be given using stop_lat for latitude and stop_lon for longitude, which are more useful for most applications.

Cable car vehicle type

If your city happens to have vehicles that are pulled by cables, you can now specify that in the route_type field.

Better sample data

The old sample data gave the same trip_id for two different trips, oops!

TimeTable Publisher is an application that TriMet developed in-house for turning their schedule data into user facing print and web timetables. The app is intended to be used by the agency’s marketing department, and as a result, it’s strongly oriented towards making decisions about how much schedule information is the right amount to present to users.

After importing the schedule data, the user can add or remove timepoints for particular lines, and can also set up footnotes for schedule entries. Once the schedule preview looks right, the user can automatically generate updated HTML and PDF schedules for the web, as well as InDesign XML for the fancy print schedules. To make it easier to figure out whether the print schedules for a given route need to be updated, the application allows the user to compare two service dates to see which routes have changed significantly.

This application is exciting because it’s one of the first instances of a transit agency making an in-house tool available for other agencies and interested parties. Being able to re-use this work means that an agency can get good results without spending as many of those precious operating dollars. Since it accepts data in Google Transit Feed format, any agency that’s participating in Google Transit can use this tool with minimal effort. For that matter, since the Google spec is an open standard, anyone who cobbles together a feed (for whatever purpose) can use it.

I should mention that the source for TimeTable Publisher isn’t publicly available yet—I gather that the TriMet folks are still tidying and vetting the (Java) code. However, they hope that it will be generally available in the next few months (and if you’re from an interested transit agency, I suspect they’d be willing to let you work with pre-release code).

Hopefully this is a sign of things to come, and we’ll see more shareable tools as more and more data is made available in standard formats!

Disclosure: I was attending TransITech on behalf of Google Transit, but as always, this post reflects my personal opinion.

Update (3/11/2007): Here’s Frank’s TransITech presentation (PDF). These slides show a lot more of the user interface of the app.