First point is often ignored

[Greenham]

@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.

[Herman Veldhuizen]

@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.

[Stefan Hummelink]

@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 .

[Con Hennekens]

@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.

[Herman Veldhuizen]

@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]

@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...

[MyZ51]

@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]

@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.

[RetiredWingMan]

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.

[Con Hennekens]

@Herman-Veldhuizen said in First point is often ignored:

I am quite sure that every new user will at some point get surprised by this nearest point issue.

Considering the ZERO (+1) questions about it on the forum I am pretty sure it won't.
I am not saying no improvement is possible, but I do think you are probably overthinking it.

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.

Whether a WP is hit or not does not depend on the position of the waypoint itself, but on the projected position ON the road. That means that the actual start of the routeline, or the little black dot you see on the road if you place a WP next to it. And YES, this feature IS limited to the start, because that is when you continuously get send back to it when you start a route passed that point a little bit, which often happens on parkinglots and driveways. There were MANY complaints about the app keeping you guided back to the start, so YES there actually was a need to treat the start differently.

Or : can the app somehow check upfront wether the Start is misplaced?

It is not about the start being misplaced, it is about the rider being misplaced at the start.

I am used to the message from tomtom when i start navigating to a destination. It tells me the ETA.

That is not a bad idea, but probably most useful in A2B routes (single destination routes). You could of course take a look at your screen too, before driving off

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.

I have found myself in positions where I though some kind of back-button to skip back to the previous waypoint would come in very handy indeed. I find myself being too late pressing the revert button if a WP gets auto-skipped. That is because exactly at those moments I tend to be busy taking a wrong turn . So yes, I would welcome such a feature!

please spare me from your analysis on me. It serves no purpose.

Let's try to be respectful to volunteers who just try to be helpful.