Headway

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.

Over at SFist, Matt Baume has been doing bang-up job on the MUNI beat. One of his innovations is the NextBus screencast, as demonstrated below:

By taking a time-lapse video capture of the online real-time bus map (and he details his methods in this post), he can go back and speculate about how things went awry. The example above shows how a detour for a street fair was handled. Neat!

Incidentally, since SFist doesn’t seem to offer a syndication feed for just their MUNI category, I threw one together using Pipes:

SFist MUNI Category RSS feed