http://www.trulia.com/local#commute/new-york-ny
DC actually seemed like it went the opposite way as it usually takes an hour and a half to get from VA through the beltway into DC while the map showed only an hour for as far out as Dale City. A half hour (or more) from Petworth into Downtown during rush hour is fair, since DC has probably the slowest crappiest drivers in the nation.
Updated theory: these commute times might not be based on actual driver data, it's probably a very rough estimation based on distance, travel time, speed limit, and population. It needs to be weighted based on the curve of traffic based on time and the way locals drive. Boca commuting will probably be slower than Miami commuting on average, unless you're on the highway in which case you're totally screwed in Miami. Not to mention anywhere there's an on-ramp with lots of flow you're going to make a choke point, so times would increase a lot, unless you started after that exit.
tl;dr Traffic is hard.
P.S. Hi from Bedford, MA. :)
EDIT: The only time it has taken 30 minutes was when I had to wait on two trains.
Also, not related to the commute times, but the crime rates look strange. At least, it's showing Arlington, VA as almost completely red (very high crime). Maybe the data is right, but that would be surprising for one of the richer, more yuppified areas of the US.
And i'm not trying to give them a hard time, really. It's a neat visualization. But for me, practically, I couldn't use this to tell actual commute times, and I think that's apparent based on the other comments on here. You want my opinion? They should crowdsource taxi drivers. Who else would have a better idea what the traffic's like at any given time of day?
If you are going to measure the distance and use that as a basis -- just report the distance. Otherwise, the estimates based on time will just flip the bozo bit in your customers.
Also, every route seems to be treated the same. In the morning, the road I live on is always empty in one direction and congested in the other. I used to commute against traffic and now go the same way as everybody else, and I could go twice as far in ten minutes as I can now. The numbers will never be accurate until you ground them in real traffic data.
For example, Beaverton, OR, into Portland. Where I live it's at most, even at rush hour, 15 minutes to one of the two freeways near my house and this is estimating 30-35 minutes. The entire (house -> downtown) calculation is close (about 45 minutes downtown) but only for rush hour. Other than if there was an accident on I-5, there isn't a possibility of taking 50-55 minutes to get from my house to Tigard or Tualatin without spending 30 minutes lounging at Starbucks along the way.
Looking at the data a little more, surface streets seem to simply be an estimate outward radially, with what appears to be very little taken into account otherwise. The freeways seem to be good, educated guess estimates.
That said, it's not too far off, and useful for when we buy a home.
Great work. I checked commuting time for Seattle, WA using public transit and most of your visualization are spot on. Is the public GTFS files you are referring to come from here: http://code.google.com/p/googletransitdatafeed/wiki/PublicFe...?
With regard to some of the earlier replies saying that the map is inaccurate, it might be worthwhile to use Amazon Turk to run some evaluation on how reliable the spatial data (or your algorithm for calculating travel time, rural vs local, .etc) is.
-Sen
However the main problem I have during my real estate search has nothing to do with UI. It seems like for every home I find through the site that I contact a realitor about the home is already "under agreement". If your site could find a way to be more up to date about those things, it would really stand apart.
This isn't a website to tell you your exact commute time. If you want that, try Google Maps.
This is to show you roughly estimated travel times in all directions when you're looking at purchasing real-estate. And I think it works very well for that.
The maps you've added are awesome when you know where you're looking at, but if you don't yet have a place picked out then knowing where to look is good too.
A naive way to compute the kind of summary map I'm interested in is to just make the color at each point on your summary map be the average color on your map for a specific place. Something smarter could weight points by their desirability (I care more about how fast it is to downtown than to an arbitrary point in a suburb) but the naive version is pretty useful on it's own.
It's more of a backend question, but what algorithm are you guys using to traverse the maps?
Also, why did you decide to use Google for the display maps, when you used OSM for the backend calculations?
The times are calculated with a simple Djikstra's traversal, implemented in the open-source pgRouting (pgrouting.org)
Our existing local information pages were already using google maps, so we didn't go out of our way to create new base maps just for this visualization.
For example, from downtown Kirkland, WA. You have the bus being faster than driving, there is no HOV lane that would explain this, my real commute choice is driving (10-15 minutes) or bus (35-40 minutes) but your heat map pretty much inverts those numbers.
so that it is normalized by population density? Otherwise it's completely misleading and uninformative.
For commute, our heatmaps are rendered in canvas, based on JSON data from our servers. This allows for the efficient slider.
We also have static image tiles, for certain (ahem) browsers that don't support canvas. The downside is that they can't use the slider.