Nuvi 765: suboptimal route planning

The routing algorithm does not take traffic lights or stop signs into account at all. (Note that it will account for actual traffic if it has a traffic receiver and there is actual reported traffic.)

If you know a better/faster/shorter way, take it. The GPS unit will catch up.

Note that the GPS unit is NOT designed to give you the best/optimal route. It is merely performing a mathematical calculation using a set of rules. "Best" is not one of the criteria.

True, but the OP did not ask for the "best" route, he asked for the "fastest" route, and when he forced the Nuvi 765 to use the Interstate the calculated transit time was 3 minutes shorter than the route it originally offered as "fastest". Therefore the original routing was suboptimal.

The following is just one example of what other users have stated in the past:

My answer:

I believe the difference between your 765 & your 260w is that they are most probably both using different map sets thus the difference of three minutes on a 66 mile route.

I've never tried it but if we put 5 different nuvi units beside one another and enter a destination they won't all be going the same way !

As far as I'm concerned different map sets, different firmwares equals different routing.

Cheers

No, the OP didn't ask for the "best" route but he commented that the routing was "suboptimal" and considering that both are pointing to superlative descriptions of the routing (and since "best" and "optimal" are synonyms) ... same thing.

And again, "fastest" in that situation does not take into consideration any time spent stopped at traffic lights or stop signs. It merely is calculating based on road speeds.

So the unit is doing what it is programmed to do. Nothing more. Nothing less.

It may never give the "optimal" route and still be working as designed.

My 885 often bypasses the obvious faster route of the Interstate because the route it calculates factors in distance and makes the assumption shorter is faster in a lot of cases. That's probably what's happening to the OP as well. The surface street route is slightly shorter, and therefore with no stops should be faster.

re: "best" vs. "optimal"

I interpreted the words "best" in the qualitative sense and "optimal" in the quantitative sense (specifically with regard to "fast-ness"). There are many occasions where the "best" route for me is not necessarily the "fastest" because I find Interstate driving quite boring. (Expedient, but boring.)

The fact remains that the "fastest" route offered by the 765 was demonstrably not the fastest, even by its own calculations. So why would a unit "miss" a slightly faster route? My guess is that it is pruning the solution set to keep the calculation time within reason (ref: other threads here asking "Why does it take so long to recalculate a route?"). As explained in the Wikipedia article on "Branch and bound":

re: traffic lights and stop signs

I can't speak for Garmins, but I know that my TomTom assigns a "link speed" to a road segment that is sometimes significantly different than the posted speed limit. In particular, segments near intersections can have link speeds that are much lower than the speed limit. I can see that by putting the TomTom in Demo mode and "driving" along a 4-lane surface road: if the posted speed limit is 60 km/h then it will cruise along at 60 until it approaches an intersection, then it will slow down to 25-30 km/h, and once past the intersection it will speed back up again. That's how it "factors in" the overall average cost of possibly having to stop there.

Sure, not the individual traffic lights, but it takes into account the average expected speed on the given street, which depends on the number of traffic lights. Further, I don't see why it shouldn't take into account also the number of intersections multiplied by some reasonable probability of hitting red light and resulting in delay. Given that now one of the route preferences is "less fuel", what else but the number of expected stops could it be based on?

Where I know a better way, I don't need the GPS. What I described in the original post was basically an experiment in order to find out if I can rely on the unit in unfamiliar places.

This is unexpected. What is the meaning of the settings under Navigation such as "faster time" vs "shorter distance" if not the promise to optimize time vs. distance?

Assuming that the calculation is based on Dijkstra's algorithm(http://en.wikipedia.org/wiki/Dijkstra%27s_algorithm), it's certainly expected to deliver the optimal route.

When I simulate (as I often do in checking things out), I have noticed that my 765 will slow to a crawl at any intersection at which I will make a turn. This means that routing is impacted by the number of turns on a route.

I have noticed that the 765 does not always have the correct speed limit but nevertheless has me traveling at a couple of miles over whatever it thinks the limit is. This means that routing is impacted by whatever speed limits are in the route - whether they are correct or not.

This also implies that my 765 has learned my driving habits over time - so a new unit would calculate the same route differently over time - factoring in the owners driving habits.

As I have never simulated using an interstate, I will have to do a simulation that takes me downtown on the freeway and see whether the Garmin keeps me at a steady speed or slows at places where there are freeway splits.

Very interesting.

Garmin has some support articles on the topic:

https://support.garmin.com/support/searchSupport/simpleCase.htm?caseId={d539bb20-d456-11de-7f4f-000000000000}

https://support.garmin.com/support/searchSupport/simpleCase.htm?caseId={74029b30-0250-11dd-dc9c-000000000000}

Both articles advise to check vehicle type and navigation setting; they don't say something like "even then, we don't guarantee optimal route", so I assume with correct settings in place, the route is expected to be the fastest.

No. It does not.

It uses the road speed for that CLASS of road.

It does not take into account the traffic lights.

It takes the distance the route travels on the road class and multiplies that times the speed for that road class.

But it doesn't take the intersections into account. The algorithm is complex but not that complex.

And again, things like "less fuel" takes other things into consideration (ie, the fuel mileage you enter, traffic, etc). But the "normal" routing does not do this.

This is unexpected. What is the meaning of the settings under Navigation such as "faster time" vs "shorter distance" if not the promise to optimize time vs. distance?

The 7x5's (and probably other models with traffic receivers as well)have a routing quirk worth mentioning. The following has happened to me a couple of times and it was just luck that I noticed why.

Lets say you punch is a destination where you believe the obvious faster route would choose the highwey...

The 7x5 models will "silently" avoid the highway if, at the time you calculated the route, the traffic receiver was on and there was a traffic issue (slow or stopped)somewhere on that highway.

In my case it was quite by accident that I stumbled on the reason being traffic and was able to verify how it happened.

That was my thought as well, but it does not look like it's the case. Here's what I did: with Mapsource, I put several maps covering the route in question and around, on the SIM card. Then on both Nuvi's 260w and 765t I put in the card and configured the device to use the map set on the card only, and calculated the route. They calculated it same as before, i.e. 260w calculated going on the highway, 765t calculated local roads. So it's probably not the map, it's the software. In fact, I recall that "improved route calculation" was in the release notes of one of the recent software updates.

Search on internet shows that this problem is quite familiar to Garmin users' community, with the pleads to Garmin to fix the software have been going on for years, apparently to no avail. On one forum I have found a creative workaround: set the route type to "less fuel", and specify artificially low MPG in the city. With that, and city MPG set to 10 vs. 24 on the highway, my 765t finally directed me to the highway. I'm not very happy, since with this I probably have only 2 grades of the road type vs. 4-5.

While being in Mapsource, I tried to calculate the route using that application. Mapsource in its settings gives more flexibility than Nuvi, it allows to set several degrees of preference between local roads vs. highways, and it also allows to specify the speed on each type of road. I did play with these settings, and to say that the result was a mess, would be an understatement. I encourage everyone to try to see for yourself, by changing them and seeing the result, to which degree this algorithm is mis-programmed. Now I wonder, should we assume that programming in the device is made by some other hands and is much better?

Which is expected to reflect the average speed on that road. Everybody knows that because of the traffic lights, the average speed on a city street is much lower than the speed limit. As others have indicated, you can even see it in the simulation mode, when the car slows down at the intersection.

Do you know that for sure, or you just guess?

All of which would have the same impact on the fuel as on the speed, thus they probably wouldn't change the route.

From the manual:

"The route calculation is based on road speeds
and vehicle acceleration data for a given route.
• Faster Time—calculates routes that are
faster to drive but can be longer in distance."

Obviously, in this specific case the device has failed to calculate the route that is faster to drive.

Note that inclusion of the word "acceleration" probably implies that the stops are taken into account.

My wife and daughter have never told me of any routing problems on their 765Ts that I keep updated for them. But I have to laugh at my 1450LMT.

I always have a destination programmed just in case there is any traffic and to know about when I will arrive. But navigating home from Erie, 1.5 hours straight south on I79, the 1450 directs me to get off at the exit just before my town and directs me over to Rt19 to town.

If I pull into any of the rest stops it likes to recalculate. If I am less than halfway home the recalculation takes me to the exit just past town. Yes, both are really about equal distance/time.

What's even funnier, if I take the 1st exit anyway it recalculates again but doesn't take me straight to Rt 19, but instead turns me off into some neighborhood streets and then over to Rt 19.

Like I said, you just gotta' laugh sometimes!

One other note, my zumo 665 rarely picks the fastest route, by far, but it has some other nice features.

That's interesting. I was trying to plot a route in the Kitchener/Waterloo area of Ontario.
My 855 insisted that I used the expressway, even though I could manualy force a route on the side-streets, that was both shorter and quicker.

I keep my nuvi set to "shortest" when using it locally and only set it to "fastest" when making long trips. Still, I frequently see cases where the GPS receiver is advising me to go one way and I know that I want a different, shorter way to get to my home. In one case that I frequently experience I have set my Nuvi to dashboard mode before taking my "detour" and I watch it say "recalculating" and then both the remaining distance and the estimated time of arrival drop significantly. The route that I choose is shorter and has fewer traffic lights (one as opposed to 3) and is less trafficked. So I know it is a better route even if the distance were the same, but it isn't the same and the nuvi should be taking my route. The Nuvi choice is slightly more of a "major" road but both routes are on two lane paved roads with similar speed limits, and I rejoin the Nuvi planned route at a light and then turn on to my street and approach my house from the same direction as the suggested route. Clearly the Nuvi knows about all of the streets, as they show on the map and the device can quickly recalculate the faster time and shorter distance. It just doesn't make the right choice.

There are many cases where this has happened to me, some just by a fraction of a mile, others by many miles.

My pint is, trust your instincts over the Nuvi. It can be a help when you need to know how to get somewhere, but don't believe that it will always give you the best choice of routes.

Frovingslosh, do all the unused roads have embedded speed limit data? I have found my units avoid roads with out embedded speed limits.

I do not think my 765 avoids all roads for which it does not know a speed limit (to get out of my area, it will simulate driving on roads for which it does not display a speed limit) and as I recall it does not have speed limits for entrance/exit ramps, but your point is interesting.

I will have to simulate this further.

It is my understanding that the nuvi routing algorithms are based on road classification rather than speed or speed limit.

Don't know this for sure, but I would suspect that are instances where freeway class roads within reasonable distance of one another might have different speed limits.

The Nuvi isn't that bad actually. I have a 770 and have seen a few aberrations over the years, but by in most case, it get's me where I want to be, even if I get off the suggested route in area I know well and can save a few minutes of a mile or two.

As with all GPSr you have to keep your brain switched on!

Since my Nuvi 250 does not display speed limits I don't know if the avoided roads all have speed limit data. But I do know that as soon as I turn on to the route that I want and the Nuvi says "recalculating" that it comes up with an ETA that is a few minutes quicker. So whatever it is using to come up with that new arrival time should also (in my mind) apply to the choices that it uses to select the route. Besides, as I stated, I have the Nuvi on "shortest route", not "fastest route" so speed limits should be irrelevant, it should only be making the choice based on shortest distance. It knows the roads are there and that they are shorter that the way it wants to take. No good excuse why it didn't go that way other than it just didn't consider that road.

double, post. deleted.

No kidding. To people who studied computational complexity a few decades ago, it would seem nothing short of miraculous that we all get pretty useful routings that are often pretty near the "optimum" (whether we are asking for short time, short distance, or low fuel).

For destinations farther away than just a little, it would take well outside reasonable computation time to come even close to considering all alternatives. You can be very sure that your Garmin does not. (nor your Magellan, Tom-Tom...)

None of which says they could not do better, and that in none of the cited cases is there anything wrong. But the expectation that it WILL or even SHOULD get the absolute best answer on all routings is a fantasy.

I realize that it isn't a trivial problem, but consider this: I'm on the Nuvi's suggested route. I'm driving west. My destination is to the north and to the east of me. The Nuvi suggested route takes me further west, then north, then backtracks to the east. I take a right turn, so I'm going roughly north (actually slightly north east, as the turn is more than 90 degrees and the road continues to turn to the north east (and towards my destination) and the Nuvi almost immediately knows that the new route is shorter and faster. It seems to me that the Nuvi never even considered that road.

It might be different if when I turned onto the road the Nuvi reported that my route was longer or ever stayed the same and then later, when I did something else the computer didn't expect, it finally realized that I had made the shorter choice, but it looks to me that the nuvi didn't even consider an obvious turn in the direction that I wanted to go that would have immediately proven to be a shorter route. That's just poor coding. I would have hoped that the Nuvi would look at each turn in the proper direction along the suggested route and see if it seemed shorter, at least as a first order test, but it just doesn't do that.

In this case it wasn't an enormous difference (unless I hit traffic), but I have seen it try to take me more than five miles out of my way for a rather local trip.

I picked up on the word backtrack and it reminded me of a similar situation that I still have. If I want to go to a particular Walmart, my 765 routes me on a parallel road to the divided highway that it should have put me on if the routing was the shortest/fastest route I have found.

It sends me down the parallel road until it can make two left turns and get on the (once was divided now 4 lanes with turn lane) highway and then backtracks till it can turn right into the Walmart.

I spoke with a Navteq rep and pointed out that there is a huge intersection just before the Walmart on the divided highway with a red light and two left turn lanes into the Walmart. That was two years ago and the problem still exists for my 765.

The divided highway and the fact that the red light provided access into two either side of the highway shopping centers without a perpendicular road seemed to me to be the problem. I suspect that if there had been a perpendicular road, the 765 would have been able to route the way I wanted it to.

Perhaps if you inspect the route in your case using a map you might come across some similar reason why your route is sub-optimal (based on your knowledge).

I can definitely confirm that in some cases in which my 3790 wants to go a different way than I think best that the failure of the (Navteq-supplied) turn permission information to show that a divided road median can be crossed at a critical place (up through and including a signalized intersection) is often the problem.

It also tries a little harder to "avoid left turns" than I personally think optimal. If Garmin were not so allergic to making the user interface look complicated, I suspect a lot of us could be made happier with a few numerical tuning parameters--to alter how strongly it values lower trip time, your preferred choice of road types, lower fuel use, and so on. But the consumer triumphs of late have very much been on the simplification side, so I'm not holding my breath for Garmin to offer more of this sort of adjustment to user preference.

I'm sure that people who want to come up with excuses for Garmin can always find some excuse. In my example it might be a left turn, it might be that my route failed to pass a Starbucks and I was instead given a longer one that assumed I would want coffee, or it might even be that the route I was given was higher trafficked, so "logically" the more popular denser traffic route "must" be better. I guess I'm just being stubborn in wanting my GPSr to actually give me the shorter route when I set it to "shortest" rather than "fastest".

I don't think it is unreasonable to want the unit to give the shorter when set to shorter or the fastest when set to fastest.

However, that will not be the case until we can find out why the algorithms are going wrong - as as you and I have both seen, they are wrong based on what we know as facts on the ground.

The algorithms are using information from Navteq on my 765. If that information is incorrect or somehow does not fit into the algorithms cleanly, then the more we can understand and convey to Navteq, the better routing we will ultimately get.

Just not quick enough for me.

I am assuming Garmin would love a couple of volunteer programmers to tackle this issue for them.

Are you guys up for the challenge?

And I'm assuming that there is no way that Garmin would give outsiders access to their code or a way to test any improvements to that code (which would open the way to fixing a lot of Garmin issues without having to buy new hardware).

I'm also assuming that Garmin is well aware of issues like this, and just doesn't car enough to focus resources at them.

If you actually know something, I can be contacted privately through this site. Otherwise, it would be best to not assume.

Garmin is a business. If they thought improving their routing would improve their profits, it would probably happen. So if it isn’t better, you can probably guess it is either out of their control or it is too expensive to improve.

My preferred opinion, based on absolutely no facts, is that part of the problem lies with the local jurisdictions. With each County or Town using some hodge podge of mapping software by people with zero interest in improving GPS routing, the data is sometimes less than adequate. The big companies then procure the data from each jurisdiction and use software to convert it into their database. Almost anything missing or wrong at the beginning ends up as less than optimal routing.

My only “evidence” is that I have seen dramatic changes in capability at county boundaries. That could only happen if the original data respected county boundaries, therefore from a government entity. An independent company might focus on certain counties but I would expect those boundaries to be fuzzy.

In the cases I have discussed, I simply want Garmin to give me the SHORTEST route. It knows the roads are there. Even if there were some error in the actual length of the roads (and I have not found one), it still knows that the route that I prefer is shorter, as demonstrated by the remaining distance to destination jumping down to a lower value on the Garmin dashboard display when I take my route and it does it's "recalculating" thing. So as much as I would love to blame local government for just about anything, Garmin does have the correct information, it just doesn't use it properly.

Not disagreeing with you. (I just added more problem ideas.) Just saying, from the very little that I know about routing, getting the “best” route may be too hard (i.e. too expensive) to always do. I believe that all the algorithms are based on doing a very good job quickly. Think about it; if it took 10 minutes rather than 10 seconds to compute the better route (or 10 hours for the guarenteed best route), you would pick a TomTom or Magellan. Once the actual problem changes (i.e. you have moved), the next solution is occasionally different.

By the way, the new route often computes as longer. What you cannot tell is if the GPS considered the new route earlier. Perhaps it previously made decisions based on incomplete information and got the better route purely by random chance.