Incorrect routing on 540 XXL

[vbaranov]

Found a problem with trip routing: while choosing the "Fastest" it brings up 200 mi and 2:28 hours for the trip. Then, in attempts to find out another route, I've entered the city name to "drive through" via "Find alternative" option - voila! Now I have 190 miles and 2:19 hours for the whole trip - faster AND shorter (!!). What's this? Why the "Fastest" route was not found without the manual intervention?
Should I perform a manual search multiple times, using "via" option in attempts to find out the fastest route? Such approach looks pretty strange. As an example, if using the "Google maps" on my PC to get directions for the same trip, that fastest route was found immediately. Well, seems like TomTom software is not capable to find out the optimal route at all. I can only qualify this as a bad algorithm, implemented by the bad programmers. These days it seems pretty strange that not-so-complex task for a trip less than 200 miles cannot be solved appropriately, Can anyone explain or suggest how to 'deal' with such problem? I can't say it is an issue, but in fact it is a real problem: why the "Fastest" option can't find the fastest way, anyway? I can't trust now neither "Fastest", nor "Shortest", nor any other options, because the proposed route might be far below any expectations.
So, now it seems like the only way to use TomTom "effectively" is to plan trips online with a help of anything from Google maps to Mapquest and MS Streets & Trips (etc.), and then verify the route with what TomTom produces, making the necessary changes in order to achieve at least satisfactory results (if at all possible), but that is not how TomTom should work - I believe. How can I trust TomTom and be confident that it does what it supposed to do perfectly? Now I make the route change a few times along the road, re-calculating the route at the certain points - and this is only for 200 miles trip. The GUI interface is convenient, but that's not all for such product.

 

[DavidS777]

There are MANY ways to get to a specific point.

The IQ routing takes into account not only the stated speed limits; but also the historical traffic flow using various roads.

The first route suggested is usually the most 'efficient'. When you ask for an alternative route; the unit gives you a different route. It also must give you distance, and travel time. So it uses the stated speed limits; but now you are not getting the actual typical road condition travel - you are getting speed limit travel.

IQ routes even take into account the time of day.

The first route suggested is the most efficient for the day, and time. If an accident or other backup occurs - it will try to help you out of that jam as well.

Alternate routes by the very definition - are historically going to be slower - even if the stated speed limits would make them faster - if no other traffic existed on the roads.

D.

 

[vbaranov]

The first route suggested is the most efficient for the day, and time. If an accident or other backup occurs - it will try to help you out of that jam as well.
Alternate routes by the very definition - are historically going to be slower - even if the stated speed limits would make them faster - if no other traffic existed on the roads.

D.

Not correct. Cannot agree. Also, my 'corrected' trip took even less time, than declared - approx. 3 hours in reality.
The "Fastest" route, generated by default, was the longest one AND the slowest one in terms of time AND distance to drive - 3:28 hours, 200 mi. That first route (as per your reply) is not by all means the most efficient, because simply mentioning specific city name in a middle of a trip makes the difference for both trip time and length - 190 mi (vs 200 mi) and 3:19 hours (vs 3:28 hours). All those 'historical' data do not play, because that was not me, who calculated how long trip will be, but TomTom, and just entering the city name into the trip route resulting in immediate reducing the trip time by 9 minutes - and that was the same TomTom with the same 'historical' data.
Why TomTom did not find that 190 mi 3:19 hours route from the very beginning? That's nonsense. I can switch between those 2 routes continuously and all the time it generates its "Fastest" route at 3:28 hours vs. 3:19, which is the REAL "Fastest" route. So, the program is stupid enough to not calculate the most efficient route, thus directing me to drive in wrong direction, while there is another way, which is 10 miles / 9 minutes better. That's a clear case of bad software and wrong algorithm. Period. Big screen and GUI i-face is not enough to represent a good product.
Is there any specialist I may claim my issues to? Anyone, who is really responsible for a product quality?
Such approach enforces all TomTom customers to spend time and gas for nothing.
A perfect example: additional 10 miles and 9 minutes for 2-way trip twice a week will result in year-end at 1,040 (!!!) additional miles and 15.6 hours (2 working days!) on a road. Isn't this too much to sacrify for nothing? My guess is that TomTom SW need to be optimized and to be at least as effective as Google maps or MS Streets&Trips - did not have any issues with neither one, and TomTom in comparison is just a toy, which needs to be babysitting all-trip-long.
Seems like until reworked, all TomTom customers need to verify the route (either "Fastest" or "Shortest" or any one else) with what other standalone / online "map" tools produce, otherwise they are at risk to drive longer and to spend more time on a road than necessary. That would be interesting to compare the same route with what Garmin can make ...
(don't have one handy, will find out any at Best Buy or CompUSA just to try).

 

[Andy_P]

Not correct. Cannot agree. Also, my 'corrected' trip took even less time, than declared - approx. 3 hours in reality.
The "Fastest" route, generated by default, was the longest one AND the slowest one in terms of time AND distance to drive - 3:28 hours, 200 mi. .

Ignore the ACTUAL drive time, that's just clouding the issue.

Did you miss Davids suggestion that the first route calculated uses IQ Routes data, but the alternative route doesn't?

I'm not sure if that is or isn't correct, but if it *is* (and I think I've heard it before) then it explains it perfectly.

 

[DavidS777]

Vbaranov -

the shortest distance between any two points is always a straight line.

However - in practicality - this is not always the quickest.

Crazy fake example: if you are hiking across country; and wish to get to a certain point; and a deep, steep ravine is between you and your destination point; it is a lot shorter distance to hike down the ravine and then back up the ravine and on to your destination point. But it takes much more Time - then if you walked the 2 extra miles on top of a ridge; and took the bridge across the ravine; and then continued to your destination point. More distance; less time.

If you access your 540 "Change Preferences"; and continue to page 4; and "Planning Preferences"; you will see some options. Two of which are: "fastest routes" or you can choose "shortest routes."

Now, IQ routing works with any of that; but within the stated parameters. Generally, I am looking for the Fastest way to a particular destination; and not necessarily the shortest.

Real world example: I own a 1994 Chev Truck. V8. Currently it is running on like 6 cylinders; and going through more oil almost than gas.

In this Seattle area; I have a way which I drive home from a popular store. I ignore the GPS for this particular situation. It desires for me to be on the Freeway for a LOT longer than I want. Takes me out of the way, more distance, etc. And the freeway goes from a general elevation of where my home is; on down, down, down... and then I would get to go up, up, up.

The Freeway route is technically MUCH faster. It is also a lot more distance; and the truck does not like to go up hills. But the freeway route has like a grand total of 6 traffic lights; and a whole lot less turns, and intersections to my home.

The route which I like to take; has a ton more intersections; and traffic lights, but stays relatively flat and on the same elevation as my house. Easier on the truck. And it is a substantial less total distance to my house. But it is definitely NOT a quicker route. Less distance, but get home slower.

IQ routes take into account not only just the posted speed limits; but actual real world traffic data; at various times of day - for various roadways. If I want it to give me the Shortest route; I can set the device for that. And then the priority of the TT device will be the Shortest route. Distance wise. But this will not necessarily (and probably will not) be the fastest route.

A straight line is always shortest. But what is the roadway like; how many intersections; posted speed limits; actual typical vehicle speed; and how many traffic lights... All of the above is taken into consideration with IQ routing. Even if not specifically stated; since the number of intersections, flow of traffic etc; all result in the typical vehicle traffic flow on any given road - and IQ looks at the historical typical traffic flow on a given road...

Hope this helps your understanding.

D.

 

[vbaranov]

For both previous posters: the real-life experience perfectly shows that so-called "First route", which uses IQ Routes data, is not always the best. In this particular case it is an opposite to what I expect: that "first route" has been tested and verified to be neither fastest, not shortest. Period. An approach to manually edit the route works better.
That's not wise to repeat the mantra "IQ Routes, IQ Routes" endlessly - it's good, but it is not perfect, because it is men-developed and men-maintained and, therefore, is full of false approaches and errors - just like any other men-made product: it may behave good in common-case scenario, but in each particular case it does not worth so much 'excitement'.
As for the trip, described above, it took 3:20 hours for the "first route" with - evidently - IQ Route applied. In second case with trip route altered manually a few times along the road, it took unbeatable less than 3 hours with approx. 40% of time on a highway. That's not fantasy, but the real-world experience.
All these talks about how nice IQ Routes is are mostly applicable (seems like) if driving mainly on highways/freeways, while in rural area or just using the back roads it is practically worthless. Maybe, the data for IQ Routes need to be adjusted too often, which is not a fact, or should be maintained more carefully or whatever else, but blindly believe in IQ Routes' superiority seems to be an overkill - it's just a program with it's own limits and flaws, but who can say for sure a word about its effectiveness in each particular case? Well, IQ Routes is just another 'feature' , which might work, but might not. This is why, if not driving on a highway, TomTom (seems) cannot guarantee the best result in planning a trip, and this is why its been said that the route planned should be verified carefully. No reason to believe blindly to that "first trip", it may be highly unoptimized: maybe, the data were not updated in timely manner, or the data are just wrong - who can prove that? Only the real-world experience can tell for sure if this is true or not. Neither product is top-of-the-world, it is wise to know the advantages and drawbacks, but some evident flaws need to be fixed or - at least - taken into the consideration while planning a trip.

 

[canderson]

I may have read too quickly through all of this, but to vbaranov:

I believe the point that is being made is still being missed. I believe you're being told that the IQRoutes 1st routing is likely more accurate than the alternatives that you are getting that appear faster.

I can't claim to know if this is true or not, but I can certainly understand the argument that the alternate routes, while they project a faster arrival, do not incorporate as much information as the original IQRoutes itinerary, and that these alternate routes may in fact take not only longer than projected, but longer than the original route.

If indeed the alternates do NOT take IQRoute info into account, then this is not only entirely believable, but to be expected.

Before IQRoutes, time-to-destination was projected based upon only three types of roads. Each of these three road types was associated with its own unique speed -- but that meant that there were only three speeds from which to choose for each and every segment of the trip. Time of day was not considered. Day of week was not considered. I used to know what the three speeds were, but can no longer recall. But for the sake of argument, assume they were 20mph for side streets, 30mph for non-highway arterials, and 50mph for serious stretches of highway.

Projection of travel and arrival times before IQRoutes was pretty shaky.

IQRoutes takes into account historical average speeds for roads where the map contains that information, sliced and diced into 15 minute intervals through the course of a week. [Holidays are not yet accounted for - it's strictly a day of week thing.]

As a result, there will be times of the day where the original non-IQ system would assume 50mph on a highway that is typically in gridlock at 5pm on a Friday afternoon. IQRoutes knows better based upon historical data, and will project a much slower speed for that section of road than the original routing system will.

So if the alternates really aren't using the IQRoutes method of projecting time to arrival, there should be no surprise that those alternates look better -- when they really may NOT be.

 

[vbaranov]

A quote: "IQRoutes takes into account historical average speeds for roads where the map contains that information"

If - and only IF - those 'historical average speeds" were updated quite often and (!!) regularly, then it is possible to accept IQRoutes data as more or less trustworthyotherwise any speculation about IQRoutes' superiority and capabilities are worthless. I don't believe (and nobody can prove) that, those "historical average" are up-to-date for all roads at any particular moment of time: as it's been said earlier (see above) "... where the map contains that information". Don't see a subject to discuss if IQRoutes are not applicable to any road - if it is not everywhere, why mention it at all, like previous comments did? How may I know it IQRoutes is 'in effect' for my particular route? If it not, then no sense to discuss it's usage and advantage (if at all exist).
It is even hard to keep the maps updated in timely manner, therefore how it can happen that the 'average speed' is being calculated/updated properly along my way? No way.
This is why in this particular case - and I strongly believe it is true for majority of trips along the intrastate and side roads - IQRoute either is not applicable (does not work - is not in effect) or introduces the 'white noise' (unreliable data), which misleads the routing algorithm and push us to believe that the 'first route' trip is the best one, while in fact it's not, and the real-world test proves it absolutely. Maybe (!), IQRoute is more or less accurate if driving via interstate highways and major cities, but it is not true in case of intrastate highways and side roads - too many roads not only to keep those "historical data", but simply to have them all in that database, which is a reason for IQRoutes do not work as expected on those roads.
Once again, don't believe at 100% in TomTom route, always compare it to what other tools recommend and use your own experience and judgment. Blindly follow the proposed route will result in more miles, more gas and more time on a road, but even if you save a few minutes, driving via the interstate highway vs. intrastate road (as TomTom recommends), the total gas usage will be much higher, than driving via the state highways/roads at 55 miles per hour (if applicable). My in-dash display shows this perfectly in "miles to empty" units: less miles -> less gas even with stops at intersections and stoplights just because the gas usage grows exponentially with speed increase. And TomTom has a clear tendency to choose the interstate highways regardless of a result - those mentioned earlier 3:28 hours vs. 3:19 hours.
(BTW, do you really believe that someone really collected the historical data near and around, say, Tar Heel AND (!) update such data at least periodically? too good to be true ... seriously, it is the same as believe in speaking snakes )

 

[canderson]

A quote: "IQRoutes takes into account historical average speeds for roads where the map contains that information"

If - and only IF - those 'historical average speeds" were updated quite often and (!!) regularly, then it is possible to accept IQRoutes data as more or less trustworthyotherwise any speculation about IQRoutes' superiority and capabilities are worthless.

Unless you can find a system that provides instantaneous (or better yet, prescient) knowledge of road speeds at all points along a trip, "typical" speeds based upon time of day and day of week beat the heck out of just using 3 speeds for 3 road classifications and hoping for the best.

I can assure you that my ETA with IQRoutes - excluding traffic anomalies - is astoundingly accurate. In fact, my old pre-IQ unit was rather pessimistic much of the time. Now, if I'm doing 85mph on a run down into Denver, I often don't buy back a single minute ... my TT knows that it's likely that everyone IS doing 85 instead of 75 at certain times of the day.

Now, add decent Traffic data to the IQRoutes, and you get a display that shows a combined estimated delay for any route. My 740 provides an overall expected delay, and also separates that into 1) IQRoutes historical data used to project a portion of that delay, and 2) current traffic information that is used to project a portion of that delay.

The ETA will inevitably be more accurate with good historical data than without.

Here's a piece of information that you may be missing that should modify your thinking about this system: Every user that offers (via Home configuration) to provide anonymous data back to TT is providing details about each trip made and average speed on each road segment of those trips. All users that make the connect back to the TT server for an update and have permitted that option are providing an ongoing return stream of data that can be used by Teleatlas to further refine their averages. If there are TT users around Tar Heel, then yes, TT may very well be collecting data for that little spot in the road. And yes - the data is encrypted.

 

[vbaranov]

Well, well, well. The initial subject was why that guy (TomTom) produces the initial route, which is much worse, than that one, corrected manually, and why the corrected route in fact is the best one? Those conversations about the 'features, bells and whistles" are just slightly connected with a subject. If in this particular case the recommended route is not at all good (the actual trip time difference is around 20 minutes for less than 200 miles trip!), then something is wrong with the algorithm implementation and/or with the data being processed. I am not willing to compare the GPS devices (I have TomTom only), but am willing to find out a reason and solution. The common-sense discussion and arguments "pro and contra" are not enough and are not satisfactory. I would like to have "set it and forget it" option for my next trip, but I would like to know at what level I can trust that 'First Route". The ability to enter multiple waypoints might help, but such approach involves a lot of manual work for any new trip and you should save all the details about the previous trips in order to be able to restore the actual 'picture' exactly like it was before.
Unfortunately, I don't know if there is a way to enter multiple waypoints, which help to 'correct' the trip along the way (entering just a few would be enough, but TomTom does not allow me to do that, but replaces the previous waypoint) in order to build the perfect way. Anyone, who is really interested in making TomTom a really good product, should take a look into this more deeply and find out a real reason why such thing could ever happen. If entering a waypoint in a middle of a road causes both time and distance to be more 'effective' than that one TomTom recommends as the fastest "first route", then an explanation should be available widely. No one should ever meet a situation when the recommended route is worse in both time and distance than that one found via the 'waypoints', which in turn is proven to be true by having an actual trip via that exact route. Fix the errors - that's all.
So, who are so brave to dig into this and find out why this at all happened? Again, the common-level explanations and discussions do not worth anything until this particular case is resolved - based on real-world experience, that 'first route' should be close to that one, found via adding a waypoint (actually, I had a few, entered continuously during the trip).
For now, I would be satisfied with the trip planning if it is possible to enter the multiple waypoints from the very beginning (TomTom just replaces a single waypoint - any suggestions 'how-to' are greatly appreciated) and use other sources/maps to find out the critical waypoints along the way.
Of course, it is much better to know for sure that IQRoutes work as expected all the time (set it and forget it), but that is not always true. By all means, the "first route" should not be too far away from 'optimal', as well as it should not be the longest one for both time and distance.

 

[vbaranov]

Found just now: "... Tomtom does not support multi via points, maximum 1 via point".
That's a serious limitaion - what, really, might be so difficult to implement? If others can do that, why TomTom can't? Any hope to have this fixed at least in foreseeable future? Txs.

 

[canderson]

The ability to enter multiple waypoints might help, but such approach involves a lot of manual work for any new trip and you should save all the details about the previous trips in order to be able to restore the actual 'picture' exactly like it was before.
Unfortunately, I don't know if there is a way to enter multiple waypoints, which help to 'correct' the trip along the way (entering just a few would be enough, but TomTom does not allow me to do that, but replaces the previous waypoint) in order to build the perfect way.

Nothing can replace "local knowledge" when it comes to GPS systems and routing. That said, if you have a regular trip, or are prepared to plan a route for a one-off trip, there is a way to force a particular itinerary. In fact, we've had some really odd routing suggested by users' TomToms and suggested to them that they create an itinerary that routes them along their preferred route. I recall a lady who was having a heck of a time a while back with a route in New York where the TomTom insisted on a route that we agreed was NOT optimal. Since we could not see into the map data to understand where the impediment might be to truly good routing, we had her create an itinerary that provided her with a route that was more appropriate.

That was an interesting issue. There was clearly something embedded in the map data (estimated speeds, road blockages, turn information or something) that was forcing the routing off what really was a much preferred routing. In those instances, there's no quick or simple way do "fix" the problem.

 

[vbaranov]

Agree - it is not quick, but could be relatively easy.
In some occasions an easy approach might be using the Google maps to make the route and import it to TT via "Tyre", Because TT, depending on mode selected (fastest, shortest etc.), attempts to re-define the imported route, it is recommended to enter a few 'points' along the way in order to 'keep' the route intact (if highly desired). In case of a brand new route, making a few 'probes' via TT, GM, T&S (and so on) might give an idea of a reasonably better route, then - as usual: GM route with waypoints -> Tyre -> TT.
This takes time, but gives better results - the preparation is required anyway for a serious trip.
In common case (don't blame me for this), TT is easy-highly-useful to use for in-city trips and along the major highways. Everything else seems to be questionable and requires additional verification in order to find out the best route.

 

[Andy_P]

Found just now: "... Tomtom does not support multi via points, maximum 1 via point".
That's a serious limitaion - what, really, might be so difficult to implement? If others can do that, why TomTom can't? Any hope to have this fixed at least in foreseeable future? Txs.

You mean something like the "Itinerary" function found on all mid and high-end TomToms since the Go300 through to the Go x50 range?

Up to 47 "via" points before the final destination.

 

[mvl]

Found a problem with trip routing: while choosing the "Fastest" it brings up 200 mi and 2:28 hours for the trip. Then, in attempts to find out another route, I've entered the city name to "drive through" via "Find alternative" option - voila! Now I have 190 miles and 2:19 hours for the whole trip - faster AND shorter (!!). What's this? Why the "Fastest" route was not found without the manual intervention?

Due to how slow IQroutes calculations are, IQroutes only enables itself for the fist couple hours of a trip, then it defaults to the more error-prone road-class-based routing. Once you stop for more than 5 minutes (eg: gas or a snack), it will recalculate the next couple hours under the detailed IQroutes methodology.

Normally, this means that any sub-optimal routing will correct itself as you drive and take breaks, but if you have an early fork in the road, it could be missed.

With the Turbo Routing of newer app 10.x GO models, this no longer happens. IQroutes is precalculated for your entire trip, so the problem wouldn't occur.

 

[vbaranov]

No, I meant the number of waypoints if making a new route via "Navigate to" option - like making a fast route from home location to PoI
The itineraries are not limited to a single waypoint, while it is not possible to enter more than 1 waypoint if using 'Navigate to" option: TT always replaces the existent waypoint, therefore if more waypoints are required for a planned trip, then build the itinerary. That process is not too convenient, therefore it is better to import itinerary from another program.

 

[vbaranov]

To "mvl":
A quote: IQroutes only enables itself for the fist couple hours of a trip, <skip>
Once you stop for more than 5 minutes ... it will recalculate the next couple hours under the detailed IQroutes methodology.
if you have an early fork in the road, it could be missed.
__________________

So, is this is a sort of 'confession' that IQRoutes works only for the short trips? If so, then such info should be known widely for all interested parties.
Well, the very first "out of highway' fork in my 'questionnable' trip occurs below that 2-hour limit and I don't usually have stops - at least during the first 2 hours of driving. So, as defined above, my only choice is to make unpalnned/unneeded stops along the way each 80-90 minutes and wait if TT could change the route - should I rely on such approach seriously? (!!)
If what's been said about the new devices is true (need verification, though), then I can just trow away that 540S and purchase a new one, but changing GPS device each other month is not a good idea, therefore I have to find out how to live with that from now on.
Well, will continue to use TT "Navaigte to" for any in-city and short trips, while knowing those limitations pushes me to upload itineraries from other sources (GM, S&T etc.) - not too convenient and time consuming, because the multiple 'waypoints' might be required in order to make the 'perfect' route.

 

[canderson]

So, is this is a sort of 'confession' that IQRoutes works only for the short trips? If so, then such info should be known widely for all interested parties.

Gonna get this beat to death eventually. You don't like IQRoutes. We get that. But let's not keep finding improper reasons for beating it up, OK?

IQRoutes is projecting arrival time based upon historical average speeds with 15 minute granularity. If you plan a 6 hour trip, do you plan to take a bottle along with you to [TMI] ... and a 50 gallon gas tank?

What IQRoutes is doing by recalculating as you get down the road is fairly understandable. There is no way for any GPS to predict your actual driving speed, nor how often your bladder will call, nor when you will want to stop to eat. So how do you expect it to guess which 15 minute interval of average historical speed will apply to a particular road segment some hours down the road? Since you can and WILL stop somewhere after some period of time, it must afterward re-project your times based upon when you will be hitting various road segments where the average speed will have changed. Ditto if you do not drive near enough to the projected possible speed. Poke down the highway at 45mph, and the original projections will be wrong - you'll be late to the party an hour down the road.

If you wish for IQRoutes to make a single projection for a long trip, you'll need an entire rewrite of the algorithm that allows you to specify when and where you will make stops, and for how long, and how fast you will be driving. How else can it guess what time you will arrive on a particular segment of road?!?

 

[mvl]

So, is this is a sort of 'confession' that IQRoutes works only for the short trips? If so, then such info should be known widely for all interested parties.

I've never seen Tomtom publish this anywhere. It's only something I've found by troubleshooting specific routes. I had tried playing with the distance, and thought it was more of a 3 hour cutoff, but could never pin it down exactly.

If you post the specific start/end and forced via point of your route, I can try to debug it.

 

[canderson]

I've never seen Tomtom publish this anywhere.

I guess I'm surprised that the OP expected them to. Your own experiments have confirmed what would have to be the IQRoutes reality. There's no way that a system can predict within which 15 minute period a driver will arrive on a particular piece of road -- unless, as I noted before -- you've got your own personal KC-135 Stratotanker and a relief tube so as to make the run non-stop at the projected average speeds.

For IQRoutes to (and any other similar system one could invent) to provide an accurate projection on a long trip would require some means of knowing the time you would arrive within each individual segment of road for which the historical speed data was available. Since such systems cannot predict driver behavior for either stops or preferred driving speed, it's not possible for such a system to make projections over long periods of time or distance.

Accuracy would require the user to provide both stop times and locations and planned driving speeds for each road segment to provide a truly accurate long term projection. No GPS provides that kind of specification of parameters for ETA projections. I doubt more than a small handful of users would be able to successfully employ it if it did exist -- and it would all go out the window the first time there was an "event" en route that threw the user's pre-defined schedule off track.

I guess I don't understand how the realities and the expectations are so far out of whack. You don't have to be a Sr. IT Analyst to appreciate the problems of developing a system like this. Imperfection is assured.