Problems with navigating a route

[menion]

Surprised it works correctly to you . Anyway, new version just published.

And now it seems to be working well ...

[menion]

Thanks for tests. If you in the first case get some navigation order on "meeting points", it should be more an accident then intent. I was thinking if the app should generate some navigation command on this crossing, but in the end, I've decided to left it rather "empty" then generate incorrect command just based on shape.

In the second case, there seems to be missing single trackpoint on the crossing. It may probably happen. We will see in terrain . But generally, it seems to work correctly, fine.

[jonny.blue]

Did some (couch-  )testing too ... and in many cases it works pretty good.

Only one time it leads me directly back to my starting point  ... but I couldn't repeat this ...

I think it's time for field test ... (when rain stops  )

[jonny.blue]

PS: can I change the value (30 sec) for delay time of recalculation  in config file?

Would be good for testing ... and maybe even in field ... because:
If Locus doesn't lead back I'm normaly back on route after recalculation. In other case my setting 'distance for recalculate' would prevent from immediately calculation.

[menion]

And raining and raining ... which is fine, nature was really dry.

30sec refresh is hardcoded in the app. If you want to trigger it earlier, you may simply over navigation menu manually, so I believe there is no need for customization here.
30 seconds is from my point of view optimal limit to prevent too frequent recalculation. And years of usage confirmed this .

[menion]

Hello Willy,
thanks for the tests.

Point-priority: are there any changes in Beta version? Should not. Via-points are really must-pass points.
Option to skip via-point is really missing as well as the option to add via-point during navigation. I've well aware of it and it's planned.

Route-priority: what happens to you should really not happen . Send me please your route as GPX, I'll test it, thanks.

[jonny.blue]

30 seconds is from my point of view optimal limit to prevent too frequent recalculation. And years of usage confirmed this .

No problem  ... 

[menion]

@0709
Heh, same as in my answer 11 days ago on the help desk, I mix two cases, sorry .

We talk here about recalculation, so I again wanted to say that for point-priority, via-points are must-pass.

Anyway, new version 3.37.2.13 just published and it should solve
a) issue with via points & route-priority as in attach file (thanks for help)
b) added hopefully nice tool that should prevent recalculation back if user ignore "turn back" 2 times. So if you ride forward, app two times recalculate back and you still ride forward, 3rd recompute should be forward and not backward.

[menion]

uff, both issue should be fixed, thanks. The whole system is quite sensitive on indexes, so I'm sure there will be a situation when the result won't be perfect. Step by step to victory .
Thanks Willy!

[jonny.blue]

After now 2 month of discussion and developement I want to give a (positive) feedback.

I tried the new version now with two longer biking routes .... and navigation along a route works (almost) perfect.

I planed the route within route planer /brouter ... included some caches ... choosed my biking profile ... and the fun could start.

I was a little scared when I saw the first deviation ... but all worked well.

Some missed turns by me leads to some further deviations ... but more or less I found back to my route without stoping on every second parking place.

Thx for your work and patience .... today for me it was great fun just to ride and get guided by Locus.


Within those deviations I saw that it really wouldn't help if you recalculate to much (because I set my distance for recalculation to 40m) but ... I had a new idea:

The problem when you leave your planed route is that Locus leads you directly back from your current positon.
While walking this is no problem ... but with car or bike it's almost impossible.
Maybe it's better (when motorized movement) to navigate straight in the actual direction and look for a "allowed" turn.
Then it would be not such a stress to have no possible guidance (because turning on street is most time not possible) ...
The second advantage would be that if you decide to ignore this short turn ... the next possible turn is generated or maybe even a better route back is found. (That's very near to my car navigation).

[menion]

@jonny.blue
thanks for the feedback. The positive one is rare and always welcome .

When we talk about recalculation & BRouter, it is a little bit complicated. Locus Map already sends to BRouter information about the direction of users movement. It has a small effect on the final router, but not so big.

Current solution: Locus Map perform two recalculations in a row. When results of both are ignored, it places no-go point behind your movement which blocks recalculation back. So, if you miss turning and will ride still straight, in the worst case after 90 seconds you receive the result that won't force you back.

As Willy correctly mentioned, there are two options that may be fine-tuned (among others).
- number of ignored recalculations till way back is blocked (may be created as an optional parameter)
- hardcoded timeout (is in app +- since begin, have to be improved in the code itself)

[menion]

@0709
to the problem with "recalculation" ... believe it's better now, thanks!

[CabrioTourer]

Just a (hopefully) small improvement idea.

Right now the no go area after two recalculation is set behind you.
Sometimes there is just in front of you an alternative way back to the point you missed. This means the goal of the no go area doesn't twork in this scenario.
Maybe it's better to place the no go area to the point you missed instead or in addition.

This should solve the problem.

I vote for an option when the no go area is set. In my case (car) I woul set it to zero. Means don't guide me back from the beginning.

Nevertheless thanks for the work you did in this area. Very welcome improvement.

[menion]

Hi guys, sorry for the small delay in my answer.

@0709
are you able to provide me (for example short video) where is visible incorrectly computed too long tail? Best for me is to simulate this problem so I can play with it a little bit, thanks.

@CabrioTourer
Nogo on missed point ... hmm does it make sense in case of "route-priority" recalculation?
... to be true, I do not have good feeling about it because I worry a lot of side effects, like completely blocked only way to target etc. Do you also have some example where this approach should make a big difference?

[jonny.blue]

Hi,
I switched to new 😎 phone with Android 9 Pie .... and after some struggling with settings ( especially power save settings ) all works well and I did my first bike tour today. 😎

With the new phone my hope was even with setting: 'enable/disable screen - turn on when notifying a track command'  changing to another app could work without entering a pin.

But ... also with new opportunities of android system to stay online Locus asks me for a pin when I change to another app ( GPS Status, even to Locus addon geocaching)
I wonder if this is really necessary or what triggers this behaviour.

- in android I disabled my lock mode while near to my trusted bluetooth headset ... so I don't need to unlock my phone.
- in Locus I don't activate 'disable screen lock'.

Therefore I hoped I can switch (when parking 😉) to other apps without entering a pin ( whyever fingerprint isn't requested).

Anyone any idea ... ?