First point is often ignored
-
@Mzokk Or i start to drive backwards first if I dont want to move the first point. I consider both solutions workarounds to an already existing work around.
@Herman-Veldhuizen Then no matter what GPS system you use you will continue to go round in circles.....as a long time Garmin user and convert to MRA.
- list item
-
@Herman-Veldhuizen Then no matter what GPS system you use you will continue to go round in circles.....as a long time Garmin user and convert to MRA.
- list item
@Mzokk No need to worry about me. I am more worried about others which have to explain for ever why point 2 is considered the nearest point in my first scenario. The only correct answer will always be point 1.
-
@Herman-Veldhuizen
Maybe a stupid reaction.
I only watched your first video. But something you can check.
If you draw a straight line from your postion to (way)point 1 and a straight line from your to the postion where the route is picked up.
Which line is the shortest?(I use MRA Next only on Android Auto. Every comment, suggestion, etc will be based on my usage with Android Auto)
-
And for every GPS system I've used 9 for the past 20 years it's still good practice to put your first point some distance away from where you are, on the route you want to take be it Garmin, MRA, OSMand, Kurviger etc. It's not a workaround the very smart (but dumb) GPS system does not know that you haven't passed through point one if you've missed it and will try to take you back through it as its designed to do. MRA by giving the option to start from the nearest point on the track is a workaround for misplaced first points. Take the scenario that you are at a hotel and place your first point for your onward journey at what you think is the exit to the carpark which turns out to be the entrance and the exit is on the direction of travel. without the option to start at the nearest part of the track the GPS will continually try to take you back to the entrance as you will never pass through that point. If you put your first waypoint some way down the road in the direction of travel the "problem" never arises as the GPS unit at the hotel knows where you are and will guide you through the first point. So you will have no issues on not passing through the first point.
-
@M.-Schrijver The shortest is still the one to point 1. I might be wrong but I dont think that mra uses track-points as targets, only waypoints can be targets, as least when finding the nearest point. With the skip-the-start logic the nearest becomes point 2 and HERE finds a path to point 2, which in this case simply bypasses point 1.
@Mzokk I did what I have read in this forum : i placed my first point (roughly 300m) away from my current position, but it was apparently not far enough according to the current logic.
I dont see why the first point has to be treated different than any other viapoint when it comes to hitting. If I misplace it it is my own fault that the app keeps sending me there. I would understand it and accept it. Now i have to check what MRA comes up with and maybe get surprised. Add a few more of these sort of things and I loose my trust in it.
Note that Beeline on my phone will happily navigate to a point 300m away and it will nicely tell me that i have visited it, if i have. And if I have another at 100m away it will send me to that 100m point first. LogicalAnd : My first point might represent something real and interesting so I might not always want to move that point.
MRA's option to navigate to the nearest is useful to have (its not only for solving the problem of a misplaced start).
-
@Con-Hennekens We can discuss a solution, but I am pretty sure that anybody who isn't a mra expert will find it strange that the nearest point is point 2 and not not point 1 (in my route 'koffie'). Every other app out there will happily go to point 1 first.
As you can see in my video my gps accuracy good. I am therefore still 'far' away from the start and the most logical nearest point is the first. I shouldn't have to know the 'so many meters away' to understand what's going on. The app has an internal parameter to determine if a waypoint has been hit , it is confusing if there is a different parameter for the first point.
@Herman-Veldhuizen said in First point is often ignored:
@Con-Hennekens We can discuss a solution, but I am pretty sure that anybody who isn't a mra expert will find it strange that the nearest point is point 2 and not not point 1 (in my route 'koffie'). Every other app out there will happily go to point 1 first.
As you can see in my video my gps accuracy good. I am therefore still 'far' away from the start and the most logical nearest point is the first. I shouldn't have to know the 'so many meters away' to understand what's going on. The app has an internal parameter to determine if a waypoint has been hit , it is confusing if there is a different parameter for the first point.
I have seen this in the past, when I place the "END" of the route (circular route for example) if my END point is closer to me than my start point is, it tries to take me to the end point directly. I rarely use the closest and just pick my start point I created.
I'm sure this feature is useful if you restarted a route mid way through.
"There is no problem so bad that you can't make it worse"
- Chris Hadfield (NASA Astronaut)
-
@Herman-Veldhuizen said in First point is often ignored:
@Con-Hennekens We can discuss a solution, but I am pretty sure that anybody who isn't a mra expert will find it strange that the nearest point is point 2 and not not point 1 (in my route 'koffie'). Every other app out there will happily go to point 1 first.
As you can see in my video my gps accuracy good. I am therefore still 'far' away from the start and the most logical nearest point is the first. I shouldn't have to know the 'so many meters away' to understand what's going on. The app has an internal parameter to determine if a waypoint has been hit , it is confusing if there is a different parameter for the first point.
I have seen this in the past, when I place the "END" of the route (circular route for example) if my END point is closer to me than my start point is, it tries to take me to the end point directly. I rarely use the closest and just pick my start point I created.
I'm sure this feature is useful if you restarted a route mid way through.
@Greenham I can see that happening yes. But I would understand that the app picks that point, accept it and disable nearest or pick the point myself next time.
I like the way beeline can skip to next or previous without having to pick the point on the map. That would be useful in a scenario where it is not clear what the first point to go to should be. -
@Greenham I can see that happening yes. But I would understand that the app picks that point, accept it and disable nearest or pick the point myself next time.
I like the way beeline can skip to next or previous without having to pick the point on the map. That would be useful in a scenario where it is not clear what the first point to go to should be.@Herman-Veldhuizen said in First point is often ignored:
But I would understand that the app picks that point, accept it
Euhhh, you somewhat had me on board in the discussion regarding the wp1 and 2 issue, but now you've lost me completely. You would happily accept the app directing you directly to the end waypoint when start and end are close together? That absolutely makes no sense from an user perspective. You intent to ride the route from "start" to end, not directly to the end. Surely, I assume you expect and accept this behaviour based on your experience perhaps with other nav devices, but yet this phenomenon is an implementation issue of the algorithm on those devices and it makes no sense on its own whatsoever. I would certainly expect but not ACCEPT this behaviour.
Imho you're expecting the nav app to only fit with your own judgment and expectations (and even inherit some odd behaviour of other nav devices just so it matches your experiences) instead of a those of a wide user base from which little of your concerns are posted here.
Long story short, the algorithm that picks the "start" waypoint works quite nicely in almost all of the situations, sure there may be times when the result is a bit unexpected from a person's point of view, yet the app clearly shows what it does and the user has many options to deal with it, all just requiring a bit of knowledge of how the app is to be used (just like every other devices out there, for instance the "recalculation set to off* on all Garmin devices, which was also simply a way to prevent the device navigating directly to the end when you've parted from instructed route...)
Happy navigating
. -
@Herman-Veldhuizen
Maybe a stupid reaction.
I only watched your first video. But something you can check.
If you draw a straight line from your postion to (way)point 1 and a straight line from your to the postion where the route is picked up.
Which line is the shortest?@M.-Schrijver said in First point is often ignored:
If you draw a straight line from your postion to (way)point 1 and a straight line from your to the postion where the route is picked up.
As far as I know the decision is not made on distance of straight lines, but on distance over the road, probably measured in time and not in meters, if that's the parameter used in planning.
@Herman-Veldhuizen said in First point is often ignored:
I am more worried about others which have to explain for ever why point 2 is considered the nearest point in my first scenario. The only correct answer will always be point 1.
I watched the movie just now and see what you mean. It does seem funny that WP1 is skipped in this particular situation. I would however not worry about it at all. If you want to start at WP1, just unselect "nearest point" or long-press WP1 once navigating. There could be multiple reasons for what happens. Maybe a one-way road to WP1 or a speed limit that makes WP2 quicker despite that it seems to be further away. This feature certainly prevents MANY "why does it keep sending me back to WP1" questions, so let it go. It is really not worth the fuzz in my opinion.
-
@Stefan-Hummelink please spare me from your analysis on me. It serves no purpose.
@Con-Hennekens I agree this is a relatively small issue. But add it to a few other issues and the trust goes out of the window. Thats pretty much where I am now. Dont get me wrong : I like MRA. I can see it has potential also for non bikers and I would be happy to pay more if I trusted it.
I am quite sure that every new user will at some point get surprised by this nearest point issue. And I think by now that we all agree on the fact that it is confusing in my example that point 2 is picked as the nearest point. So the question is can something (simpel) be done to make it less confusing.
My thought: The distance the app uses to determine wether the start should be skipped or not seems to be quite large. When the accuracy of the gps position is good, could it be a smaller? The problem with misplaced waypoints is not limited to the start. Every other point has the same problem so I can only blame myself if my start is far away from the road. I dont see the need to treat the start any different.
Or : can the app somehow check upfront wether the Start is misplaced? By a mini simulation?Lastly, I am used to the message from tomtom when i start navigating to a destination. It tells me the ETA. A message like 'heading to waypoint 1 : Start' could be helpfull too. If it tells me 'heading to waypoint 2: Koffie' it would ring a bell.
And if you haven't done it yet, i suggest you try out Beeline one day. It doesn't support the concept of navigating to nearest point but is has an interesting way of skipping to next and previous.
-
@Stefan-Hummelink please spare me from your analysis on me. It serves no purpose.
@Con-Hennekens I agree this is a relatively small issue. But add it to a few other issues and the trust goes out of the window. Thats pretty much where I am now. Dont get me wrong : I like MRA. I can see it has potential also for non bikers and I would be happy to pay more if I trusted it.
I am quite sure that every new user will at some point get surprised by this nearest point issue. And I think by now that we all agree on the fact that it is confusing in my example that point 2 is picked as the nearest point. So the question is can something (simpel) be done to make it less confusing.
My thought: The distance the app uses to determine wether the start should be skipped or not seems to be quite large. When the accuracy of the gps position is good, could it be a smaller? The problem with misplaced waypoints is not limited to the start. Every other point has the same problem so I can only blame myself if my start is far away from the road. I dont see the need to treat the start any different.
Or : can the app somehow check upfront wether the Start is misplaced? By a mini simulation?Lastly, I am used to the message from tomtom when i start navigating to a destination. It tells me the ETA. A message like 'heading to waypoint 1 : Start' could be helpfull too. If it tells me 'heading to waypoint 2: Koffie' it would ring a bell.
And if you haven't done it yet, i suggest you try out Beeline one day. It doesn't support the concept of navigating to nearest point but is has an interesting way of skipping to next and previous.
@Herman-Veldhuizen said in First point is often ignored:
please spare me from your analysis on me.
Now that folks, is a prime example of a mature and substantive response...
-
Put the first point some distance say 1km away from where you are. The GPS system know where you are when you start and will navigate you through the first waypoint. This is good practice no matter what GPS system you are using.
@Mzokk I like this idea, but if cruisers are navigating to a start point, like a large retail outlet using the app from their residence, it will take them to a point 1km away from the meetup location.
I suppose that’s ok if everyone knows to navigate to the starting location, then shut down the route to the meetup location, and start the new route leading cruisers to the via point 1 km away.
Chuck
-
@Herman-Veldhuizen
Maybe a stupid reaction.
I only watched your first video. But something you can check.
If you draw a straight line from your postion to (way)point 1 and a straight line from your to the postion where the route is picked up.
Which line is the shortest?@M.-Schrijver I did some more testing related to nearest in another region with more mountains and while being somewhere halfway (not near the start). The app indeed finds a track point (when navigating as a track) or a waypoint (when navigating as a route) based on straight line distance. In both cases the result was not what I expected. Because of the mountain the time to those points was longer than the time to other points. It resulted in a route where part of it had to be driven in both ways. This is unrelated to the topic we are discussing here. So I have logged a ticket for support to look at and I suggest we leave that for now.
-
All this discussion about WP1. I use my brain, when starting a route I always look at what the Navigation software or device is going to do before I start off. Commonly, I will manually skip WP1 before heading out just to eliminate a possible issue. Been fooled too many times when I trusted the s/w or device and ended up in a mess.
