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.

At the launch of the iPhone over a year ago, I got excited about how good the iPhone was for transit riders, and I’m happy to say that it’s gotten even better in recent months.

First of all, the launch of the iPhone application store this July has led to unparalleled boom in the development of mobile client applications, including many more transit-related apps than ever before. I have a category for iPhone apps in the Headway Wiki, but new ones have been popping up faster than I can add them! A quick count shows about 100 transit-related apps in the U.S. store alone, mostly in the Navigation and Travel sections. The apps range from simple system map image browsers to apps that have full trip planners and real-time arrival estimates (particularly for systems that have opened up their data).

Why are we only seeing this rush now, when other kinds of smartphones have been around for the past 10 years or so? I think there are a few factors:

1. The iTunes application store makes it dramatically easier to buy and install applications than on any other smartphone, and it’s straightforward for a developer to post an app and get a 70% cut of whatever price they choose. In a way, Apple has done for mobile applications what they had already done for music downloads.
2. An iPhone app has several ways to determine where the user is, whether by GPS, Skyhook’s wi-fi base station database, or Google’s cell tower location system. This makes it possible for an app to automatically show the closest bus or subway station.
3. The iPhone and iPod Touch present a uniform platform, where every device has the same screen size, and every device has a data connection at least some of the time. This simplifies the task of designing an application.

These things combine to create an attractive situation for would-be developers of mobile transit applications, and so far, the market seems to be thriving. I’m particularly happy that it’s brought several active new faces to the Transit Developer community (and that several of the iPhone apps use public GTFS data feeds from agencies).

The other exciting development is one that I’m happy to have had a hand in: the addition of public transit and walking directions to the iPhone’s built-in Google Maps. It’s great to have public transportation as a first-class citizen of the iPhone, so that transit directions are just as easy to get as driving directions. Besides being incredibly convenient for regular riders like me, this has the potential to raise awareness of the transit option to people who might not have considered it before. I’ve been seeing a lot of great feedback to that effect on Twitter—here’s one example:

New subway and bus schedules in google maps on the iPhone = amazing. Just saved me a cab ride. –leemhoffman

Of course, iPhone Maps only gives transit directions in areas where the agency or operator has made their schedule data available to Google. This can lead to odd situations like the one in London, where Google Maps has commuter coach information from Traveline South East, but no information from Transport for London on the tube or the city buses. However, the list of covered regions continues to expand almost every week, as more agencies see the value of publishing their schedules for Google and other application developers to use.

What about the other smartphone platforms? Symbian, BlackBerry, and Windows Mobile are all still quite viable, and I have no doubt that the success of Apple’s app store will spur the development of easier ways to create and distribute apps on those platforms. Hopefully this will expand the market for third-party transit apps there. (It’s also worth noting that they all have their own versions of Google Maps for mobile with public transit directions already.)

The new Android system isn’t available on many phones yet, but it does have a decent app store and standard location APIs, so I expect to see many more third-party transit apps there as the platform becomes more common. Unlike the iPhone, it also allows programs to run in the background while the user is doing other things, meaning that it’s possible to build applications that can monitor the progress of your bus or train and sound an alarm when it’s time to leave the house.

In any case, these are exciting times for the mobile phone market, and ultimately transit riders will continue to benefit by getting better information on the go.

As some people have noticed, right now it’s hard to get transit routing from Google Maps on iPhones, because Apple’s software grabs most Google Maps URLs and sends them to the built in Maps application. This situation will no doubt be improved in the future, but in the meantime, here’s a workaround.

To get Google transit routing on your iPhone, go to:

http://maps.google.com/transit

and do your search from there. This will give you plain-HTML transit results.

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.

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 topic du jour in the geek press is the iPhone, and I can confirm that it is indeed the bees’ knees. I found it interesting that two different online commentators saw fit to point out today that the iPhone is a great way to pass time on public transportation. First, here’s author Steven Johnson:

Here’s one I wouldn’t have predicted in advance: the iPhone makes me want to take a train somewhere. People who have above ground mass transit commutes are going to be psyched. Surfing, checking mail, listening to music, picking up a few calls — all without lugging out a big laptop, or switching back and forth between the Treo and the iPod.

Soon after I read that, I saw that one of Philip Greenspun’s friends summed up his iPhone review with:

If I were a train commuter, or a yuppie with a fast-paced
street life, I’d buy one tomorrow.

Why is this popping up in the zeitgeist? I think the iPhone is introducing many people to the joys of always-on mobile internet. For the past couple of years, my Hiptop/Sidekick has been making my transit trips (and waits in line) more pleasant, and the iPhone is head and shoulders above that device. And surfing the web or watching a TV show on your phone is much more fun than having to stare at the bumper in front of you in the daily traffic jam.

Not only is the mobile internet a good distraction—it’s also a great way to get transit information. For those of us that work on transit sites, the iPhone means more chances to help people when they’re out in the world. I tried out a couple of the transit sites that are dear to my heart on the iPhone’s Safari, and the results were decent:

Google Transit defaults to giving static HTML directions on the iPhone, which works OK. (Draggable web maps don’t really work on the iPhone, since dragging only pans the page.) Unrelated to the Google Transit web app, you can see (but not click on) rail station icons in the iPhone’s native Google Maps application:

buskarma also does fine:

An unexpected benefit here is that buskarma also makes it easy to get to the Pittsburgh Port Authority‘s PDF maps, which look great on the iPhone’s PDF viewer (blame the slight blurriness on my photography rather than the Ginsu-sharp screen):

(To get to the PDF schedule and map for a route, just type the route number, say, 54c in the buskarma searchbox, then click printable schedule.)

These work OK, but there’s lots of room for improvement—I would love to see a transit application that’s as well-adapted for the iPhone as the OneTrip shopping list site is. Sure, the iPhone is an extreme niche market right now, so making an iPhone-specific site isn’t going to help the majority of transit riders—yet. However, I hope that the popularity of the iPhone ushers in an era where good mobile internet is commonplace in the U.S., and where more riders get good transit information where and when they need it.