Messages

I do see the complexity in combining all searches together, and I can live with having to select different search "means". But one major bother, that should be not too difficult to change is this:
Everytime the search scope is changed, there's a new, empty input field. Why not prefill with the search term already entered in another search? All the time I start typing into a search field before realizing I have the wrong search - then I change it and have to start from scratch (unless I thought of that and copy-pasted the term, which of course is also a bother).

PS: I just realized that this works between internal point and track search, but that's the only place I found.

What about then at least adding support for PlusCode? That can be copied from Maps with one tap and surely be parsed by Locus search without ambiguity?!

@slarti76 - thanks, hadn't used +codes before. Still slower (many more taps) than direct "share" of a point from my testing:

• drag POI details down a few times
• tap on "See all"
• tap on +code (very little visual feedback BTW)
• switch back to LM4
• open Search (maybe side panel button)
• paste clipboard (maybe more steps here)

Yeah, agreed, but
a) if we don't have another always-working solution,
b) surely no problem with parsing (well-defined as far as I understand)
c) at least last two steps could be improved if Locus adds a PlusCode support by automatically inserting clipboard content in search field (if it parses as PlusCode).
Heck, Locus could parse the clipboard when opening the search and automatically switch to PlusCode if it parses.

Honestly, I'm a little diappointed how the missing ability to correctly share positions from Google is waved away here. Menion et al should be aware that this is an ability that is absolutely crucial for "normal" users. OSM is nice and well, but let's face it, GMaps will always be more up-to-date. Rarely anyone relies on OSM POIs alone, so we all search stuff in GMaps all the time and want to easily enter the points in Locus. This is not something to just say "hasn't been working for a while, so what?"...

Hi guys, sharing points from Google Maps does not work for years as I know. Somewhere in 2021 maybe even later, they changed the format and the information app receives can no longer be simply converted to any text or coordinates.

What about then at least adding support for PlusCode? That can be copied from Maps with one tap and surely be parsed by Locus search without ambiguity?!

Hi there, also my 2 cents to the new side panel:
First, like it! Wouldn't mind some more configuration (e.g. rarely using LoPoints, so would rather be able to hide those lines).

What I'm not quite happy with yet is the theme selector: When you change the theme, you still first have to go through the options screen everytime, even though now there's a dedicated button for that. When switching between themes, I rarely also need to change the current selection, so this is a superfluous step.
Also, the "layers" button may be technically correct, but I think most users will be confused and would rather call this "theme settings", so I propose to use a cogwheel icon.

I would like to add Management of Track Waypoints as No. 5.

Yes, please don't forget about this. There's a bunch of improvements needed here, many very basic (it's not even possible to multi-select and delete trackpoints!)

You will also need to improve search. It should work simultaneously in addresses and points.

I completely agree. Locus search is pure usability horror from last century. A proper search is ONE SINGLE TEXT FIELD that simply searches EVERYTHING at once and shows results as they come in.

Making me decide in advance on where I want to search is just wrong on every level imaginable.

Even worse is when I start typing, realize I got the wrong "place" to search in, change it, and the input field is cleared - why's that? Makes no sense and would be easy to fix...

We have of course some plans and things that need to be done, but still ... simple question (that may influence my personal preferences). What is the biggest pain/requirement you mostly have with the app, I should solve during the next cca 3-9 months? I have in mind a few main categories:

1) management of the track waypoints (not surprisingly my favorite
2) improve dashboard (missing items, simplify edit, improve charts, ...)
I would add
3) rotating labels in vector maps (or, rather, make labels non-rotating in relation to the (rotating) map. That's the main area where Locus just looks so much worse than other concurrent map apps - and of course it's not just looks when actually navigating...
4) better overlay handling, e.g. with overlay presets. For example, I have overlays with hike routes, skiing routes, public transportation stops, all are best at different alpha values, changing between them is such a pain that I usually don't use the feature, even though it's quite good in principle.

All locus notifications are active
Permissions for Locus are active except physical activity.
Out of my curiosity, what is "physical activity" in locus for?
Thank you

I think that's for the new (but beta) auto-pause detection.

Hi Menione. Backup files sent to the cloud are too big. The last one has over 0.5 GB. Most of the space is occupied by the track.db (800 MB) file. It is unnecessary to back up routes and points for the Gold version because they are stored in the Webplaner. Would it be too difficult to miss these files for Gold users from autonatic backups?

I strongly oppose leaving out the *.db by default. As an option, ok, but in my view, this is an absolute necessity - you can never rely on online storage service, I want to be able to restore my database even when e.g. Locus Web is down.

UI - I think SET/Recalculate position should be swapped. Typically, bottom right has OK (what you could say "Set" is, and it was there before). In my quick workflow I almost end up recalculating all when I just wanted to change routing profile.

My thought precisely. "Special operation" in the lower right is a recipe for disaster

Yes, it should be by its "Created time" parameter. And well, you know. Waypoints in the app are painful and need a new system for handling them. Old problem ...

I could start again about my hope to at some point being able to create waypoints in the track editor, so they have a datetime. It's one of my biggest annoyances that waypoints created during recording have a timestamp, but when I forget them and want to add them later on, they won't have a timestamp that fits to the track.
Not all waypoints are POIs, like "hut", but things like "put on snowshoes", "removed crampons", etc. For those things, times are of relevance, especially if you use the same trail several times.
Well, I'll keep hoping...

There is more options on how to improve Presets. I'm still playing in my mind with two
- remember state before applying preset and allow restoring the previous state (already used in the navigation!)
- change the whole concept that you will be always in one active! preset (profile) and will just switch between them

I don't think the second option is a great idea: If implemented like that, every change of a setting *must* also change the active preset. That's definitely not what I want: If e.g. I change the map theme, I still want the original preset theme when I next activate it.
Only solution to this, I think would be that every change puts you in "unsaved preset", which you then can save, or discard when activating another preset. That would actually be cool, but I image it being rather complicated to implement.
Currently, I'm very happy with the existing system.

I just noticed a change in the Track Editor (aka "Fine-Tuner"): When clicking on a point, the date/time is not shown anymore in the pop-up. Could you please bring that back, at least the time? I really think it's a big step back, I need the time all the time (no pun intended), e.g. to find out where the rest was in a track. Now I need several clicks for the details for every point! The time only takes 5 characters, so I don't really see any reason to get rid of it...

These no go areas are very important to force the route algorithm not to route through Italien villages. Very dangerous in the Alps.

Off topic, but why are Italian Alpine villages dangerous?

This will not change route length (still 84.4km) but
calculated time dropped to 1:47h. This should not happen bcs route doesn't changed.

Well, technically the time should be at least a few seconds longer, because a waypoint is supposedly a stopping point, so you have to break and afterwards speed up again.
Ok, joke aside, at least I can understand why the result of the underlying algorithm would not be exactly the same. Of course it makes no sense that it's shorter.
(and yeah, I'm working in the train business, where stop-or-no-stop is quite a factor...)