Orphan Road

Check it out here. I like the interface: clean, simple and optimized for mobile devices. I've been using this one for a few months, and it's okay, but takes forever to scroll down to to the stop you want. I think organizing the data primarily by bus, rather than by stop, makes more sense, at least for my use.

I like the intuitive appeal of "I'm at this intersection, what buses are coming my way?" But in practice, there are just too many intersections for the interface design. And most of the time you're probably really only interested in one or two known buses.

(via)

Thanks to those people that have gotten back to me already. Some people have said that the most useful thing would be information at the bus stop. This is an example of what that could look like.

For all you commuters out there, check out Commuter Feed, which aggregates SMS updates about traffic incidents via Twitter.

Not much going on in the Seattle feed yet, but once it gets rolling, it could be pretty useful.

While we await true real-time bus information at all our Seattle bus stops, consider the lazy option, instead of getting frustrated because the 48 or the 7 is taking forever.

Dadnab is a service that offers text-based trip instructions to your cell phone. It looks pretty handy. Just TXT seattle [at] dadnab.com.

Blogger Jeff Jarvis has a worthy follow-up to my post today about smart transit. Jarvis writes about a particularly grueling commute into NYC:

There were thousands of people in that jam. We all knew what was going on and could have informed the thousands more who followed into the same trap. And I’ll be most of us would have done that out of sheer altruism, in the hope that someone else will help us avoid the next jam. Why have we not yet invented systems to capture and share that knowledge? I’ve been plotting this for years: I met with these and other traffic services a decade ago begging them to come up with the means to gather our knowledge of traffic: We could call into numbers that have logged our usual routes and report our conditions and get the conditions ahead. Or we could set up the means to monitor and report the movement of those phones along routes and cell towers. Or we could simply enable people to call a service and leave trouble reports. Anything. But, no, we knew nothing.

This isn't limited to transit riders, either. When GPS-enabled cars hit a traffic jam -- or even when they just notice that the driver is hitting the brakes an awful lot -- the car should upload that information to a server or a peer-to-peer network, so that other cars can aggregate the information and plan routes accordingly. The fact that we're still waiting for the AM radio's 10-minute traffic updates in this day and age is absurd.

Cascadia Prospectus reports that there's a new study underway to change the way real-time bus info is captured. The current system involves having the bus pas a series of mileposts, which doesn't work too well in crowded areas or when the bus has to divert its route due to construction or snow. The new method would involve GPS and/or Wi-Fi, which "would vastly improve the tracking in the urban area."

Another part of the study would involve counting passengers. Perhaps the algorithm somehow uses the number of boardings to determine how many stops the bus will have to make, and uses that to calculate the arrival time.

This makes it clear just how tricky real-time bus information actually is to implement. With a train, it's relatively straightforward: trains don't get stuck in traffic and make regular, predictable stops. But even the most sophisticated GPS bus system can only tell where the bus is right now and then make a guess about how long it will take to close the distance between the bus's current location and yours.

In most urban areas, though, that's probably enough if you're a regular commuter. If the system can tell me that the bus is still a half-mile away, I can make a reasonable guess about when it will get to my stop. Also, if I have the option of taking the local or waiting for the express, all I need to know is how far behind the express is relative to the local. Exact times don't really matter.

CP also points to this 2003 P-I article on the Mybus pilot program in North Seattle, which goes deeper into the local v. express dilemma.

Following up on Matt's post about NextBus, it looks like the burgeoning transit-planning space is getting a new entrant, HopStop, which covers NY, SF, and DC, among others (but not Seattle, alas).

The cool thing about HopStop is that they're providing a free API, which will let transit-geek sites like ours provide a custom interface and feature set. Come to Seattle, HopStop!

The logical evolution for these sites is toward mobile phones, of course. That's where the action's going to be in a few years.

Hot off the presses. Transit information system NextBus will be coming to Seattle.

According to my sources, the soon to be completed SLU streetcar will incorporate NextBus technology.

Unlike Metro's homegrown MyBus (and the equally homegrown BusMonster), NextBus is already being used by transit systems around the country, including BART, D.C.'s Metro, and more. They've got some really cool functionality, including an online form that lets you set up automated text messaging to alert you to the impending arrival of a certain bus or train. It's great stuff.

While I'm all about the "can do it" spirit that's gone into MyBus (and thanks, Google, for the funding), I have to ask Metro -- why build something from scratch when there's already a great application out there that does everything you could want it to do?

NextBus suggests that we write Metro and the city and county governments to encourage them to adopt their system. If you're interested, here's the Metro "comments" page: Metro comments.