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

Not following route - why?

Why is the 530 not faithfully following the route - it seems to recalculate it's own path and avoid this section of my planned route.

First time it happened it confused me so much i nearly knocked into another cyclist - i've now gone back to the same spot 3 x and it consistently always not doesn't follow my route (photoshopped green arrow showing my route (magenta color)). Instead it reroutes to the main road......I have disabled recalculation - so it shouldn't recalculate and should just blindly follow my route ????

  • Thinking out loud -so the 530 will follow my planned route as long as my route is obeying the rules of the land. Otherwise it will abandon my route and do a go around based on the rules of the land. What i mean by that is that the 530 shouldn't be able to take the cyclist against traffic - or going opposite into a 1 way street.

    The device knows nothing about the "laws of the land".

    It only knows the map and the track.

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

    The map is a network of connected lines (roads and paths) where the lines have different properties (like direction, whether cycling is allowed, whether the road is a "highway", whether the road has tolls, etc).

    The lines are linked together at "nodes". A road/path is a series of lines connected at "nodes" (the line segments approximate the curve of the real road). Intersections are nodes too. Nodes have properties too (the most relevant is when a node represents a barrier).

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

    Historically, the tracks used for navigation were actually recorded rides.

    Route planners let you create a made-up (synthetic) ride. They are a relatively recent thing.

    When the device calculates a route, it can only stick to the lines on the map. As far as it can tell, the regions in between the lines are "lava" (a place it is impossible to go).

    When aren't using a track and have the device calculate a route, it will select the roads to use in the route according to the "avoidances" you've selected ("avoid highways", "avoid toll roads", etc). It won't use roads the wrong way.

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

    If you use a track, it doesn't use the avoidances. It shouldn't consider the avoidances.

    The basic point of designing a route is to pick the roads you want to use. You don't want the device to override your choices.

    I'm not sure what it does with wrong way roads when using a track.

    It seems it won't go through a node that is designated as a "kissing gate" (a kind of barrier).

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

    When using tracks, I think the device should ignore barrier properties of nodes (that is, the routing algorithm should treat the node as passable and route through them. When using tracks, I think the routing algorithm should ignore the road direction. These things would be very easy to implement. (While you might not be able to ride through these restrictions, you might be able to walk through them).5

    I think the device should give up sooner on routing around "lava" ("off road" sections). That is, it shouldn't calculate long detours around places the map shows as impassible). This would be harder to implement.

    That is, when using a track, the device should behave as if you know more about where to go than it does.

    The track is an indication of where you want to go and that it's possible to go there. The device should work with the choices inherent in your track. Not against them.

  • "When using tracks, I think the device should ignore barrier properties of nodes (that is, the routing algorithm should treat the node as passable and route through them. When using tracks, I think the routing algorithm should ignore the road direction. These things would be very easy to implement. (While you might not be able to ride through these restrictions, you might be able to walk through them)." I disagree with your statement here. First of all how does one use 'Tracks' to make the 530 ignore the rules of the land and just blindly follow whatever route i lay down. 

    I believe the routing algorithm is that the priority is to route by the rules of land - that means road directions. In my case - A kissing gate exists to avoid cars/motorcycle (too big to fit through the kissing gates)  being used on the trail. So the 530's routed a go-around.

    You can plot a nonsense route and load it to the 530 but the 530 will only go along the nonsense route as far as the rules of the land allow it. I can see why the garmin programmer(s) implemented it that way - for safety and legal reasons. 

  • I disagree with your statement here.

    Why?

    What the map installed on the device says you can do might not reflect reality.

    If you spent time doing detailed research into the route, why would you want the device to decide to contradict you (and, possibly, plot a miles-long detour around something you don't need to avoid)?

    You were complaining about a detour around a spot it appears you wanted to go through. It's a 12 mile detour for something you could easily push a bicycle through.

    to route by the rules of land - that means road directions

    No, the device uses the data in the map installed on the device. The OSM maps often have errors.

    In my case - A kissing gate exists to avoid cars/motorcycle (too big to fit through the kissing gates)  being used on the trail. So the 530's routed a go-around.

    Is there a "kissing gate" there? Street view shows bollards.

    While you wouldn't be able to drive a car through there, why do you think it's reasonable for the device to force you to avoid that location on a bicycle?

    Are you using a bicycle (or walking)? Are you happy with the detour the device wants you to make?

    I can see why the garmin programmer(s) implemented it that way - for safety and legal reasons. 

    The internal routing is problematic (it's common to hear about issues with it). It doesn't always plot "safe" routes and will happily use roads that are not particularly safe for cycling.

    The "safety and legal reasons" for the gate don't (it seems) to apply to cyclists.

    If you need the device to keep you from driving through "kissing gates", you are misusing the device.

    If you need the device to keep you safe, you are misusing the device.

    If you need the device to keep you safe on a route you researched and planned, you are misusing the device.

    First of all how does one use 'Tracks' to make the 530 ignore the rules of the land and just blindly follow whatever route i lay down.

    ???

    You want the device to plot you around things for "safety and legal reasons" but want to have it ignore those reasons?

    Anyway, you turn off "turn guidance". 

  • If you are planning a route (and creating a track), you should already be dealing with the "safety and legal issues".

    It doesn't seem many people would be happy to have the unit decide (maybe, based on bad map data) to contradict that work.

  • Don't mean for this to get bigger than Ben-Hur but i happen to have some time to kill. Ultimately i just want to learn about the 530's behaviour so that i can avoid problems while riding.

    "You were complaining about a detour around a spot it appears you wanted to go through. It's a 12 mile detour for something you could easily push a bicycle through." - it's a new area, so if the 530 decides to do the 12 mile detour, I wouldn't know better - until i realised this is taking much longer than expected. Again it's a new area to me - i would not recognise the turnoff unless the 530 points to it.

    Kissing gate or Bollard - whatever - evidently there's something there to block RidewithGPS to autoroute through it - I don't know if the 530 will perform like RidewithGPS with it's TBT. If it does it will make add a 12 mile detour to my route - not happy. Obviously i want to avoid that.

    And as for the 'track' - so if i disable TBT then it becomes a track ? Is that what you mean when u use the word track - thus i can go along the magenta colored route that will be faithful to my planned route (without the 530 possibly deviating me away from the planned route).

    Summary - i don't know how the 530 will treat the bollard (kissing gate) until i'm actually riding. So i've decided to play it cautiously and break the route up into 2 sections.

  • Ultimately i just want to learn about the 530's behaviour so that i can avoid problems while riding.

    I'm explaining how the device works. With the "whatever" nonsense, being dismissive about what people are saying won't help you do that.

    Kissing gate or Bollard - whatever - evidently there's something there to block RidewithGPS to autoroute through it - I don't know if the 530 will perform like RidewithGPS with it's TBT.

    Not "whatever". If you want to learn about the behavior of the device, you need to understand how these map features work and are used. Since the map features are supposed to reflect reality, then what is really there matters too.

    RWGPS shouldn't block routing for cyclists if it's a bollard on the map.

    Being specific about the feature is necessary to understand the behavior.

    The behavior (of RWGPS and the 530) has two places that could be the source:

    • If RWGPS does block bollards, then RWGPS's routing algorithm is wrong.
    • If the actual barrier is a bollard (not a kissing gate), then the map data is wrong.
    If it does it will make add a 12 mile detour to my route - not happy. Obviously i want to avoid that.

    You aren't happy about the detour but you also think the device should adhere to the "rules of the land" for "safety and legal reasons". With the way these work, you can't have the device avoid details and adhere to the "rules of the land".

    And as for the 'track' - so if i disable TBT then it becomes a track ? Is that what you mean when u use the word track - thus i can go along the magenta colored route that will be faithful to my planned route (without the 530 possibly deviating me away from the planned route).

    You are being vague and too nonspecific here too.

    Look at my posts in this thread. They won't explain everything but they will give you a basis in asking questions more clearly.

    forums.garmin.com/.../navigation-screen-mapping

  • We all like to learn, everyday is a school day :-)

    <nerdmode>

    Anyway, there can be a big difference between the different type of barriers. e.g. this is the points file from the OpenTopoMap as an example.

    barrier=bollard | barrier=cycle_barrier 
        { add mkgmap:bicycle=yes; 
          add mkgmap:foot=yes; 
          addaccess no;
          set mkgmap:road-speed=1; }
    barrier=bus_trap  
        { add mkgmap:bus=yes; 
          add mkgmap:foot=yes; 
          add mkgmap:bicycle=yes; 
          addaccess no;
          set mkgmap:road-speed=1; }
    barrier=gate
        { add mkgmap:bicycle=yes; 
          add mkgmap:foot=yes; 
          addaccess no;
          set mkgmap:road-speed=0; }
    barrier=kissing_gate | barrier=stile | barrier=block
        { add mkgmap:foot=yes; 
          addaccess no;
          set mkgmap:road-speed=0; }

    These files are used to convert the raw OSM data into a map file that the Garmin can use.

    Hopefully you can interpret from this that cycling would be allowed through a bollard, cycle_barrier, bus_trap (?) and gate but would not be allowed through a kissing_gate, stile or block.  Now although this isn't the same file that Garmin uses it gives you idea that the type of map feature is important.

    </nerdmode>

    That trail looks sweet btw ;-)  Nice area.  Is it paved (hard to tell from Google StreetView as its covered in leaves)?

    Summer time down south :-), crappy mild and wet in the UK right now.

  • Just to be clear, Davemorrisuk is showing the rules used to convert Openstreetmap (OSM) data to a Garmin "img" map (done using a program called "mkgmap").

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

    Hopefully, Garmin uses the same sort of rules in creating its maps.

    Barriers can also be tagged in OSM with "access" types. Ideally, those should be used when generating the map too.

    It's due to the existence of those sorts of rules that I updated the barrier in OSM to be a bollard (as it is in Street view). That update probably won't help Machoman but not will help others in the future. 

    I think the path is dirt (it's doesn't appear to be in a densely-populated place (which would justify the cost and maintenance of pavement).

  • Former Member
    0 Former Member over 4 years ago in reply to dpawlyk

    Dammit - wish the Edge would just blindly follow my planned route - in RWGPS this 'gate' thing is preventing me from routing through the track properly.

  • Do you know what's really there?

    PM me the location.