Improving on TrafficTweet

... the last thing we need is more drivers texting on their cell phones. The traffic had better be at a dead stop first!

Hey, Mariae -

It seems like this thing just broadcasts whatever people send it, right? (I'm scared to try because I don't live in NYC so I couldn't give any real info).

Exactly right -- the way that this currently works it's just a simple repost, so it just takes whatever people input via Twitter and outputs it to its own timeline.

Is there a way that you could make it so that if I send you a certain message, it sends back all the traffic tweets from about the last hour or so? That way I'm not getting tweets about traffic all day long, but when I'm ready to go somewhere, I can see what has been happening recently.

I think that you're looking in the right direction. Even just within NYC, you're only interested in traffic information for certain areas at certain times, so each user really wants a personal filter in the way that you describe.

It could definitely be done. For one simple approach off the top of my head, you could take advantage of Twitter's direct message functionality: when you want traffic updates you send a message to the bot like...
@traffictweet recent
...and then the bot sends you all the updates as direct messages, so that only you are seeing them.

It gets more interesting if you add additional functionality, but I think this could be a great start (though it'd need more data coming in to be really useful).

I wrote the original code for this, so I'll see if I can make some time to rough out a version like this. If anybody else is interested in working on it feel free to let me know--I'm happy to share whatever background knowledge I can.

Absolutely happy to share!

You can grab the source code and read through the setup information here: http://bit.ly/DwAu

It's a pretty simple script--you need to have some basic technical skills to get it running, but by no means do you need to be a wizard. :)

1. doesn't google already give you traffic conditions on you gMaps? we do in SF.

good point - is there an API for that data, and is the data fresh?  if so, that would be easier to get and more reliable than data that was input by users.  though if not, it doesn't do much good in the moment when you're trying to make decisions.

Looking into the API question, I see this post: http://googlemapsapi.blogspot.com/2007/06/add-traffic-to-your-mashup-button.html  that talks about a map overlay call for traffic info, but I don't get the sense that could be abstracted to tell you what routes were less busy than others.

instead of tweeting traffic conditions, why not just have an app that transmits your Lat/Long every 30 seconds or so and thereby shows speed over time on any given street.

See Seth Godin's Challenge.

I think the general takeaway from your comment is that if up-to-the-minute traffic data can be obtained in any sort of automatic, programmatic way, that would be easier and more reliable than asking users to input the data themselves.  I think that's right, I just don't know if it can at this point.  Data input from users might still be the easiest place to get started right now.

While the whole signing up on a webpage idea is not bad, it limits some flexibility on the user's end (what if i want traffic info outside my usual commuting times?) and it also seems overly complicated. Maybe one day the resources will exist at DIYcity to build a traffic bot this comprehensive, but i think we need to start simple.

As for using the Google traffic API (if that's even a possibility), i don't think that it's a bad idea, but i do think it takes away from the DIY nature of the project. Part of what really attracts me to the DIYcity project is not the end functionality (because if i want a traffic report that bad, i can turn on my radio and find one in 3-4 languages) but rather the sense of community interaction that is enabled by technology.

By building a twitter bot which gathers its data from anyone and everyone, we are using technology an open source ideals to reconnect people who have been sitting alone in their Lexus monads listening to Sunny 95 for the traffic report. Suburban sprawl and TV and a million other things have slowly eaten away at the sense of community in our cities, and even though a Google API might be more expedient, it wasn't hand-made by the people of my community and so it just doesn't have the heart i'm looking for in a traffic report, dammit.

< /ideological rant > (for now)

Great thoughts on the homegrown, community aspect of the potential project.  I was trying to sketch out a future case with functionality that could be built in a few weeks or months depending on who's interested in working on it. Alas, I'm no developer/programmer. 
I think using twitter for community traffic updates is convenient but ultimately limits it to a demonstration project because so few people are twitter users (relatively speaking).  I'm not saying we shouldn't go ahead, just something to think about.
So continuing with the twitter bot idea, we should at least consider expanding it to a few bots for different geographic areas/corridors. I'll bet any reports done for the congestion pricing plan would have good analysis on commutersheds.

What would keep me from using it? The fact that, being a New Yorker, I don't drive. What we need is a twitter feed or bot or whatever for the MTA - now that I would use. Crowd-source those sick passengers, signal problems, police investigations, etc. With a little pattern matching, you could have custom feeds for the various lines.

Also, your captcha needs a list of stop-words. It invited me to enter an epithet.

Seems there are three areas here:
1. Gathering traffic information
2. Analysing it and extrapolating
3. Distributing it in a relevant way to users

I'd suggest focusing on distributing the data rather than gathering or analyzing it. The former holds a lot of untapped potential, and the latter have already been done well enough to avoid competing with (for now.)

Dan Greenblatt's, Mariae Mancipium's and whitneymcn's suggestions are good because they focus on where we can immediately benefit the most.

There is an accurate traffic flow model by Dirk Helbing and others, and I imagine Google and other traffic tools already use this to make predictions and also to estimate problems in other places. For example, if traffic is slowing down and becoming more dense at point A on a highway, it is likely there is a more substantial slowdown, or even a jam, forming 1 or 2km ahead. With exact data, these can be predicted with enough accuracy for users to plan the right route. (AFAIK these models can work in real-time.)

This may present an opportunity, as combined with crowdsourcing, it would create an open platform for other open services, per Adam Greenfield's vision. Applying the Helbing model to data from users who are constantly updating from GPS could yield some very accurate extrapolations. Though, there is one thing missing: predictive models for traffic require vehicle speed AND traffic density. It's a bigger project, but if we could pick up traffic density data and apply it to a predictive model, we'd have a free, open traffic system.

If we can't do that, distribution is shining strength of this project, so I'd stick to distributing existing traffic data in better ways.