IQ routes bug with roads < 10mph

[mvl]

I've been commenting on an IQroutes bug with roads less than 10 mph in a few places throughout the forum, but I wanted to consolidate my experiences in a new thread if it helps others.

I've found IQroutes does not properly calculate speeds on roads that are predictably less than 10mph. I experience the following symptoms:

- If I do a manual time change and do a route demo (on roads that don't have speed limits), Tomtom will drive the demo at IQroutes speeds. When driving these <10 mph roads, Tomtom drives them at about 15 mph. At times of the day where these same roads average 30mph (eg: 2 am) the demo properly drives them at 30mph.
- When stuck in the below-10mph traffic on these roads, the estimated arrival time steadily increases. This is in line with IQroutes thinking the roads are 15mph roads, not the 3-5 mph roads that they truly are. On most other roads, IQroutes arrival estimates are nearly perfect for me (other than congestion from accidents)
- Routing sends me down these roads often, as they would be the fastest route if they were 15mph, not the predictable 3-5mph. If Tomtom knew they were 3-5 mph, there are plenty of faster alternatives.
- These roads are major thoroughfares, with 10-15 cars passing per minute in rush hour. IQroutes has good data on much smaller roads, so I'm sure this isn't an issue of insufficient anonymous input data.
- This reliably happens on every road I know of where the predictable traffic is less than 10 mph.

I've been trying to think of possible root causes, and have two possible hypotheses:
1) Tomtom may be filtering out really slow speeds in its anonymous data input, thinking they are either parked cars or pedestrians. Tomtom should instead pick a median or 75th percentile speed, regardless of whether it is 3 mph. In some areas 3mph is accurate.
2) These roads are stop-and-go, mostly because they are lines waiting for light cycles. The 5mph average is often a result of waiting 1-2 stopped minutes for a light cycle, then everyone in the backup moving 15mph a few feet down the road until the traffic light stops the whole line again. Perhaps Tomtom isn't averaging stopped time into its IQroutes calculations.

This has been my only complaint with IQroutes. This bug causes IQroutes to send me straight into the slowest traffic, often wasting 15 minutes in predictable backups.

The only workaround I found is to selectively erase the roads in mapshare. Adjusting mapshare speed limits don't help because IQroutes ignores them. The downside of this workaround is that Tomtom doesn't take me down the roads during mid-day or late-night when they are clear and the fastest route.

Examples, from the Boston area are:
- 201 Frontage Rd, Boston MA (southeastbound) at 5:30 pm weekdays
- 322 Riverway, Boston, MA (northeastbound) at 8:30 am weekdays
- 1180 Boylston St, Brookline, MA (eastbound) at 8:00 am weekdays

One glimmer of hope: LIVE traffic reports congestion near these areas occasionally, but never reports these reliable slowdowns. Yet Yahoo maps traffic often does report them. Since LIVE is supposed to report when Trafficcast varies from IQroutes, hopefully LIVE is using an updated IQ2 database that shows the slower true speeds on these roads, and the upcoming May map update will give us that database. Fingers crossed...

 

[Michael Quinlan]

I've seen you mention this bug before. Thanks for taking the time to explain it further. When collecting speed data I imagine it's hard to differentiate between vehicles stuck in traffic and vehicles stopped or driving slowly for some other reason. Additionally, I have wondered how they deal with backups that are lane-specific, such as traffic waiting to exit one highway and enter another vs. continuing on the original highway at "normal" speeds.

In any event, having a "minimum" speed in IQR seems like the wrong way to go.

Most often I use my 740 in a commercial vehicle, which can't travel on certain roads. But I sometimes use it in a passenger vehicle, which has no restrictions. What I've done to account for this is duplicate my map folder on a memory card, and use Map Share to "block" the roads that the commercial vehicle can't go on. When in my passenger vehicle, I switch to the unedited map. This may help you with dealing with these "slow" roads and editing your maps.

 

[NorFowl]

I've been commenting on an IQroutes bug with roads less than 10 mph in a few places throughout the forum, but I wanted to consolidate my experiences in a new thread if it helps others.

I echo Michael's thanks for your consolidating and reiterating your discovery.
In fact, just today I was "cruising" through the heart of Denver at rush hour, and my 730 sent me on a side road that was worse (slower) than I25. Sounds like the "MVL <10MPH Bug."

But Michael makes a good point re "minimum speed" I think: When you consider that along some roadways (and we have to think globally--or at least 'westernly'--here) at any given point, cell phone movement data could be coming from pedestrians (a whole sidewalk full!), or parked cars (e.g. waiting to pick up people/kids), vehicles stuck in one lane waiting for signal/exit, etc. and the good old "normal" traffic flying by in open lanes... all within 30-50 feet of each other.

Given the distance precision of commerical GPS, it'd be mighty hard to figure out what's going on in such situations, and I'm sure the folks at TomTom have whitnessed equally "contradictory" feeds. Of course, getting data from additional sources could help. But ooooh, a one-size-fits-all algorith sounds like Mission Impossible .

So here again, the possibility of an "Expert Mode," where the user could switch to the raw data and or algorithm they know is appropriate for where they themselves actually are, could be very useful. Not for everyone, but a way around a compromised "universal" indicator perhaps.

 

[mvl]

I agree that cell phone based data sources in Europe need a pedestrian filter.

However, tomtom-sourced anonymous data shouldn't. I hope tomtom considers an assumption that most tomtom-sourced data is true driving data.

Perhaps an algorithm like below would work:
- take all tomtom anonymous data
- take all cellphone data above 15mph
- calculate the 75th percentile (fastest) of the combined above sources, as the time-of-day prediction

 

[NorFowl]

Certainly worthy parameters for US. In Denver there's a light rail system that runs at about 55 MPH bi-driectionally between stops, and it's right next to I25. Half the people on there at any time seem to be using cell phones. So the "cell phone data >15MPH" could really skew reality. The trains are packed, and run no-stop throughout the day (15 minute intervals).
But holy cow... how to account for that, using cell data only, I haven't a clue!

 

[mvl]

But holy cow... how to account for that, using cell data only, I haven't a clue!

You'd be surprised, Tomtom has already tuned LIVE/HD traffic to address a similar situation in Amsterdam. They don't say how, just that they did in this video.