Definition of nearest point on track
-
I have been surprised a number of times when starting the navigation (as track) while being on the track already, between 2 points. Currently the app seems to find the waypoint with the shortest straight line distance from the current location. This then can result into the app sending me in the REVERSE direction (and this is especially surprising if the auto recalc setting is off). The path to the nearest waypoint can then be LARGER then the path to the next point on the track. I know that opinions differ but I still think that it would be more logical if the app would take the direction into account and start with navigating to the NEXT point on the track. If I am away from the track and recalc is off I expect the app to NOT calculate any path, in the same way as when I an following the track but deviate from it at some place.
-
I have been surprised a number of times when starting the navigation (as track) while being on the track already, between 2 points. Currently the app seems to find the waypoint with the shortest straight line distance from the current location. This then can result into the app sending me in the REVERSE direction (and this is especially surprising if the auto recalc setting is off). The path to the nearest waypoint can then be LARGER then the path to the next point on the track. I know that opinions differ but I still think that it would be more logical if the app would take the direction into account and start with navigating to the NEXT point on the track. If I am away from the track and recalc is off I expect the app to NOT calculate any path, in the same way as when I an following the track but deviate from it at some place.
@Herman-Veldhuizen I think that I have managed to reproduce the behaviour which I have found in logical. The test route is very small and not very relevant but therefore hopefully good for debugging.
My test route: www.myrouteapp.com/route/open/10505395.
Also @ginogino seems to run into this issue (
https://forum.myrouteapp.com/post/59115).I am at the location indicated by this picture.
When I start the navigation then the app sends me to point 3 , which is what I expected. However when i delete point 3 the App sends me first to point 2 (which I did not expect). In both cases point 2 is the nearest point (straight line distance) and in both cases point 3 or 4 is the nearest when direction is taken into account. I use navigate as track, use all waypoints.
-
@Herman-Veldhuizen I think that I have managed to reproduce the behaviour which I have found in logical. The test route is very small and not very relevant but therefore hopefully good for debugging.
My test route: www.myrouteapp.com/route/open/10505395.
Also @ginogino seems to run into this issue (
https://forum.myrouteapp.com/post/59115).I am at the location indicated by this picture.
When I start the navigation then the app sends me to point 3 , which is what I expected. However when i delete point 3 the App sends me first to point 2 (which I did not expect). In both cases point 2 is the nearest point (straight line distance) and in both cases point 3 or 4 is the nearest when direction is taken into account. I use navigate as track, use all waypoints.
@Herman-Veldhuizen, most people do NOT want to be send to the finish straight away, so that has been avoided by adding this logic to the calculation. Also the nearest point logic, as far as I know, accounts for going into the right direction.
So in your example, WP3 seems logical, and if you remove WP3, the new WP3 is the endpoint and to avoid being send directly to finish it sends you to the previous nearest point, which following the logic is now WP2.
It may not make much sense in this manufactured test, but in normal scenic routes it works quite well
I am just an enthusiastic MRA user, and hope you will be one too!
Most motorcycle problems are caused by the nut that connects the handlebar to the saddle.
Streetpilot 2610/Zumo 660/Zumo 395/ CAT S52 + MRA app -
@Herman-Veldhuizen, most people do NOT want to be send to the finish straight away, so that has been avoided by adding this logic to the calculation. Also the nearest point logic, as far as I know, accounts for going into the right direction.
So in your example, WP3 seems logical, and if you remove WP3, the new WP3 is the endpoint and to avoid being send directly to finish it sends you to the previous nearest point, which following the logic is now WP2.
It may not make much sense in this manufactured test, but in normal scenic routes it works quite well
@Con-Hennekens Ok thanks. Good to hear that the direction of the track is taken into account.
I had more cases where the app sends me into the opposite direction. I will keep a watch on this and let you know when it happens again. -
@Herman-Veldhuizen, most people do NOT want to be send to the finish straight away, so that has been avoided by adding this logic to the calculation. Also the nearest point logic, as far as I know, accounts for going into the right direction.
So in your example, WP3 seems logical, and if you remove WP3, the new WP3 is the endpoint and to avoid being send directly to finish it sends you to the previous nearest point, which following the logic is now WP2.
It may not make much sense in this manufactured test, but in normal scenic routes it works quite well
@Con-Hennekens Ok I think that I know a bit more now. The issue is that when standing still, the app might think that I am actually moving (at low speed, 1 or 2 km/h) due to the (limited) gps accuracy. When the app thinks that I am moving in the opposite direction it ends up with a recalculation and a possible wild path to the first/next point. Do you agree? I have never experienced such behaviour with tom tom and I hope you can find a solution for this.
-
@Con-Hennekens Ok I think that I know a bit more now. The issue is that when standing still, the app might think that I am actually moving (at low speed, 1 or 2 km/h) due to the (limited) gps accuracy. When the app thinks that I am moving in the opposite direction it ends up with a recalculation and a possible wild path to the first/next point. Do you agree? I have never experienced such behaviour with tom tom and I hope you can find a solution for this.
@Herman-Veldhuizen, This could perhaps explain what you experience, especially when that WP in the wrong direction is a VIA and therefore not skipped at recalculation when you go in the right direction. I am definitely not going to find a solution for this, as I am no developer at MRA ;-). I can only suggest that you look at the first to be visited waypoint yourself, before you put on your gloves and correct that yourself when needed by skipping one WP. That's a habit I taught myself
Don't forget to shout that to the rest of the group too 
I am just an enthusiastic MRA user, and hope you will be one too!
Most motorcycle problems are caused by the nut that connects the handlebar to the saddle.
Streetpilot 2610/Zumo 660/Zumo 395/ CAT S52 + MRA app -
@Herman-Veldhuizen, This could perhaps explain what you experience, especially when that WP in the wrong direction is a VIA and therefore not skipped at recalculation when you go in the right direction. I am definitely not going to find a solution for this, as I am no developer at MRA ;-). I can only suggest that you look at the first to be visited waypoint yourself, before you put on your gloves and correct that yourself when needed by skipping one WP. That's a habit I taught myself
Don't forget to shout that to the rest of the group too @Con-Hennekens My waypoints in question were shaping points. Interesting enough TomTomGo on the same phone and in the same car doesn't have this issue. I am guessing that TomTom assumes that a very low speed (with a low accuracy) is the same as no speed. And it probably quickly recalculates when it finds out that the direction changes. With MRA you get only one shot. Having to zoom out and check what MRA has come up with after each restart is not really a motivating solution.
-
@Con-Hennekens My waypoints in question were shaping points. Interesting enough TomTomGo on the same phone and in the same car doesn't have this issue. I am guessing that TomTom assumes that a very low speed (with a low accuracy) is the same as no speed. And it probably quickly recalculates when it finds out that the direction changes. With MRA you get only one shot. Having to zoom out and check what MRA has come up with after each restart is not really a motivating solution.
@Herman-Veldhuizen said in Definition of nearest point on track:
Having to zoom out and check what MRA has come up with after each restart is not really a motivating solution.
That's just a question of habit I think. I never leave without having seen for myself I am going in the right direction.
