No Return order generated
Question problem or better in help "New Idea" ?
Locus V 3.18.9
Observed in real drive situation using function: Navigation to Point by Locus_B-router.
Out of track alarm set 75 m and Recalculate distance: 100 m.
Map view: Rotate Map.
Following a proposed Navtrack with correct map orientation toward the South.
A Navigation Order "Right" (to the West), but decide to skip the order, and use a next alternative road further away, so keep driving straight forward to South.
After +/- 100 m by auto recalculation trigger, suggests a return, but shows ONLY 180° rotated map view, without return TTS message nor special indication by Icon.
This 180° map rotated map, opposite to the moving direction, causes some confusion. Result using Map fixed to the North is +/- less confusing.
Q: After recalculation, should (can ?) the map not be oriented toward the moving direction, and generate a (TTS) Return order and Icon Point ? Point Icon because if user still decides do a return, in use as universal indicator, till a next clear (Left if returning) Navorder shows up.
Can this rerouting experience be improved somehow or do I a miss a more precise setting ?
And yes sure , I do realize...is probably not a simple task, to serve users not obeying some navigation orders ;-)
Video: https://youtu.be/BxPXXnsI6T0
When passing the Right navorder the map orientation changes toward the expected navigation direction. Strange to see (user still moving straight but reported position keeps hanging) but as such, acceptable. However after recalculation(s) the resulting 180° rotated map view in real drive situations is rather confusing.
The same question
Good morning Willy,
I understand your point and agree, that in case of BRouter, this is a problem in the field.
Unfortunately I think that just placing "turn around" command as first point in such cases, may be little dangerous.
I've already wrote about this to Arndt (author of BRouter). What is missing here, is a feature that should already work with MapQuest maps. In MapQuest, Locus also send information about current user movement and also time needed till user react (current 3 seconds) ... heh, I'm just check it and seems that there is an issue and even MapQuest do not handle it correctly for recalculation ... so MapQuest in next version.
Anyway point here is, that best solution should be, if such command will be received directly from BRouter. So Locus should say ... "compute me track from current location to this location and now I'm moving this direction and at least for X seconds, do not give me any order as I need to slow down and react firstly". I believe that should feature on side of BRouter will be implemented soon or later as it is quite useful.
Hope you get my point.
Good morning Willy,
I understand your point and agree, that in case of BRouter, this is a problem in the field.
Unfortunately I think that just placing "turn around" command as first point in such cases, may be little dangerous.
I've already wrote about this to Arndt (author of BRouter). What is missing here, is a feature that should already work with MapQuest maps. In MapQuest, Locus also send information about current user movement and also time needed till user react (current 3 seconds) ... heh, I'm just check it and seems that there is an issue and even MapQuest do not handle it correctly for recalculation ... so MapQuest in next version.
Anyway point here is, that best solution should be, if such command will be received directly from BRouter. So Locus should say ... "compute me track from current location to this location and now I'm moving this direction and at least for X seconds, do not give me any order as I need to slow down and react firstly". I believe that should feature on side of BRouter will be implemented soon or later as it is quite useful.
Hope you get my point.
Ok ok...thanks for info.
Ok ok...thanks for info.
Anyway I hoped there was a more simple solution.
As the uncomfortable map rotating only is present using "Snap to route".
So prefer to use the other alternative setting solving this map problem
Snap to route SET. (Text from manual)
- Ignores slight inaccuracies of GPS positioning and maintains the navigation cursor position on the navigated route
Snap to route: UNSET: Example video: https://youtu.be/XDLMitAcQLY
- Second arrow indicates gps location and direction, map centered around this indicator.
- Map orientation to moving direction, results in a logical rotating map view.
- Less stable map orientation by "live gps" location. Improve stability by stronger (slower) filter ?
Anyway I hoped there was a more simple solution.
As the uncomfortable map rotating only is present using "Snap to route".
So prefer to use the other alternative setting solving this map problem
Snap to route SET. (Text from manual)
- Ignores slight inaccuracies of GPS positioning and maintains the navigation cursor position on the navigated route
Snap to route: UNSET: Example video: https://youtu.be/XDLMitAcQLY
- Second arrow indicates gps location and direction, map centered around this indicator.
- Map orientation to moving direction, results in a logical rotating map view.
- Less stable map orientation by "live gps" location. Improve stability by stronger (slower) filter ?
Replies have been locked on this page!