Headway

I’ve been busy working on some things that I hope to be able to share with you all soon, but in the meantime, I wanted to mention a few things:

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!

Since I’ve seen surprisingly few wrapup posts about it (only Tara’s and Alexa’s), I’ll go ahead and say that last month’s TransitCampBayArea event was a real treat, surpassing the expectations of pretty much everyone that I talked to. Here are some of my highlights from the event:

• 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!

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.

Those of you in the San Francisco Bay Area this weekend should check out TransitCampBayArea, this Saturday and Sunday in Palo Alto. Following in the footsteps of similar events in Toronto and Vancouver, TransitCampBayArea is a “solutions playground” where the emphasis will be on how citizens can help improve the transit experience in the Bay Area via hands-on creative work. (In short, the kind of thing that I love to cover in this blog.)

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!

These days most every transit agency has some sort of online presence, but it wasn’t so long ago that the web was a curiosity known only to academics and those savvy enough to seek out early ISPs. Even at that early stage, the benefits of putting transit schedules online were clear, and so transit riders worked to fill the void.

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.

Of the 74 third-party transit sites collected in the Headway Wiki, one of the ones that I’ve been most impressed with is the onNYTurf Subway Map. This donation-supported mapping project, associated with NY blog/discussion site onNYTurf, covers rail and ferry lines in the New York metropolitan area.

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.

If you’re interested in simple ideas that can improve the transit experience (likely if you’re reading Headway), the Permanent Campaigns Consulting blog is a great resource. Permanent Campaigns’ business is helping agencies communicate better with their riders (with the intent of increasing ridership), and their keen understanding of the landscape shows through in their consistently insightful posts. For instance, their New Year’s post has some great ideas on how to improve the new rider’s comfort and dignity:

Consider a new rider venturing onto a bus for the first time. She is unsure of the route. Perhaps she’s unsure of the fare. The bus driver, who after all is driving a bus, doesn’t have much time to hand-hold and guide the new rider. She feels a little bit like she just got on a roller coaster and hopes that it goes the right way.

How can we give her more control?

We can make sure that every single bus has a route map. Without exception.

We can include a first-time riders sheet to distribute on every single bus. Without exception.

We can distribute a new rider hotline number with specially trained call intake personnel who can guide a new rider and talk them through the experience of a new bus ride while they are on their mobile phone (”I don’t know where I am or where I am going! Will this bus go to X?”)

We can cultivate a volunteer organization of frequent riders to help new riders. These volunteers can wear buttons or T-shirts and when they see new riders, offer to help. Maybe the volunteers get a free pass or some other recognition for their efforts.

Keep up the good work, guys–hope the agencies are listening!

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.

One of the reasons why buses are sometimes less pleasant to ride than trains is that they’re much more likely to offer a jerky ride. This probably has a lot to do with the traction afforded by rubber tires and the unpredictability of the street traffic that buses travel in. Either way, when you’re on a sideways-facing hard plastic seat, or standing on a crowded vehicle without a convenient handhold, the net effect is that you might become better acquainted with your fellow riders than you’d like.

While some of the jerkiness can no doubt be chalked up to the vehicle, in my experience some drivers definitely have a lighter touch than others. Why not reward the attention paid by a conscientious driver to the quality of the ride? A simple accelerometer in the AVL package would likely be enough to figure out who was doing a good job. (There’s at least one company, Road Safety, selling this type of hardware for first-responder, commercial fleet, and of course anxious parent applications.)

Rather than using this system to punish careless drivers, it’d be be better (if more costly) to offer incentives for a driver to opt into, and perform well in, this type of monitoring. In some ways, this would be similar to the pilot programs that Progressive Insurance has run in which private drivers can choose to have their driving behavior recorded in exchange for reduced insurance charges. This way, it can preserve driver dignity at the same time that the smoother rides improve rider dignity.