I never understood why this hasn't been done yet by others. With all these network connected GPS receivers driving around, it wouldn't take a large percentage of them to contribute to a service that shows the actual current speeds on roads around metro areas. This data then is aggregated and distributed to other users to allow for efficient use of the roads. The sources of the data can be paid, even, or given an otherwise expensive mapping app+service for free. Maybe some app developer out there is already working on this, but it seems like an obvious thing.
There is an app that does it. Someone showed me the other day. Can't remember what it is. It's like Trapster but something else. You leave it running in the background, it's a social thing, so when it detects fellow users in the locale slowing down they mark roads as having slower traffic.
It's easy to get an app for everything. Remembering what it's called, is another task altogether.
I never understood why this hasn't been done yet by others. With all these network connected GPS receivers driving around, it wouldn't take a large percentage of them to contribute to a service that shows the actual current speeds on roads around metro areas. This data then is aggregated and distributed to other users to allow for efficient use of the roads. The sources of the data can be paid, even, or given an otherwise expensive mapping app+service for free. Maybe some app developer out there is already working on this, but it seems like an obvious thing.
It's been attempted many times over the last 10 years and is currently being worked on by at least 9 companies that I know of.
The primary difficulties are you need a very large number of devices and/or you need a large amount of bandwidth to send data back to a central processing location.
For good quality traffic you need a minimum of 2% of all the vehicles on the road though the usual threshold is 5% of the vehicles for reliable accuracy. Since at most 10% of the population is traveling at any one time, that means you need an installed base of 20-50% of the total population. That's a LOT of devices. None of the attempts to date have come even remotely close to the necessary number of devices.
Even with available devices, you need to aggregate the data in a central location. If the phone is running your app (maps or something similar), the app can deal with aggregating the locations, determining the roads and speeds, filtering stationary and pedestrian movements, and sending only very condensed usable information back to the data center. But then you need not just 2-5% of the traveling phones, you need those phones to be running your app at the time. That's probably never going to happen but it's the only approach available to an individual app developer.
If you are going to aggregate anonymous locations from many, many phones running many apps, then the amount of data sent over the air is very large. There is considerable impact on battery life as well. Collecting those locations specifically to generate traffic information costs considerably more than the value of the traffic information.
However, if the locations are sent as part of normal operation, as all "location aware" apps do, then the incremental cost of using the locations for traffic is tiny. This is the approach that Google and almost certainly Apple are using. This approach is only available to the phone OS makers as they can build it into the location services layer of the OS and into the back end support for those services.
It will take a few more years but reasonably high quality crowd sourced traffic will get there. Google, Apple, Rim, and Nokia are all working on implementing it now. Microsoft almost certainly is but will need a much larger installed base. The carriers have been toying with it for a decade but have dragged their feet so long that they will get completely bypassed by the phone OS makers. The current information is junk but we're approaching critical mass and the smartphone growth curve means it will improve quickly.
Actually, it's Apple that could be accused of doing the copying:
From the Wall Street Journal, 4/22/2011:
"Google also has said it uses some of the data to build accurate traffic maps. A cellphone's location data can provide details about, for instance, how fast traffic is moving along a stretch of highway."
I've always wondered how Google got traffic data on so many streets. I found it hard to believe they all had sensors embedded in them.
More lame AppleInsider reporting to even think they are talking about network traffic, but admittedly, the press release could have been more clearly written. Apple is probably a bit upset that their hand in working on their own mapping/navigation has been shown.
Neither of them are original and I doubt that they are claiming they are. There was a cluster of attempts in the 1999-2002 timeframe. There was a second wave of attempts around 2005-2006. The current crop of contenders started around 2008 but are based on the earlier work.
Plus, it would be nice not to need to use Google Anything.
And, really, Google Maps is not that great, especially when it comes to directions. Especially their public transit directions can be laughable.
I had to get to over 50 different locations in four boroughs of NYC in 30 days two years back, and GMaps turned me into a subway and bus ninja - never got lost once on any of the trips. The pre-smart phone era for me: I printed the relevant info from a PC before starting out and didn't attempt to use it to predict when subways or buses would intersect each other nor when I would intersect them, but for mapping out workable, complicated routes it was great other than not knowing about a few construction projects.
Quote:
Originally Posted by cameronj
That seems like the easiest of imaginable problems to solve, really. We're not talking about one data point, we're talking about dozens hopefully, and I think a sophisticated TI-82 could eliminate moving data points which never go faster than 5 MPH, essentially never stop except at intersections, and aren't ever located approximately near the middle of the road. GPS is accurate enough for that.
Plus the main benefit of such a service wouldn't be for crowded city streets, it would be for commutes though highways and local streets where bypassing an accident would save you a ton of time.
Maybe not quite "the easiest imaginable" problem to solve.....
[note: emphasis supplied in quoted post below]
Quote:
Originally Posted by felipur
It's been attempted many times over the last 10 years and is currently being worked on by at least 9 companies that I know of.
The primary difficulties are you need a very large number of devices and/or you need a large amount of bandwidth to send data back to a central processing location.
For good quality traffic you need a minimum of 2% of all the vehicles on the road though the usual threshold is 5% of the vehicles for reliable accuracy. Since at most 10% of the population is traveling at any one time, that means you need an installed base of 20-50% of the total population. That's a LOT of devices. None of the attempts to date have come even remotely close to the necessary number of devices.
Even with available devices, you need to aggregate the data in a central location. If the phone is running your app (maps or something similar), the app can deal with aggregating the locations, determining the roads and speeds, filtering stationary and pedestrian movements, and sending only very condensed usable information back to the data center. But then you need not just 2-5% of the traveling phones, you need those phones to be running your app at the time. That's probably never going to happen but it's the only approach available to an individual app developer.
If you are going to aggregate anonymous locations from many, many phones running many apps, then the amount of data sent over the air is very large. There is considerable impact on battery life as well. Collecting those locations specifically to generate traffic information costs considerably more than the value of the traffic information.
However, if the locations are sent as part of normal operation, as all "location aware" apps do, then the incremental cost of using the locations for traffic is tiny. This is the approach that Google and almost certainly Apple are using. This approach is only available to the phone OS makers as they can build it into the location services layer of the OS and into the back end support for those services.
It will take a few more years but reasonably high quality crowd sourced traffic will get there. Google, Apple, Rim, and Nokia are all working on implementing it now. Microsoft almost certainly is but will need a much larger installed base. The carriers have been toying with it for a decade but have dragged their feet so long that they will get completely bypassed by the phone OS makers. The current information is junk but we're approaching critical mass and the smartphone growth curve means it will improve quickly.
Enjoyed this post. Seems a good description of "the mapping landscape" for "traffic"....
That link is to the Dutch app store. While INRIX may be using crowd sourced data in the Netherlands, it isn't in the US. At least to any large degree. INRIX data is aggregated primarily from government sensors supplemented with truck fleets and predictive algorithms.
Apple is talking about something quite different or at least something based much more heavily on crowd sourced data rather than primarily sensor data.
I'm sure the INRIX app works reasonably well. Sensor data is very good, where it's available. Google and Apple are interested in generating their own data both because it gives them a competitive advantage (government sensor data is available to everyone equally) and because it gives them data on surface streets where there are no sensors.
About a year ago Google started providing traffic data on lots of surface streets rather than just freeways. All that surface street data is generated from cell phone movements. That's the data that Apple wants to start producing (as well as for areas where there are no freeway sensors, ie rural areas).
It's been attempted many times over the last 10 years and is currently being worked on by at least 9 companies that I know of.
The primary difficulties are you need a very large number of devices and/or you need a large amount of bandwidth to send data back to a central processing location.
For good quality traffic you need a minimum of 2% of all the vehicles on the road though the usual threshold is 5% of the vehicles for reliable accuracy. Since at most 10% of the population is traveling at any one time, that means you need an installed base of 20-50% of the total population. That's a LOT of devices. None of the attempts to date have come even remotely close to the necessary number of devices.
Even with available devices, you need to aggregate the data in a central location. If the phone is running your app (maps or something similar), the app can deal with aggregating the locations, determining the roads and speeds, filtering stationary and pedestrian movements, and sending only very condensed usable information back to the data center. But then you need not just 2-5% of the traveling phones, you need those phones to be running your app at the time. That's probably never going to happen but it's the only approach available to an individual app developer.
If you are going to aggregate anonymous locations from many, many phones running many apps, then the amount of data sent over the air is very large. There is considerable impact on battery life as well. Collecting those locations specifically to generate traffic information costs considerably more than the value of the traffic information.
However, if the locations are sent as part of normal operation, as all "location aware" apps do, then the incremental cost of using the locations for traffic is tiny. This is the approach that Google and almost certainly Apple are using. This approach is only available to the phone OS makers as they can build it into the location services layer of the OS and into the back end support for those services.
It will take a few more years but reasonably high quality crowd sourced traffic will get there. Google, Apple, Rim, and Nokia are all working on implementing it now. Microsoft almost certainly is but will need a much larger installed base. The carriers have been toying with it for a decade but have dragged their feet so long that they will get completely bypassed by the phone OS makers. The current information is junk but we're approaching critical mass and the smartphone growth curve means it will improve quickly.
I'd love to know why one user driving down a street out of every 100, which in most busy streets would mean one every 3-4 minutes I imagine, wouldn't be plenty to feed a database of street speeds. And yes, if you force yourself to have incompatible traffic databases, then that requires several users to feed multiple databases, but if one company performed the aggregating work for multiple different app vendors (like the way Navteq provided maps for many different map websites and services), then a user using app 1 on a droid and another using app 2 on an iPhone and another using app3 on a Winmo device would all be contributing to the same cache of data.
The post above is impressive in the amount of numbers it throws around, I just see no logical reason why, if 100 cars pass a given point in 5 minutes, 15-20 of those cars need to be passing data out. Logically it makes no sense that street speed can't be measured with far, far less.
I also question the claim that at most 10% of vehicles are on the road at any one time. Rush hour runs from 4-6 in most big cities. Surely you don't suggest that 90% of the people who live in those cities are not driving during rush hour in the morning and evening, do you?
I'd love to know why one user driving down a street out of every 100, which in most busy streets would mean one every 3-4 minutes I imagine, wouldn't be plenty to feed a database of street speeds. And yes, if you force yourself to have incompatible traffic databases, then that requires several users to feed multiple databases, but if one company performed the aggregating work for multiple different app vendors (like the way Navteq provided maps for many different map websites and services), then a user using app 1 on a droid and another using app 2 on an iPhone and another using app3 on a Winmo device would all be contributing to the same cache of data.
It's a statistical sample size problem. There is quite a lot of variability in traffic and you need reasonable sample sizes to get accurate results. If that one car gets stopped by a pedestrian or hits 2 red lights instead of 1 red light or whatever, its speed can easily vary between a 5mph average over some distance to a 30 mph average over the same distance. And a car 2 seconds ahead of that car may make the light and average 30 while the car right behind gets caught and averages 15.
If you only have 1 sample, your speed estimate will likely be way off most of the time.
Getting enough people to contribute to the same cache of data is the whole crux of the problem. This is why Google and Apple will be able to do it while previous attempts have failed. All location enabled apps on all iphones or all android phones will contribute to the traffic data cache. And that will eventually give a big enough pool.
Quote:
The post above is impressive in the amount of numbers it throws around, I just see no logical reason why, if 100 cars pass a given point in 5 minutes, 15-20 of those cars need to be passing data out. Logically it makes no sense that street speed can't be measured with far, far less.
I said 2%-5% which is 2 to 5 cars during that 5 minutes, not 15-20. And really that percentage applies to freeways which is what most of the research has been done on. For surface streets, those 5 cars are not going to yield very accurate traffic. I don't know what your logic says a reasonable number should be but think about driving along a uncongested freeway (which is an easy situation). You may see trucks going 50 in the right lane and people going 85 in the left lane. On a city street the problem is much worse with lights and parking cars and turns and so forth. You want to report the average speed, so you need some number of measurements to average together. Most people doing this kind of thing want 5%. More is better, less can give okay results but accuracy will suffer.
Quote:
I also question the claim that at most 10% of vehicles are on the road at any one time. Rush hour runs from 4-6 in most big cities. Surely you don't suggest that 90% of the people who live in those cities are not driving during rush hour in the morning and evening, do you?
Commutes are getting longer so it might well be more like 15% -20% at the peak now. I think the last statistics I looked at were for 2004. Bear in mind that rush "hour" is 2 or 3 hours long or more. If 6 people have 30 minute commutes during that 3 hour period, you may only have 1 of them on the road at a time even though all six travel during "rush hour".
But you also want traffic information for more than just the most congested period of the day and outside of that period the percentage will be lower. So the principle still applies, you need a much larger installed base than the sample size you need at any particular moment.
Well it'd be a lot better than the iPhones native google maps app. I mean the app is better than nothing, but it would be nice to see a better nav. app with voice turn by turn directions and voice to text. I think we would all appreciate that! That is if they made their own nav. app with those options
On the Android platform that's exactly what Google Nav offers. Voice control of the navigation app, traffic flow map overlays, favorites and navigation to Google lookups, spoken turn by turn directions, voice to text. . .
I don't know why they wouldn't have the same functionality on the iPhone, but assume Apple wouldn't allow it.
Not mentioned at all is upwards of 70% off all traffic delays can be predicted. The Washington Beltway is always congested at the same times every weekday. I-4 thru Tampa is always backed up in specific spots at 7:45 in the morning, Monday thru Friday.
A predictive/historical database can alleviate much of the need for active, real-time traffic flow reporting. That's the direction that TomTom/TeleAtlas and to a lesser extent Nokia/Navteq have gone with traffic services. Real-time traffic updates have been far from reliable due to a number of factors, some mentioned here. But good predictive data gathered from actual travelers over a long period of time can be highly dependable, particularly on major travel routes in the largest metros.
My guess is that Apple's "traffic" is the electronic kind: call/text/data transfer history.
Why do they want it? My dream communications network would be an 802.16e-based Mesh network. Imagine every iPhone acting as a wireless relay, allowing P2P packet transfer. It's lower-power, takes pressure off the cell carriers, and undoubtedly cheaper for the user.
In support of my belief, check /Library/CallHistory/call_history.db (via Stack Overflow).
Comments
Google is satisfied, now it can begin the work to copy it.
android has had turn by turn directions for free even on the cheap phones for a long time
I never understood why this hasn't been done yet by others. With all these network connected GPS receivers driving around, it wouldn't take a large percentage of them to contribute to a service that shows the actual current speeds on roads around metro areas. This data then is aggregated and distributed to other users to allow for efficient use of the roads. The sources of the data can be paid, even, or given an otherwise expensive mapping app+service for free. Maybe some app developer out there is already working on this, but it seems like an obvious thing.
There is an app that does it. Someone showed me the other day. Can't remember what it is. It's like Trapster but something else. You leave it running in the background, it's a social thing, so when it detects fellow users in the locale slowing down they mark roads as having slower traffic.
It's easy to get an app for everything. Remembering what it's called, is another task altogether.
EDIT: HERE IT IS: "Waze"
http://itunes.apple.com/my/app/id323229106?mt=8
Why can't they just work with Google on this? Google already has a crowd-sourced traffic thing for their maps, why not join forces?
*snicker* Apple and Google are not currently BFFs
I never understood why this hasn't been done yet by others. With all these network connected GPS receivers driving around, it wouldn't take a large percentage of them to contribute to a service that shows the actual current speeds on roads around metro areas. This data then is aggregated and distributed to other users to allow for efficient use of the roads. The sources of the data can be paid, even, or given an otherwise expensive mapping app+service for free. Maybe some app developer out there is already working on this, but it seems like an obvious thing.
It's been attempted many times over the last 10 years and is currently being worked on by at least 9 companies that I know of.
The primary difficulties are you need a very large number of devices and/or you need a large amount of bandwidth to send data back to a central processing location.
For good quality traffic you need a minimum of 2% of all the vehicles on the road though the usual threshold is 5% of the vehicles for reliable accuracy. Since at most 10% of the population is traveling at any one time, that means you need an installed base of 20-50% of the total population. That's a LOT of devices. None of the attempts to date have come even remotely close to the necessary number of devices.
Even with available devices, you need to aggregate the data in a central location. If the phone is running your app (maps or something similar), the app can deal with aggregating the locations, determining the roads and speeds, filtering stationary and pedestrian movements, and sending only very condensed usable information back to the data center. But then you need not just 2-5% of the traveling phones, you need those phones to be running your app at the time. That's probably never going to happen but it's the only approach available to an individual app developer.
If you are going to aggregate anonymous locations from many, many phones running many apps, then the amount of data sent over the air is very large. There is considerable impact on battery life as well. Collecting those locations specifically to generate traffic information costs considerably more than the value of the traffic information.
However, if the locations are sent as part of normal operation, as all "location aware" apps do, then the incremental cost of using the locations for traffic is tiny. This is the approach that Google and almost certainly Apple are using. This approach is only available to the phone OS makers as they can build it into the location services layer of the OS and into the back end support for those services.
It will take a few more years but reasonably high quality crowd sourced traffic will get there. Google, Apple, Rim, and Nokia are all working on implementing it now. Microsoft almost certainly is but will need a much larger installed base. The carriers have been toying with it for a decade but have dragged their feet so long that they will get completely bypassed by the phone OS makers. The current information is junk but we're approaching critical mass and the smartphone growth curve means it will improve quickly.
Actually, it's Apple that could be accused of doing the copying:
From the Wall Street Journal, 4/22/2011:
"Google also has said it uses some of the data to build accurate traffic maps. A cellphone's location data can provide details about, for instance, how fast traffic is moving along a stretch of highway."
Read more: http://online.wsj.com/article/SB1000...#ixzz1KkDpXi6H
I've always wondered how Google got traffic data on so many streets. I found it hard to believe they all had sensors embedded in them.
More lame AppleInsider reporting to even think they are talking about network traffic, but admittedly, the press release could have been more clearly written. Apple is probably a bit upset that their hand in working on their own mapping/navigation has been shown.
Neither of them are original and I doubt that they are claiming they are. There was a cluster of attempts in the 1999-2002 timeframe. There was a second wave of attempts around 2005-2006. The current crop of contenders started around 2008 but are based on the earlier work.
Plus, it would be nice not to need to use Google Anything.
And, really, Google Maps is not that great, especially when it comes to directions. Especially their public transit directions can be laughable.
I had to get to over 50 different locations in four boroughs of NYC in 30 days two years back, and GMaps turned me into a subway and bus ninja - never got lost once on any of the trips. The pre-smart phone era for me: I printed the relevant info from a PC before starting out and didn't attempt to use it to predict when subways or buses would intersect each other nor when I would intersect them, but for mapping out workable, complicated routes it was great other than not knowing about a few construction projects.
That seems like the easiest of imaginable problems to solve, really. We're not talking about one data point, we're talking about dozens hopefully, and I think a sophisticated TI-82 could eliminate moving data points which never go faster than 5 MPH, essentially never stop except at intersections, and aren't ever located approximately near the middle of the road. GPS is accurate enough for that.
Plus the main benefit of such a service wouldn't be for crowded city streets, it would be for commutes though highways and local streets where bypassing an accident would save you a ton of time.
Maybe not quite "the easiest imaginable" problem to solve.....
[note: emphasis supplied in quoted post below]
It's been attempted many times over the last 10 years and is currently being worked on by at least 9 companies that I know of.
The primary difficulties are you need a very large number of devices and/or you need a large amount of bandwidth to send data back to a central processing location.
For good quality traffic you need a minimum of 2% of all the vehicles on the road though the usual threshold is 5% of the vehicles for reliable accuracy. Since at most 10% of the population is traveling at any one time, that means you need an installed base of 20-50% of the total population. That's a LOT of devices. None of the attempts to date have come even remotely close to the necessary number of devices.
Even with available devices, you need to aggregate the data in a central location. If the phone is running your app (maps or something similar), the app can deal with aggregating the locations, determining the roads and speeds, filtering stationary and pedestrian movements, and sending only very condensed usable information back to the data center. But then you need not just 2-5% of the traveling phones, you need those phones to be running your app at the time. That's probably never going to happen but it's the only approach available to an individual app developer.
If you are going to aggregate anonymous locations from many, many phones running many apps, then the amount of data sent over the air is very large. There is considerable impact on battery life as well. Collecting those locations specifically to generate traffic information costs considerably more than the value of the traffic information.
However, if the locations are sent as part of normal operation, as all "location aware" apps do, then the incremental cost of using the locations for traffic is tiny. This is the approach that Google and almost certainly Apple are using. This approach is only available to the phone OS makers as they can build it into the location services layer of the OS and into the back end support for those services.
It will take a few more years but reasonably high quality crowd sourced traffic will get there. Google, Apple, Rim, and Nokia are all working on implementing it now. Microsoft almost certainly is but will need a much larger installed base. The carriers have been toying with it for a decade but have dragged their feet so long that they will get completely bypassed by the phone OS makers. The current information is junk but we're approaching critical mass and the smartphone growth curve means it will improve quickly.
Enjoyed this post. Seems a good description of "the mapping landscape" for "traffic"....
Apple tellecomm!!!!!
Link: http://itunes.apple.com/nl/app/id324384027?mt=8
Works awesome.
This crowd surfing traffic app already exists: INREX traffic.
Link: http://itunes.apple.com/nl/app/id324384027?mt=8
Works awesome.
That link is to the Dutch app store. While INRIX may be using crowd sourced data in the Netherlands, it isn't in the US. At least to any large degree. INRIX data is aggregated primarily from government sensors supplemented with truck fleets and predictive algorithms.
Apple is talking about something quite different or at least something based much more heavily on crowd sourced data rather than primarily sensor data.
I'm sure the INRIX app works reasonably well. Sensor data is very good, where it's available. Google and Apple are interested in generating their own data both because it gives them a competitive advantage (government sensor data is available to everyone equally) and because it gives them data on surface streets where there are no sensors.
About a year ago Google started providing traffic data on lots of surface streets rather than just freeways. All that surface street data is generated from cell phone movements. That's the data that Apple wants to start producing (as well as for areas where there are no freeway sensors, ie rural areas).
It's been attempted many times over the last 10 years and is currently being worked on by at least 9 companies that I know of.
The primary difficulties are you need a very large number of devices and/or you need a large amount of bandwidth to send data back to a central processing location.
For good quality traffic you need a minimum of 2% of all the vehicles on the road though the usual threshold is 5% of the vehicles for reliable accuracy. Since at most 10% of the population is traveling at any one time, that means you need an installed base of 20-50% of the total population. That's a LOT of devices. None of the attempts to date have come even remotely close to the necessary number of devices.
Even with available devices, you need to aggregate the data in a central location. If the phone is running your app (maps or something similar), the app can deal with aggregating the locations, determining the roads and speeds, filtering stationary and pedestrian movements, and sending only very condensed usable information back to the data center. But then you need not just 2-5% of the traveling phones, you need those phones to be running your app at the time. That's probably never going to happen but it's the only approach available to an individual app developer.
If you are going to aggregate anonymous locations from many, many phones running many apps, then the amount of data sent over the air is very large. There is considerable impact on battery life as well. Collecting those locations specifically to generate traffic information costs considerably more than the value of the traffic information.
However, if the locations are sent as part of normal operation, as all "location aware" apps do, then the incremental cost of using the locations for traffic is tiny. This is the approach that Google and almost certainly Apple are using. This approach is only available to the phone OS makers as they can build it into the location services layer of the OS and into the back end support for those services.
It will take a few more years but reasonably high quality crowd sourced traffic will get there. Google, Apple, Rim, and Nokia are all working on implementing it now. Microsoft almost certainly is but will need a much larger installed base. The carriers have been toying with it for a decade but have dragged their feet so long that they will get completely bypassed by the phone OS makers. The current information is junk but we're approaching critical mass and the smartphone growth curve means it will improve quickly.
I'd love to know why one user driving down a street out of every 100, which in most busy streets would mean one every 3-4 minutes I imagine, wouldn't be plenty to feed a database of street speeds. And yes, if you force yourself to have incompatible traffic databases, then that requires several users to feed multiple databases, but if one company performed the aggregating work for multiple different app vendors (like the way Navteq provided maps for many different map websites and services), then a user using app 1 on a droid and another using app 2 on an iPhone and another using app3 on a Winmo device would all be contributing to the same cache of data.
The post above is impressive in the amount of numbers it throws around, I just see no logical reason why, if 100 cars pass a given point in 5 minutes, 15-20 of those cars need to be passing data out. Logically it makes no sense that street speed can't be measured with far, far less.
I also question the claim that at most 10% of vehicles are on the road at any one time. Rush hour runs from 4-6 in most big cities. Surely you don't suggest that 90% of the people who live in those cities are not driving during rush hour in the morning and evening, do you?
I'd love to know why one user driving down a street out of every 100, which in most busy streets would mean one every 3-4 minutes I imagine, wouldn't be plenty to feed a database of street speeds. And yes, if you force yourself to have incompatible traffic databases, then that requires several users to feed multiple databases, but if one company performed the aggregating work for multiple different app vendors (like the way Navteq provided maps for many different map websites and services), then a user using app 1 on a droid and another using app 2 on an iPhone and another using app3 on a Winmo device would all be contributing to the same cache of data.
It's a statistical sample size problem. There is quite a lot of variability in traffic and you need reasonable sample sizes to get accurate results. If that one car gets stopped by a pedestrian or hits 2 red lights instead of 1 red light or whatever, its speed can easily vary between a 5mph average over some distance to a 30 mph average over the same distance. And a car 2 seconds ahead of that car may make the light and average 30 while the car right behind gets caught and averages 15.
If you only have 1 sample, your speed estimate will likely be way off most of the time.
Getting enough people to contribute to the same cache of data is the whole crux of the problem. This is why Google and Apple will be able to do it while previous attempts have failed. All location enabled apps on all iphones or all android phones will contribute to the traffic data cache. And that will eventually give a big enough pool.
The post above is impressive in the amount of numbers it throws around, I just see no logical reason why, if 100 cars pass a given point in 5 minutes, 15-20 of those cars need to be passing data out. Logically it makes no sense that street speed can't be measured with far, far less.
I said 2%-5% which is 2 to 5 cars during that 5 minutes, not 15-20. And really that percentage applies to freeways which is what most of the research has been done on. For surface streets, those 5 cars are not going to yield very accurate traffic. I don't know what your logic says a reasonable number should be but think about driving along a uncongested freeway (which is an easy situation). You may see trucks going 50 in the right lane and people going 85 in the left lane. On a city street the problem is much worse with lights and parking cars and turns and so forth. You want to report the average speed, so you need some number of measurements to average together. Most people doing this kind of thing want 5%. More is better, less can give okay results but accuracy will suffer.
I also question the claim that at most 10% of vehicles are on the road at any one time. Rush hour runs from 4-6 in most big cities. Surely you don't suggest that 90% of the people who live in those cities are not driving during rush hour in the morning and evening, do you?
Commutes are getting longer so it might well be more like 15% -20% at the peak now. I think the last statistics I looked at were for 2004. Bear in mind that rush "hour" is 2 or 3 hours long or more. If 6 people have 30 minute commutes during that 3 hour period, you may only have 1 of them on the road at a time even though all six travel during "rush hour".
But you also want traffic information for more than just the most congested period of the day and outside of that period the percentage will be lower. So the principle still applies, you need a much larger installed base than the sample size you need at any particular moment.
Well it'd be a lot better than the iPhones native google maps app. I mean the app is better than nothing, but it would be nice to see a better nav. app with voice turn by turn directions and voice to text. I think we would all appreciate that! That is if they made their own nav. app with those options
On the Android platform that's exactly what Google Nav offers. Voice control of the navigation app, traffic flow map overlays, favorites and navigation to Google lookups, spoken turn by turn directions, voice to text. . .
I don't know why they wouldn't have the same functionality on the iPhone, but assume Apple wouldn't allow it.
A predictive/historical database can alleviate much of the need for active, real-time traffic flow reporting. That's the direction that TomTom/TeleAtlas and to a lesser extent Nokia/Navteq have gone with traffic services. Real-time traffic updates have been far from reliable due to a number of factors, some mentioned here. But good predictive data gathered from actual travelers over a long period of time can be highly dependable, particularly on major travel routes in the largest metros.
You are the man! Wow. Nice posts. Thanks for sharing.
Why do they want it? My dream communications network would be an 802.16e-based Mesh network. Imagine every iPhone acting as a wireless relay, allowing P2P packet transfer. It's lower-power, takes pressure off the cell carriers, and undoubtedly cheaper for the user.
In support of my belief, check /Library/CallHistory/call_history.db (via Stack Overflow).
Just my 2 cents!