Messages

2 lines consumes too much space again. If so, you should be able to hide them in the menu.
But you could make both buttons in one line. The name Tracks is very short.

Hello guys,
new Beta 4.17.1.3 just generated. I've found also one extra issue in consumption that may happen in the case, in the directory is really a lot of files. I've improved caching so it may help as well.

But I still do not know why with a single 1" you had so high power consumption Michael ...

Hello,
why I missed your previous post > do not know, sorry.

It is really weird because I'm aware of only two situations when track recording may be really paused "magically":

1) new, not yet perfectly working, mentioned "auto-pause" settings
2) app was killed by the system, and later started manually again (after more than 10 minutes after it was killed) and the app automatically pause the previous recording.


Otherwise, it may be paused over the widget, by intent (so over Tasker etc), in the UI (side panel or dashboard). Hmm and this is probably all ...

--

I've anyway just generated a new Beta version for tests so I've added some extra logs related to the start/stop of track recording. If you find a moment, you may try to install it, then long-click on the app main menu button and enable  Setup logging > Log to file.

Then try recording as usual and after the issue happens, so after you notice an accidentally paused track recording, just stop the app and send me a log file from the Locus/logs directory. Info, when (exact time) issue happened may be useful.

Michael, in the test directory, is a Beta version with
- logs
- a little optimized caching of HGT files

Give it a try. If consumption will be the same, please enable "Log to file" and create a small log for me, thanks!

or even... have the "Barcelona"(s) in the list BUT only change the zoom if & when that item in the list is tapped?

The app zooms out only to be visible nearest result together with your previous location on map, so even if you have Barcelona in the list the app will not zoom out to it in case there are closer results. So if you get big unexpected zoom outs when fire up text search, we most likely wasn't able to find what you wanted.

If the search is done from the center of the map or from the GPS position, it is from that point that I would like the distance to be measured.

Search is always "done" from the center of the map. But I agree, it might be confusing when you search when locked on your GPS position and map will automatically move to show you nearest result, thus these distance markers not longer relates to GPS position. Will think about it!

What I do not understand: before the new search system, Locus DID use Google APIs, right?

Ok, I admit that I ignored previous "Google driven" search in my replies more that it is fair, sorry for that. Menion wrote few reasons why we don't want to use it for the future, but the list is even longer including its unreability. But the last thing we want to be your search experience worse than before, so thanks a lot for your feedbacks again. We for sure have some ideas already how to adress some mentioned topics or at least make the issues less of the problem, so keep your fingers crossed!

Android version should make no difference. Anyway, the app currently loads HGT files into memory and then computes elevation from these in-memory files. I have a suspicion, that aggressive memory management force app to discard these loaded files and app then has to re-load them again ... and again. So I've added some logs into the app to see, how often app re-loads these files from disk. The beta will be published, hmm hopefully tomorrow ...

[EDIT]

Thanks for the log Michael. Unfortunately, I see nothing useful inside ...

Will have to try on another device next few days because on my main Pixel5, no problem as I wrote before. Still, no idea why this should happen ...

Btw. you are using 1" files from Sonny from here right https://sonny.4lima.de > Germany DTM 1" ?

EDIT: I've added some more log messages into the app, so in the next Beta version, "Log to file" may produce some more info. I have one idea what may cause it so want to try.

GM share - we just probably forgot to test it. 
Zoom level affecting the composition of results, or maybe even search engines low level - this can be quite easily done (simple version) and I agree it is a next logical step.
Which bar is important and which is not: in the world of AI, some improvement over what we have now is IMHO quite possible, but very labourious and from the "data work" point of view also very hard.
Clusters of pois displaying numbers - server side this should be easy, front - end boys will hopefuly cope :-)

I don't think Barcelona for "Bar" is that irrelevant.

@Radim - maybe the search should consider the current zoom level? Barcelona may be relevant if close by, but not when 2000km, and the map is zoomed out to display, non-existent map/ no offline map even exists. This zoom-out to 2000km happens on most searches which is bad.

Did you check why a share from Google Maps doesn't work? This workaround would help alot.

That happens with certain themes.  When I see that, I try another.

Have you tried the Elevate theme that comes with OAM?  It's well matched to the underlying map.

EDIT: on quick investigation, I'm guessing you're using one of the Locus internal themes with OAM.  The internal themes match well with LoMaps, but not so well (IMHO) with OAM.

Elevate, or any of the other V4/V5 themes (a bit hard to find), should look much better.

Man kann übrigens die beiden tracks*-Dateien aus /storage/emulated/0/Android/data/menion.android.locus/files/Locus/data/database/
rausnehmen, Locus legt dann beim Start eine neue, leere Trackdatenbank an.

Wenn es also dann durchgestartet ist, kann man wieder Backups einspielen, Importe machen etc.

Like @karlchick I don't want to render all areas as semi transparent. I believe OAM removes layer=-1 from tunnels in preprocessing and allows tunnels to be rendered by the theme with skillful use of transparency and position in the theme. I prefer this and I think it gives a better result overall.
The reason @karlchick can't get cycle route blobs to behave as wanted in tunnels (or on bridges) is because Lomaps treats all hiking, cycling and MTB routes as separate ways which don't inherit the tag values of the highways they follow. So the road has a tunnel tag but the cycle route does not.
Edit: @karlchick You'll also find that your cycle blobs are missing from the bridge (adjacent to the tunnel) in the Lomaps version. They have been drawn on layer 0, underneath the bridge layer, as the cycle route doesn't inherit the layer tag either.

Sent from my moto g(6) plus using Tapatalk

[Locus Map (4)]

New Locus Map (4) version

Important links
- list of news of public versions
- Public versions
- Beta versions

Versions
25. 4. 2023 - Locus 4.16.0

@michaelbechtold There are already Czech R. and Slovakia LoMaps available as V4 in the Locus store (version 2023.03.23). The rest will be released probably during the next week.

@john_percy
bridge=viaduct - added

[Beta version 4.15.2.4]

So the new Beta version 4.15.2.4 was published.

I was quite sure, that it will already contain a new search system, but we are trying to make it perfect even for the Beta version, so a few more days are necessary. At least an improved Backup manager as @freischneider already noticed and few more tweaks.

@Tapio
are there any exact steps that cause this issue? Even on your side?