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 biggest benefits of transit agencies making their raw schedule data publicly available, as TriMet and others have done, is that riders are free to do interesting things with the information that the agency itself might not have thought of or have taken the time to do themselves.

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!

It’s been a couple weeks since my last post about transit and the iPhone, and we’re starting to see some iPhone-optimized transit information.

Turncolor, a software startup, has created MuniTime, a pretty iPhone widget that counts down the time to the next bus or train arrival at a particular stop. MuniTime currently supports San Francisco Muni and Portland Streetcar, but I assume that it could easily be adapted to any of the many systems that use NextBus for vehicle tracking. I really like MuniTime; my main wish-list item for them is an easy way to bookmark a particular stop, so that I can easily jump to the right one as I’m roaming around town.

Also, this weekend I threw together iNextMuni, a version of the NextMuni mobile site that has a more iPhone-like style. This was mostly an excuse for me to play around with Joe Hewitt’s iUI interface library, but maybe some of you will find it useful.

Have you come across (or built!) other iPhone-optimized transit applications? Let me know in the comments!

The Sick Transit Chicago blog asks: can good realtime information trump short headways? I suspect that there’s a tipping point for headways—if the bus or train comes every 10-15 minutes (or better), riders can feel comfortable just showing up at the station, confident that they won’t have to wait too long. If the improvements in service wouldn’t improve things to that point, I bet most choice riders would prefer realtime transit information.

There is a social justice angle to this, though—not everyone has easy access to internet-connected computers and mobile devices. Unless the agency can afford lots of estimated arrival displays for shelters, and a voice-based automated system (IVR) for checking arrival estimates, the information will only benefit a subset of the ridership.

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.