Messages

>Who actually uses the current Locus gpx export?
I only use non-RTE format, so happy for you to ignore or discard my thoughts below

>Contains only start & shaping & Via and Finish as route points.
but dangerous - without any knowledge of the routing profile, on import the viewer (most likely Locus) could (mostly likely) create a subtly or completely different (unwanted) route/ track. Any setting like this should not be the default.

I know this because my old Garmin eTrex would generate completely different (unwanted) route/ track when only start/ finish point was in the GPX file (exported from RWGPS). As a new GPS user it was very confusing.

So there needs to be a clear warning on the danger of this style of export. Maybe the addition of a (?) icon/ button alongside the checkbox to explain the ramifications.

Using RouePlanner and showing itinerary I am not always able to swipe the list away downside and thought better not use the top-left exit-arrow, as it would possibly END Route planner. Yes, it does not and behaves like swiping down and brought me back, hides the itinerary.
Is this also irritating to others?

@T-mo - sorry, but can you explain further, or annotate a screen cap?

I'm more thinking about and option to put these buttons into function panels - but this also is not so simple task 

yes please - vote for https://help.locusmap.eu/topic/25808-add-zoom-buttons-to-list-of-function-panel-buttons

My device consumes 40-50% Battery on my 5-6h hiking trips and that didn't noticably change.

@tapio - interesting, thanks. I'm using ~2.5%/h (= 15%/6h) with 3000mAh (3Ah) battery (all other apps off, no mobile, only track recording, no navigation), and certainly wouldn't want much increase for constant sensor processing code. For simple movement detection, a check every 1 or 2s would be more than adequate resolution.

Sounds to me like Tasker would be consuming quite a lot of battery to process these simple situations of moving/ stopped.

shake sensor = Accelerometer = compass - https://en.wikipedia.org/wiki/Accelerometer

Obviously wouldn't work well on bike or in car

@tapio - no reason why not if properly coded

As for Pause (no movement) detection.

@tapio I'm hoping internal accelerometer will be used some time in the future for "no movement detection". Far more reliable than current GPS location method. Plenty of apps already use this for an "alarm". As far as I can tell, some Garmin GPS have used this method for a long time. Fellow riders with Garmin GPS beep nearly instantly they stop, whereas the Locus track can show constantly moving position +/-7m.

So I guess an option to add Waypoints like "Pause @ {t}: mm:ss" shouldn't be too far away.

+1 nice idea - add a Help suggestion for voting?

@Žajdlík - I was unable to reply to your last post from 4.3 topic. I agree your "{t} <from> <to>" looks fine, but I just feel a more generic {t} as a default setting is more universal. I have 2 friends I've recently introduced to Locus, and even though pretty tech savvy, they still find LM4 a little overwhelming to get started, and find hidden features I am using. I don't see any easy way around this except for some very advanced AI that can make expert recommendations - maybe LM7 in 10 years time?

I would suggest a new name template {T} = YYYYMMDD-HHMM. This would mean multiple recorded tracks on same day have a unique name, and can be properly sorted alphanumerically - {t} = YYYYMMDD.

@menion - recording profile > track name format: {t} is described, but how does any user discover the other pre-defined tags? Maybe a (?) button at right side of "pre-fill format" textbox brings up list of tags?

FWIW my profile template name was not affected. I would suggest a track/filename more compact & unique like {t}"-"<ascending-serial#> or just {t} if time is included to make the name unique (I can't recall). The other suggestions are heavily dependent on personal preference, and will often result in a quite long name that subsequently has to be mostly partially deleted by many users.

Does metres really have a sense? Hmm ...

@Menion - to me, maybe @0709 too? the distance to the next navigation announcement makes more sense than time. Each could have advantages in different scenarios though. I generally find the shortest time in the setting (eg. 30|180|300) is somewhat unreliable, but the most crucial. The actual 30s announcement is anywhere between only 10s to 30s before the turn, as this is often when speed is slowing down, so I often have to turn on display manually anyway. Maybe a fixed distance setting here would be more predictable?

vote for this suggestion from 3 years ago too - https://help.locusmap.eu/topic/transfer-function-in-config-cfg-to-gui-navigation-expert-setting

(edited your quote with my emphasis)
current navigation_announcements_times=15|35|300
proposed navigation_announcements_distances=75|175|1500
Selection in meters would have the great advantage: Simplicity and clarity.

@0709 - ok, thanks for clarifying. yes, this could be a good enhancement - help topic?

With a choice of time (in seconds) but certainly also the more simple select distance in meters.
Time default is 15|35|300 sec or Distance default 75|175|1500 meters
Selection in meters has the great advantage: Simplicity and clarity.

@0709 - I currently have "navigation_announcements_times=30|180|600" - are you saying the values can be "sec" or "meters"? What is the full syntax? The keyword "..._times" implies these values are "sec" not "meters". This is certainly one hidden gem setting that would be good to migrate to UI expert settings.

4.3.3.8_1035: for me at ZL9 to ZL11 there are a little too many distance markers (eg attached), but it's just minor, and now without "km" in label, it is near perfect. Thanks @Menion.

re config.cfg - also beware - don't bother adding your own comments after the hash# character, as these will be deleted next time config.cfg is written

"Km" symbol ... I know, but I have to consider other units that may be currently selected. It also helps to avoid confusion with labels of points or other content on the map. Hmm for now, I think that they are so small, that the "km" symbol causes no issue ...

@menion I disagree, surely this "km" text is a waste of valuable space, see screen caps (note this track was out-and-back; there are way too many labels for ZL <= 14. At ZL 15 & 16 they are mostly OK, then ZL 17+ there are too few or none! Can they be dynamically adjusted to just have 3 or 4 at any given ZL? This scheme then works for high ZL where only a few 100m are displayed. PS - new beta/ same name - seems to be better

Can the labels be toggled from the Route Planner?

I think a warning is needed in the app, to protect developers from possible legal action, but even more so to clarify that ETA is not an exact science, but a rough estimate.

@lor74cas - if user has to enter their details for their own profile, then onus is back on the user for the ETA. Not fully because there is the algorithm behind the scenes, but still one more reason that user specified profiles are +1.