Headway

This past weekend, I had a little bit of time to work on a hobby project:

This is my Sony Ericsson MBW-150 bluetooth watch, showing the next few SF Muni bus arrival times for a nearby stop. The code to fetch the arrival times is running on my Droid phone, and communicating with the watch using Marcel Dopita’s OpenWatch software for the Android platform.

Using a secondary display like a watch could allow a rider to keep tabs on when their bus is coming without constantly having to take their phone out of their pocket and unlock its display—particularly nice if it’s cold enough and they’re wearing gloves.

It’s also worth mentioning that a few months ago, I wouldn’t have been blogging about this. On November 7, the San Francisco MTA finally gave formal permission to developers to build apps using their realtime arrival data. Prior to that, developers who spoke publicly about their experiments with the Muni realtime data risked threats from a company that claimed a contractual right to charge for access to the arrival data for Muni’s vehicles. People were still building interesting things, but because of these chilling effects, no one outside of their circle of trusted friends would ever know about them.

Moral of the story for agencies: if you want to encourage innovative realtime transit apps in your city, read your contracts carefully, and insist on the right to provide realtime data about your vehicles to creative and energetic developers. You’ll be in good company, alongside the Chicago’s CTA, San Francisco’s Muni and BART, Boston’s MBTA, and Portland’s TriMet.

Note: this post was updated to replace the original image with an improved one on December 18, 2009.

A couple of months ago, a Chicago software developer named Harper Reed (who also happens to be CTO of skinnycorp, purveyors of some of my favorite t-shirts) did some reverse-engineering of the Chicago Transit Authority’s Bus Tracker web applications to figure out how to access the realtime information that they displayed.  He documented what he learned in a blog post, so that other developers could use that information to build their own bus tracking applications.
He also set up a proxy site for the API, to add a few functions, to return faster responses, and to reduce the load on the CTA’s servers.

His effort enabled others to create useful things like an iPhone application, a Mac OS X dashboard widget, a text messaging service, and a website that automatically shows you the stop you care about depending on the time of day. All of these things were developed in the space of two months, at no cost to the CTA, and at almost no cost to the riders (the iPhone app costs 99 cents to download—the other things I mentioned are free).

Of course, as Harper himself points out, his API is unofficial and illegitimate, done in one developer’s free time without the involvement or approval of the CTA or Clever Devices (its bus-tracking vendor).  These sorts of efforts are generally vulnerable to getting shut down under the auspices of contractual, copyright, or server load concerns.

For instance, here in San Francisco, developers of unofficial SF Muni tracking applications have received legal threats in the past: Steven Peterson (author of the handy Routesy iPhone app) mentioned it here and here, and Robert Dampho of muniriders.net told his story here.

Some of this is motivated by the fear of giving away what you might be able to sell.  It’s hard to blame perpetually underfunded transportation agencies for looking for additional sources of income—if they could find someone who’s willing to pay significant sums for access to their realtime information, then cutting off a few software developers (for whom transit applications are often a side project) might seem like a small price to pay.

However, this could be a false economy: consider how much time and money it would take for the CTA to contract out the development of all the applications I mentioned above. By allowing third-party developers to work with their information, a transit agency effectively gains a very motivated external R&D lab for almost no cost or risk.  A few forward-looking agencies have come to this conclusion, and have started offering official developer resources: Portland’s TriMet and the Bay Area’s BART have been the most progressive so far.

Until the day that the CTA decides to join them in explicitly offering access to their transit data, however, Harper and other Chicago transit developers are innovating on borrowed time.

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