Click to See Complete Forum and Search --> : Garmin routing algorithm


apersson850
02-11-2005, 07:46 AM
There's been a lot of discussions, over the year(s), about the quality of the calculated routes, why they differ from what you would expect and so on.

There are two things, limiting the possible quality of the routes: Time and memory.

To calculate the perfect route would take a very long time. Not an infinite time, since there aren't an infinite number of possible routes from A to B, given that we have to follow the roads on the map material in question. But there are many enough, to have a computer calculate routes all the way to the destination, without having figured out the best way to go there, even when we've found the way, using traditional methods.

So clearly, the routing algorithm has to clip off areas, which doesn't seem reasonable, to keep the number of possible ways small enough to handle.

When testing different routes, the computer has to keep data of the various possible ways to come forward in memory. Lets look at a very simple example:
........________
...__/_____......\__
_/...............\_____\__
...\__________/
.....\______/

The dots have no meaning, they are just placeholders.
As you can see, there are four possible ways from A to B, which are sensible. There are also stupid roads, leading back to where you came from, so the algorithm has to be able to figure out that they lead in the wrong way, or that they come back to where you've already been.
Also, after checking the routes in the lower half of the picture, the routes there, or at least the best of them, must be rememberd, while checking the routes in the top part of the picture. Otherwise, we can't compare which route is really the best.

In a real example, there are many more roads, thus many more alternatives to keep in memory.
Since memory is a limited resource, the algorithm sometimes has to discard a whole area, filled with small roads, and instead try to find a way around it, using larger roads. This will then be true, even if you set custom routing preferences (can't be done on the iQue, but the 3600a supports it) to favor minor roads, or if you set it to use the shortest road. The shortest may very well be along one of these small roads, but there simply isn't memory enough to figure out which way to go, along these roads. So the computer will have to use something that's easier to figure out, or run out of memory.

In the first releases of the iQue, a route too complex to calculate resulted in a crash, but now they display a message about the problem instead.

If you look at an area with many small roads, and you want to pass through it, then place a via somewhere inside that area. At a point that seems reasonable to pass, preferrably. Since the iQue (in this case, but the principles are general) then can calculate the entire route in two steps, the memory may be large enough to allow it to figure out where to go, along these small roads too.

This is also the explanation to why all these Avoids sometimes doesn't avoid anything. The alternate route, according to the users desire, may simply be too complex to calculate. So even if you set Avoid highways, or place an avoidance bar on a highway, or an area the highway passes through (possible on the 3600a), you may still be routed through there, if the alternatives have too many options to handle, within the existing memory constraints.

Once again, a strategically place via may solve the whole problem, since it allows the iQue to split it up in two halves.

I hope I've cleared up a few of the questions regarding this kind of algorithms in general, and the routing in the iQue in particular, with this post.

jonasolof
02-11-2005, 07:57 AM
I have the impression that the iQue will always try to start to route on roads that lead straight towards the target. So if there are such roads in the beginning and they should be avoided anyhow, it is quite important to put in a via to help the routing process cirvumvent this trap.

JMckie
02-11-2005, 07:59 AM
Seme very interesting on solutions in Graph Theory and Combinatorics.

http://mathworld.wolfram.com/GraphGeodesic.html

http://mathworld.wolfram.com/All-PairsShortestPath.html

http://mathworld.wolfram.com/DijkstrasAlgorithm.html

apersson850
02-11-2005, 08:38 AM
Oh yes, there's a lot to read about these algorithms. But I wanted to keep Bokkie away from counting syllables again, if possible, so I only took an excerpt from my memory.

Chan Eil Fhios
02-11-2005, 11:03 AM
I have to admit, I've always wondered about the algorithm used for routing (although not enough to research it, so far:)). As far as I knew, routing problems are NP complete but somehow they are coming up with reasonable routes (if not always optimal) and in a surprisingly short time.

Of course, I'm strange enough to find graph theory fascinating, so...:D

Bokkie
02-11-2005, 02:10 PM
Originally posted by apersson850
Oh yes, there's a lot to read about these algorithms. But I wanted to keep Bokkie away from counting syllables again, if possible, so I only took an excerpt from my memory.

There are too much of them polly silly balls, too much in fact that it hurts my head. I tap on map. I say route to. I not care how it gets me to the end point as long as it does. Too much data in head makes head hurt.

Aaaaaaaaargh. Take it away. It hurt. Give me easy words, not hard one. Give me few, not many. My head. It ache...

apersson850
02-11-2005, 06:21 PM
Not that they let the code out of the house, of course, but I've at least understood that they are eager to find shortcuts, when possible. Like if there is a major road, that goes a long way towards the target, then skip the possibly faster/shorter sideroads around it, since they'll probably not contribute too much anyway.

With this method, we may suddenly find ourselves much closer to the destination, without much calculation work.

On the other hand, this strategy sometimes results in the silliest of routes...

My recommendation is clear:
Let the unit compute the route.
Look at the route.
If it's funbob'd, place a via-point strategically somewhere along where you would have liked to go.

That will usually solve routing problems.

Wiggers
02-14-2005, 10:48 AM
I've often done thought exercises on different routing algorithms, but never tried to prove whether they were any good or not. One I thought up for fastest route is an iterative branch and cull method. From your starting node calculate the VMG toward the target of x links. Take the n best paths and look at x links from the nodes at the tip of each. Rinse and repeat, removing any duplicates. The values of x and n will have to be determined (dynamically?) by available resources, but I think it has merit. In fact x doesn't need to be very big as most road junctions only have 2 or 3 possible exits, exceptionally 5 or 6. Roundabouts (traffic circles) can be considered as a series of T-junctions in a ring.

I have heard of other strategies, like the one mentioned by apersson850, where the algorithm looks for primary routes close to the start and finish, and then routes to the nearest points on those.

Mark

jrose1g
02-14-2005, 09:53 PM
On the topic of routing, I seem to recall much fun being made of some wierd routing in Microsoft MapPoint. Try using MapSource and CS Europe to calculate a route from the west coast of Wales to the west coast of Scotland. The route I was trying to look at was St. David's to Oban, Scotland. Mapsource took me on the ferry to Rosslare, Ireland up to Belfast and on another ferry to Troon. The iQue itself calculated a logical route.

Edit: I did have the routing preferences set on "Shortest Distance", so I guess it is logical after all.

snoopy-doopy
02-15-2005, 03:57 AM
'Since memory is a limited resource, the algorithm sometimes has to discard a whole area, filled with small roads, and instead try to.........'

If this is really true so why don't they use 'Swap files' on the SD-Card . Ok that would slow down the calculation.
I could imagine that in the 'Prefernces' I could say to 'Q' to use 'Swap Files' and how much megs. on the card.

apersson850
02-15-2005, 04:01 AM
I don't think that's a good idea.
The iQue is supposed to be useable even without any card.
The routing algorithm is about the same in all Garmin units, which of course is an advantage for their programming departement.
I would assume that the time penalty for such a memory use is too high.

Sure, you could have a setting for this, but considering the slowness in calculations, caused by slow cards, I still doubt it.