Where's the Next Bus? I'll Tell You

When New York City released real-time bus info for a Brooklyn line, one of my colleagues wasn't happy.

Yes, she could use a smartphone to see buses on an MTA map. Yes, she could get location information by texting the code for her stop (she lives near the route). But none of this was simple enough.

"I want a phone number that will TELL me when the next bus is coming," she said.

I'll have it for you by the end of the day, I replied.

It was a bit of a gamble. More of a challenge to myself, really. But if "before midnight" counts as the end of the day, then I succeeded. Try it:

Dial 646-480-7193. When prompted, enter 308333 or any of the bus stop codes for the B63 line.

It's not journalism, but it is a working example of how someone can take public data and turn it into a useful tool, quickly. And at almost no cost.

How I Did It

First, I wrote a little program in Sinatra that sends a 6-digit bus stop code to the NYC Metropolitan Transit Authority API -- or application programming interface -- whenever someone hits my program's web address. (The API is a public portal to the live bus data. All you need is a little programmer know-how and a free key from the MTA. The technical details are right here.)

The API sends back 77 lines of information about the stop and the buses approaching it, including the one detail I want:


The next bus is three stops away. I use a Ruby tool called Nokogiri to find and extract just this number, which I drop into an amazingly simple web page. The page's entire output looks like this:

The next bus to arrive at 14th Street and Fifth Avenue heading north is 3 stops away.

That accomplished, I bought a phone number from Twilio for $1 a month, and $0.01/call. Twilio provides a telephone connection to web-based programs, which I first heard about during a demo at a TimesOpen event

I set my new phone number to hit my program's URL whenever someone calls. By wrapping the text in special tags, Twilio recognizes it as a cue to talk:

The next bus to arrive at 14th Street and Fifth Avenue heading north is 3 stops away.


I later used Twilio's <Gather> tags to build what's essentially a web form to capture digits entered on a phone for any bus stop. I also added error catching, for when no buses are coming, and programmed it to announce the location of the following bus if the next bus is arriving.

Some Hiccups

Turns out that Twilio reads text a little too fast to be understood on an NYC street corner. So I rewrote the output to introduce pauses:

The next bus to arrive at ... 14th Street ... and ... Fifth Avenue ... heading ... north ... is ... 3 ... stops ... away.

Also, there's a bug in the API system that sends back server errors in certain conditions. Word is that the MTA has actually fixed this on their development servers, and that fix is being pushed to the public system pretty soon. 

More to Come

I have a few enhancements up my sleeve, which should be done in a week or two. If you'd like to know when new tricks roll out, drop a note with "Bus Talk" in the subject line to john (at) johnkeefe.net. I'd love to hear your thoughts on how it could work better, too.

I'll also release the source code after those nifty updates. Let me know, too, if you're interested in that.

Photo by jbrau13 on flickr.

2 responses
This is great, an app like this is screaming for voice recognition though! I did something similar for the BART system in the San Francisco Bay Area:


Where you may actually speak the station instead of having to remember some phone keypad code combinations. Also, with Phono, things may get really interesting too:


Great to see the #opengov stuff get consumed!

Great project, great app!

I'm a bit of a transit app developer myself, having written a series of blog posts about a transit app I wrote for my home state of Delaware - http://www.voiceingov.org/blog/?p=2165. Although, right now I'm stuck with static scheduling info., no real time transit data where I am. Yet. ;-)

I work for a company that provides a similar service, but with lots of nifty benefits that you won't find with Twilio (or any other cloud telephony provider for that matter).

For one, my company (Tropo) support speech recognition in phone apps, a nice benefit that you can provide to users with very little additional app logic.

Also, you can use your same application code and deploy to multiple communication channels - Phone, SMS, IM, even Twitter. I used SMS and IM for my transit app. project.

Finally, with Tropo you have the benefit of mashing up your app with some of our other cool tools, like Phono. I used the IM channel on my transit app and mashed it up with Phono and Google Maps to build http://findthebus.com.

Give it a whirl with a Delaware address (e.g., 320 Rehoboth Avenue Rehoboth Beach, DE 19971 - this is the address to the Dogfish Head Brewpub and Restaurant in Rehoboth Beach).

We don't charge developers for apps that don't run un production mode, and phone numbers are free for developers. If your intent is to share your code and provide a demo app that others can learn from, I think you'll find the cost of using Tropo much better than any other provider.

Once again, hats off on a great project. If I can provide any additional info, please feel free to drop me a line.

Mark Headd