Related

Edge 1040 routing still VERY VERY BAD - 120 miles instead of 18?

jrc_
2 months ago

It has been poor, my 1040 always pales compared to edge 1000 routing. Originally saw 15 mile rides turn into 22 miles with higher climb, but this one today is RIDICULOUS.

Saratoga, CA to Palo Alto, CA allows for various routes, some popular, some scenic, some mountainous, some near flat. all around 18miles, +300ft, -600ft.

Edge 1040 created a course that goes all around the SF Bay, 127miles 6463ft climb.

Yet I get ZERO traction on Garmin following up on this.   It used to be that they would actually follow up, ask for data dumps, participate in these forums, and after a while actually fixing stuff.  Now it seems the team is heavy divested in creating a bike bell for the 1050.  Wag the dog.

See route created by 1040 @24.03 and Ridewithgps (loaded via pin)


  

  • 0 2 months ago

    If anyone could try that on their unit (1040, 1050 or maybe 1030), a city to city route, saratoga, CA to palo alto, CA. I'd appreciate, trying to see if it is some setting in my unit or just firmware bugs. I already tried many settings in navigation (this was road cycling, avoid nothing, no popularity, minimize distance) and nuked and reloaded maps (using garmin express and using wifi on the unit only.  Thanks.

  • 0 2 months ago in reply to jrc_

    I am experiencing the same. Calculating a route on the 1040 is absolutely useless. Regardless of the settings (e.g. shortest, no constraints) it seems to pick random routes, which contain many unnecessary additional miles of undesired detour. Garmin…please fix this. 

  • 0 2 months ago in reply to L.Rouge

    the "motorcycle routing" issue caused the "no routable roads" problem.

    changed to "road cycling" and then it routes, but 18mi turns into 120mi.

    can you try on your unit? create a course, on the unit, from "saratoga,CA to palo alto,CA.

  • 0 2 months ago

    Hi,

    On my Garmin 1040 I did experience something like you have (not the most direct route but a route with tons of climbing this was on Tenerife island). 

    So, I had the following "flag" activated on my Activity Profile on the device. 

    Activity Profile / Road / Navigation / Routing / Popularity Routing ( was set to ON)

    Disabling this has solved the issue that I had.

    This was on the latest none beta firmware.

    Hope it helps!

    Cheers,

    Mark

  • 0 2 months ago in reply to jrc_

    Further info.   It seems that Garmin Connect also has this behavior (same algorithm, same map?), so some finer debugging was possible there.

    Starting from one point in saratoga and then going to a point in palo alto created a 152mi route.  moving the starting point north by one block, still in the same road it was already taking, it suddenly creates a 15mi route. odd.

    Then turned popularity routing off (the default in g connect) and it never goes berserk, no matter which starting point.

    CONCLUSION 1 - popularity routing algorithm in garmin connect PC is broken.

    I double checked on the device and popularity routing was off, but just for kicks I turned it ON  (slider to the right, green) and voila' instead of asking me for 123mi to go to palo alto it now asked for 19.6 miles.  Still a bit poor but not 123 miles.

    CONCLUSION 2 - popularity setting in the 1040 might be inverted (or the algo reads it inverted),

    CONCLUSION 3 - routing algorythm in 1040 is also broken, although can be mitigated by turning popularity ON.
     
    exhibit A - g.connect A to B, popularity on - 150 miles  
    https://connect.garmin.com/modern/course/292021719

    exhibit B - same but starting point one block north, 15 miles
    https://connect.garmin.com/modern/course/292022347

    exhibit C - same as A but popularity off. 15.5 miles  no starting point gives the 100+miles
    https://connect.garmin.com/modern/course/292022907

  • 0 2 months ago in reply to jrc_

    More info on this.  I got a 'brand new' 1040 as reference unit, wont let it update or take maps etc.
    It seems avoid high traffic routes setting may be inverted  (or my understanding?  on the screen that says 'select what to avoid' i assume sliding to the right, making the switch green means ON=AVOID), because only when set to not avoid HRT the long routes are created.  See my post from beta forum.  curious if it happens to anyone else (create on the device a course from the city of saratoga, CA to the city of Palo Alto, CA and see how long it wants you to ride).

    ===============================

    Routing issue - 126 miles instead of 19mi - high traffic roads to blame?

    After many many tests I am getting to perhaps closer to some clues of why Edge 1040 on-device routing is so poor.

    While I have noticed bad re-routing behavior since I got the unit - the Edge 1000 always much shorter and reasonable routes - it wasnt until recently that a simple home to a restaurant 15mi away generated a 126mi loop all around the SF bay area.

    I tried many settings, and went as far as getting a brand new unit, kept 'virgin' as it came (maps and firmware, 20.19).

    The new unit with old maps and fw behaves way better, routes from 17.3 to 19mi depending on settings. Comparable to Edge 1000 (17.3 to 18.3 except one weird at 32mi).
    The present unit, at 24.05 shows the problem. I tried 'rolling it back to last non beta fw, same problems.

    So I documented a lot of settings, and it seems that "avoid high traffic" is the main culprit, also "popularity" routing.  The anomaly of 100+ mile tracks for a typ 17mi ride only occurs with AVOID HIGH TRAFFIC set to off (or allow HTR) and Popularity routing turned off.  If either popularity routing is turned on, or if it is told to avoid HTR, reasonable routes are created.

    It could be that popularity routing takes precedence, so if some HTR are 'popular' they are routed anyway, and that HTR setting (or its use) is INVERTED.  How else would turning off an avoidance make much longer routes?

    See the long table of tests I've done.  Now trying to graft old fw into the current unit, including old maps to see if the behavior persists.   Although my gut tells it is a fw bug, a bad algorithm or avoidance inversion that was more recently compounded by many many extra HRTs in newer maps.