This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Long calculation times with turn by turn navigation

Former Member over 6 years ago

Dear all,

After a lot of frustration with long calculation times for turn by turn navigation on the Edge 820 (Firmware 9.10, Maps of Europe 2018.10) I did some systematic tests which I'd like to share here.
I tested systematically 4 courses with 2 different maps on the device and with the algorithms "road cycling" and "straight Line". (When calculating with "straight line" the resulting path was the same as with "road cycling")

The courses (all GPX files):
[TABLE="border: 0, cellpadding: 10"]
[TR]
[TD]testge[/TD]
[TD]an 11.4km course in Geneva city made with Garmin Connect.[/TD]
[/TR]
[TR]
[TD]testge_man[/TD]
[TD]the same 11.4km course made in Google Maps but with a small number of trackpoints selected manually. This was then exported and converted into a simple GPX file. The routing on the edge820 results in the same final path as testge.[/TD]
[/TR]
[TR]
[TD]vuache[/TD]
[TD]an about 70km tour which is mainly outside the city. This course was created on Garmin Connect.
[/TD]
[/TR]
[TR]
[TD]lake tour[/TD]
[TD]a 188km tour around the lake of Geneva. This tour course was created by a tracklog of an actually performed ride which in Garmin connect was converted into a course. [/TD]
[/TR]
[/TABLE]

The two maps which were tested:

The standard Garmin Maps (cycle map of Europe 2018.10, i.e. OSM based)
An OSM (Open Street Map) based map made by me: Removed all points of interest, all buildings and (probably most importantly) all lines with the "footpath" tag. Then created a routable map with mkgmap of the Geneva + lake area.

The following table shows the number of track points in the courses and the measured route calculation times on the Garmin Edge 820:
[TABLE="border: 0, cellspacing: 0"]
[TR]
[TD="align: left"] [/TD]
[TD="align: left"]routing algo[/TD]
[TD="align: left"]testge[/TD]
[TD="align: left"]testge_man[/TD]
[TD="align: left"]vuache[/TD]
[TD="align: left"]lake tour[/TD]
[/TR]
[TR]
[TD="align: left"]# trk points[/TD]
[TD="align: left"] [/TD]
[TD="align: right"]471[/TD]
[TD="align: right"]39[/TD]
[TD="align: right"]1610[/TD]
[TD="align: right"]5264[/TD]
[/TR]
[TR]
[TD="align: left"]Map:[/TD]
[TD="align: left"] [/TD]
[TD="align: left"] [/TD]
[TD="align: left"] [/TD]
[TD="align: left"] [/TD]
[TD="align: left"] [/TD]
[/TR]
[TR]
[TD="align: left"]Garmin map[/TD]
[TD="align: left"]road cycling[/TD]
[TD="align: right"]12:37.00[/TD]
[TD="align: right"]01:41.00[/TD]
[TD="align: right"]10:09.00[/TD]
[TD="align: right"]04:40.00[/TD]
[/TR]
[TR]
[TD="align: left"]Garmin map[/TD]
[TD="align: left"]straight line[/TD]
[TD="align: right"]06:05.00[/TD]
[TD="align: right"]00:55.00[/TD]
[TD="align: right"]05:13.00[/TD]
[TD="align: right"]02:45.00[/TD]
[/TR]
[TR]
[TD="align: left"]custom map[/TD]
[TD="align: left"]road cycling[/TD]
[TD="align: right"]04:22.00[/TD]
[TD="align: right"]01:23.00[/TD]
[TD="align: right"]05:31.00[/TD]
[TD="align: right"]01:53.00[/TD]
[/TR]
[TR]
[TD="align: left"]custom map[/TD]
[TD="align: left"]straight line[/TD]
[TD="align: right"]02:29.00[/TD]
[TD="align: right"]00:49.00[/TD]
[TD="align: right"]02:53.00[/TD]
[TD="align: right"]01:03.00[/TD]
[/TR]
[/TABLE]

Conclusion: The map used in the device DOES matter for the calculation time. The number of trackpoints seem to be NOT the relevant factor for the calculation time. However, when you compare the times for the testge and the testge_man maps it seems obvious that densely packed points in the city heavily "disturb" the routing algorithm (i.e. a lot of useless stuff is being calculated). It also seems that the straight line algorithm is more efficient. Unfortunately I have not found any documentation on what the various algorithms are doing in the turn by turn calculation. The GARMIN manual, as usual, is completely useless when trying to understand how the unit works since it essentially only lists the menus with their entries.... Surprising for me are the short calculation times for the long lake tour (...this is, how it should be of course...). I would estimate the "complexity" of this course similar to the "vuache" course since it often deviates from the simple main road around the lake.

Any comments or insights highly welcome...

0 looigi over 6 years ago

I don't have much to offer here. The calc times for me have been very reasonable here in the US using the Garmin maps on the 820 and using GPX track courses created on a number of different sites. I have had issues in the past with earlier Edge units using courses created on sites using different maps from the one installed on my Edge, and for courses with excessive track points. What you're experiencing seems different.

0 aweatherall over 6 years ago

The calculation time is a function of the course length and road complexity/density that course goes over.

0 Former Member over 6 years ago

Thanks for your answer, looigi. The calculation times are particularly bad when the course is going through the city. I was wondering if the often "simpler" street network in the states (planned cities with "square" like architecture of the network) is easier to digest for the routing algorithm? Who knows...

To the comment of aweatherall: the parameters you are mentioning for sure go somehow into the calculation... however (as my systematic checks show) these are only part of the story... The map itself (even if always based on OSM), the routing algorithm and the CHOICE (not so much the number) of the track-points seem to be more important. The length of the course seem to be pretty irrelevant (the shortest course gave the longest calculation time if used with the default Garmin map and the trackpoints delivered by Garmin-Connect)