Traffic (and cars more generally) are a particular interest of mine - both the algorithmic component (path finding and navigation) and the behavioral/mechanical side (see here). Today, Google announced that they are now crowdsourcing traffic data in Google Maps. This represents a fantastic use of technology, and one which I've often wondered why no one has done sooner. Google certainly wasn't a firm I expected to take up the challenge, but their solution may just do the trick.
Current traffic reporting relies on an observer and a reporter - someone has to see a traffic jam, consider it worthy of attention and relay that information to the reporter, who in turn broadcasts the news to a curious audience. Recent advances have included cameras acting as observers (though someone still must monitor their output) or the use of automatic car-counting devices (lasers and rumble strips). Moreover, automated traffic reporting services have emerged, some even integrated into automobile navigation systems. To the extent that data is reliable, it can be used to readjust planned routes on the fly - but that requires good information on the traffic intensity and area covered, as well as rapid refreshes. With the exception of major interchanges, such information isn't always available.
Google's new plan may change all that. Instead of relying on an observer/reporter model, they are integrating the measurement directly into the system. With your permission, Google will monitor the location of your GPS-enabled phone and use that information to collect speed data. No longer does someone have to observe a collection of slow-moving vehicles and decide whether or not it constitutes a "traffic jam" - Google will know exactly how fast any car is travelling at any point. The measurement of traffic becomes objective and endogenous.
With this knowledge, the fastest route can be determined easily - and it may extend beyond merely locating traffic jams. One of the biggest drawbacks of current navigation systems is that they often make simplistic assumptions about travel speeds. Frequently, 65 mph is used for highways and 25mph is used for all other roads. If you travel at a different speed, even for a short period, it could dramatically impact your ride versus the navigation system's assumptions. Google, by contrast, will know just how fast you can go at any point on the highway. Combine that with a little intelligence about how you tend to drive as compared to other drivers (or even without that insight) and you should end up with a far more accurate estimate of travel time. Moreover, a slow-but-not-stopped highway might be skipped in favor of a lightly-traveled back road - an outcome at which traditional navigation systems would never arrive.
The only worry I have is what happens when the system is applied to an area where it is difficult to discriminate between roads, lanes, or sidewalks. GPS isn't precise enough to determine whether someone is on a street or a sidewalk. Perhaps the massive amount of foot traffic on 42nd street will show up as a permanent traffic jam (though, to be fair, that would be accurate). Conversely, Some clever data-skimming could get around this issue, however: if there are enough fast-moving points to be confident they aren't outliers, only use those points for the traffic network.
Alternatively, Google could leverage its existing partnership with various metropolitan transit authorities to collect information from buses. Finally, cab drivers could try to sell their locations to Google, as they would provide sustained and reliable urban datapoints. The cabspotting project by Stamen illustrates what that data would look like: