Automatic display activation = guiding with display and sounds
The discussion is already here. Thanx to @jusc for opening.
My expectation were always that Locus turn on the display on junctions or crosssroads even when guiding (not navigating) along existing tracks. But it doesn't :(
So the new request is:
: Locus should compute navigational orders as sounds along the track but w/o the common used signs displayed for left or right, w/o any voice guiding
: Locus should activate the display when a turn / junction / crossroad is ahead (if notifications are enabled) to give the user (biker) a short hint where to go = hand free = matter of safety
: adding manual turn instructions should not be necessary
: different sounds should be generated for "left", "right" and "attention" (if a situation is not clear). Suggestion for sounds are either using international morse code or arbritrary sounds choosen by the user
: Alerts for "away from track" and POI notification are unaffected
: the track should keep the color and line style of the folder where the track is called from
: The arrow line to the next trackpoint should be kept 'cause its very helpful
: Filter like in navigation (hight, medium, low) shoud be kept also.
: The battery consumtion should be similar to pure guiding plus the additional time when the display is on (automatic dimming can switch of the display again).
This feature gives a minimum information about the further way to go with a maximum on battery saving and safety while biking or hiking.
Would be nice to have a lot of votes for these feature request.
Christian
I like this idea 
A first "how to" in: Locus forum.
http://forum.locusmap.eu/index.php?topic=3318.msg30858#msg30858
https://dl.dropboxusercontent.com/u/35289926/prepare%20track.pdf
A first "how to" in: Locus forum.
http://forum.locusmap.eu/index.php?topic=3318.msg30858#msg30858
https://dl.dropboxusercontent.com/u/35289926/prepare%20track.pdf
Waypoint Snapper.
All (free) Waypoints along track in 6 m corridor are snapped, and listed in correct trackdistance order, then used for Navi guiding during track drive.
Waypoint Snap on track action.
Waypoints along track in 6 m corridor should be "snapped ontrack" when exporting to a new trackfile with merged way(course)points.
Waypoint Snapper.
All (free) Waypoints along track in 6 m corridor are snapped, and listed in correct trackdistance order, then used for Navi guiding during track drive.
Waypoint Snap on track action.
Waypoints along track in 6 m corridor should be "snapped ontrack" when exporting to a new trackfile with merged way(course)points.
Some of the ideas published in the forum to generate L/R Morse signals where never published in this help desk because far too complicated to realise.
Lets hope that this proposal is a better solution, by using a "fixed" Locus .tcx solution. In A next Locus version ?
Using the .tcx file format possibilities as explained in the attachment. Alternatively even .gpx files format could be used. But thats for later.
The notify arbitrary sound alert should work independently from the used local language. The TTS sound (and eventual visual text notify) alert should be available in the used local language.
Pse. See the .pdf attachment.
Some of the ideas published in the forum to generate L/R Morse signals where never published in this help desk because far too complicated to realise.
Lets hope that this proposal is a better solution, by using a "fixed" Locus .tcx solution. In A next Locus version ?
Using the .tcx file format possibilities as explained in the attachment. Alternatively even .gpx files format could be used. But thats for later.
The notify arbitrary sound alert should work independently from the used local language. The TTS sound (and eventual visual text notify) alert should be available in the used local language.
Pse. See the .pdf attachment.
+1 would be great
+1 would be great
If I corrently understand ... ehm. Implemented ;).
I'll be waiting for feedback after some field tests with new Beta version (planned on tomorrow 26. March).
If I corrently understand ... ehm. Implemented ;).
I'll be waiting for feedback after some field tests with new Beta version (planned on tomorrow 26. March).
Awesome, thanks Menion! :)
Is there a changelog, or can we try the Beta somehow?
Awesome, thanks Menion! :)
Is there a changelog, or can we try the Beta somehow?
This must be heaven! Thanx menion! Looking forward to new version...
(I'm not able to leave a comment here with smartphone due to strange design for mobiles :( )
This must be heaven! Thanx menion! Looking forward to new version...
(I'm not able to leave a comment here with smartphone due to strange design for mobiles :( )
ok, guidance with automatic display activation is implemented. Great!
But the thread should not marked as 'completed' because sound and track styles are missed.
ok, guidance with automatic display activation is implemented. Great!
But the thread should not marked as 'completed' because sound and track styles are missed.
This is a thoughtful feature request, especially for cyclists and hikers who don't want to keep checking the screen. I also like the idea of using distinct audio patterns instead of spoken instructions, since they're language-independent and much less distracting.
If Morse-style alerts are ever considered, keeping them short and consistent would probably make them easier to recognize without overwhelming the user. For example, a simple pattern for left, another for right, and a separate warning tone for attention points could become intuitive after a little practice.
When I experiment with Morse patterns or want to verify how a sequence should sound, I usually use https://morsecodetranslatr.com/ as a quick reference. It's handy for checking both the visual code and the corresponding audio before implementing ideas like this.
Overall, I think combining automatic display wake-up with simple audio cues would make guidance safer while keeping battery usage low. It seems like a practical balance between navigation and minimal distraction.
This is a thoughtful feature request, especially for cyclists and hikers who don't want to keep checking the screen. I also like the idea of using distinct audio patterns instead of spoken instructions, since they're language-independent and much less distracting.
If Morse-style alerts are ever considered, keeping them short and consistent would probably make them easier to recognize without overwhelming the user. For example, a simple pattern for left, another for right, and a separate warning tone for attention points could become intuitive after a little practice.
When I experiment with Morse patterns or want to verify how a sequence should sound, I usually use https://morsecodetranslatr.com/ as a quick reference. It's handy for checking both the visual code and the corresponding audio before implementing ideas like this.
Overall, I think combining automatic display wake-up with simple audio cues would make guidance safer while keeping battery usage low. It seems like a practical balance between navigation and minimal distraction.
Replies have been locked on this page!