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.

City-Go-Round is in many ways a successor this site’s own Headway Wiki, in that it makes it easier to find transit apps that people have built for a particular area or agency. However, CGR adds things like location-based search, screenshots, and better information about platforms and locations for each app. Even more importantly, it helps show how open data can really enable developers to build apps that help transit agencies and their riders, and provides a way for transit riders to tell their local agencies that they want open data.

The site came about because the guys at Front Seat started adding public transit information to their Walk Score site, and they started wondering how they could get access to more transit information to make their site more useful. So they rounded up some of the most passionate open data advocates in the Transit Developers community: Brandon Martin-Anderson, Jehiah Czebotar, Dave Peck, and Josh Livni, and put together a great resource in a few short weeks. (I also helped in an advisory role.)

The site has the most data about the US, but there’s already a bit of information about Canadian and Australian agencies. The site is also open source, and the team hopes that developers in other countries will help expand the site towards more global coverage.

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.

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.

Transit Developers is a discussion group for people who build transit applications, whether independently, or working for transit agencies. If that sounds like you, I encourage you to sign up and post about what you’ve been working on.

WhereCamp is an annual get-together for developers of geographical applications, and a good place to swap tips and meet other folks with big ideas. This year it’s happening this weekend (May 17-18, 2008) on the Google campus in Mountain View, CA. I know that there will be several people who work in the transit field there, including Bibiana McHugh and Mike Gilligan from TriMet and Aaron Antrim from Trillium. I hope to see more of you there!

• Mike Smith, Director of Engineering at NextBus, urging transit developers and riders to rise up and demand a bus-tracking API from NextBus and its client agencies. What are we waiting for?

• Seeing so many local agency folks realize how they could make good use of the energy and ideas of indie transit developers, simply by being willing to talk to them (rather than reflexively trying to shut them down).

• On the flip side, seeing transit hackers and activists learn about the challenges and constraints that the agencies are fighting as they try to offer better service.

• Having the chance to give a talk with Chris Messina and Bryce Nesbitt about transit mashups from both inside and outside agencies. As the first morning progressed, we realized that our planned talks all worked into the same message, so we rejiggered things so that my lightning tour of the third-party sites on the wiki led right into Chris’s story of how IamCaltrain got built in 24 hours, into Bryce’s point that even more things would get built if more transit agencies would share their information with developers in a reusable format.

• Seeing people brainstorm cost-effective ideas to help agencies with their problems (like getting local design schools to help improve BART signage).

• Hearing that the MTC was planning to provide a feed of regional schedule data in machine-readable format.

• Working with a mix of hackers and agency folks on a lightweight transit service alert (micro?)format. Bryce set up a group to continue the discussion.

• Getting to meet so many progressive-minded agency folks and transportation hackers, some of whom I only knew from email (like Aaron Antrim), and others that I was meeting for the first time (like Mark Simon and Logan Green). The event was such a blur that I wish I had gotten more cards. Don’t hesitate to shoot me an email!

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.

Saturday is structured with pre-planned talks to help bridge the gap between the transit agency and web 2.0 worlds (I’ll be giving a talk about mashups from both inside and outside of agencies). Sunday will be the traditional self-organizing BarCamp day–any participant can sign up that morning to give a talk.

I’m hoping that this will be a good chance to meet more of the local transit hackers (and agency staff) in person. If you’re going to be there (or at this week’s APTA TransITech conference in Anaheim), drop me a line!

Bay Area residents in the late ’90s were well-served by the Bay Area Transit Information Project (Internet Archive link), a student project which eventually morphed into the official 511.org that we use today. This effort inspired others like the SoCalTIP page for Southern California transit.

Chris “aka Wad”, who writes for the excellent MetroRiderLA blog, was one of the co-founders of SoCalTIP, and he agreed to answer a few questions about the old days:

When was SoCalTIP launched, and when did it finally shut down?
SoCalTIP was launched in 1996. After a little under a decade, Ray Mullins and I decided that it was just far beyond our capabilities, and the site just faded away. The domain name lapsed in 2004.

How did it originally get started?
It was inspired by the Bay Area Transit Information Page, which started in 1994 or 1995. That was created by two college students as a thesis project. Ray helped them out with their efforts.

Southern California had a similar need. We have about a hundred different transit agencies, each maintaining its own information center. Since there’s no centralized information center in Southern California, it was up to transit advocates to provide one. We did, and we gave most transit agencies their first online presence. The BATIP template was carried over for SoCalTIP.

What features did SoCalTIP offer at its peak?
SoCalTIP’s most valuable asset was having the schedules in one place. It listed every transit agency from San Luis Obispo and Kern counties to the north, San Diego and Imperial counties to the south, and Las Vegas to the east.

We also kept the most simple site design possible. We didn’t use a lot of graphics, all of our schedules were fixed-width (Courier) plain text, and everything was easy and ready to find.

Many people had requested us to build a transit planner, but this would have been way beyond the capabilites of a volunteer site. Instead, we offered routing advice via e-mail, and the routes we came up with from our heads could beat computer-generated routes any day.

Who were the people who were most involved with creating and maintaining the site?
It was a collaboration of several people, but full-time, I typed schedules and was the public face of SoCalTIP while Ray maintained the server end.

What kind of maintenance did it involve?
The upkeep on such a simple site actually involved a lot of maintenance! When I typed up schedules, I would have to include some code for Ray to put it in his textproc program. He then had to put it in a format that the SoCalTIP server (Unix) would like.

Eventually, this led to a backlog of schedules that Ray was never able to process.

What kinds of discussions did you have with the agencies themselves, if any?
I had many discussions with most of the transit agencies listed. More often, they were cooperative and helpful. A couple would send me schedules ahead of time to get them on the site before they went into effect for the public. Some offered to give us the raw data. A few agencies even provided links.

The transit agencies were very encouraging with our efforts. We did not get any resistance.

Did you have any kind of database software generating the site, or was it all created by hand?
Ray created special programs to take initially Word, then Excel, files and turn them into properly formatted plain text for the web. I am not a programmer, so I don’t know how these worked.

Initially, I hand-typed schedules on Word. When I had access to Excel, I figured out a formula to calculate headways, and I could get done in minutes.

How closely did you work with the creators of the Bay Area TIP?

Ray lent his expertise to BATIP, and transplanted the idea to Southern California.

What finally caused SoCalTIP to shut down?

Ray’s full-time job as a programmer did not leave him much time to maintain SoCalTIP on the side. I did not know enough programming to maintain it on my own. Plus, the backlog became so large we probably would not have caught up, ever. This was before Wiki, which would have made SoCalTIP last longer.

Who knows, it may come back.

At first, the map looks like your standard Google Maps transit mashup, albeit one with very nice custom tiles:

However, when you zoom in, you really start to see what a labor of love this has been for developer Will James and his collaborators:

The map has detailed underground footprints of every station in Manhattan and many in the other boroughs, complete with red staircase icons marking all the entrances. This information was collected by the community: according to Will, “visitors to the map have gone out and photographed many of the subway entrance and exit maps at the real stations and sent those in so I can illustrate them and include them on the map. The illustrating work for Manhattan was all done by Jared Schneidman who volunteered to do the work.”

But that’s not all: recently Will has integrated a wiki system for filling out station information like transfer information, service advisory links, and accessibility.

I’ve wanted to see something like this for a long time–it’s hard to manage this sort of metadata, so it’s great when motivated users can contribute or correct information based on their local knowledge. I’ve been watching the edits since the effort was announced last month, and there’s been a steady stream of improvements, mostly coming from Will and a couple other users. (It’s possible that the wiki syntax is a barrier to casual edits, or perhaps the feature isn’t visible enough yet on the site.)

onNYTurf’s map is so good that they’ve even syndicated it to a few other sites, including a bar guide and dance music event guide.

Keep up the good work, Will & co.!

See Also: onNYTurf entry in the Headway Wiki.