Headway

Update (3/5/08): TriMet sent me an updated version of the presentation; I’ve updated the version embedded on this page, or you can download the PDF.

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.

One of the most exciting talks that I saw at last week’s APTA TransITech conference was Frank Purcell of TriMet’s talk about TimeTable Publisher. (I don’t have a link for that presentation yet, but here’s a PDF of his talk at GOSCON 2006.)

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.