Messages

Do you have them in the original folder structure ?
Then it is pretty easy: just locate where your current Locus install resides - most prob. in private /Android/data on internal storage - and copy the data there.
Connected to a PC this should be straight, on the mobile itself you need Apps like x-plore or TC to get to those private data folders.
If the data is REALLY old, the database structure might not fit.
If you have the old data PLUS you collected new data already on your Pixel 7, then things get more manual and nasty.

Well, we know the HOW (dealing with the file once a second, over and over again, without ever caching it), but we do not understand the WHY. With this function call every second gone, it is no longer an issue - luckily :-)

Each post from Menion includes all relevant links at its bottom.
For your convenience here is the one you need:
http://bit.ly/lmVersionsTest
I'm using the AFA version, too, BTW.
Cheers
Michael

Another 1%/h battery saving (down to 5%/h while recording track, with a 1" hgt for  the region of the track, on a Galaxy S10), now that the hgt evaluation once per second is avoided.
TXs a lot, Menion!

Another 1%/h battery saving (down to 5%/h while recording track, with a 1" hgt for  the region of the track, on a Galaxy S10), now that the hgt evaluation once per second is avoided.
TXs a lot, Menion!

Ich orientiere mich an den Track-Titeln (Name), für Suche und Sortierung.
Und der Name ist in der UI von Locus änderbar.
"Created" ist der Zeitpunkt der Aufnahme (nicht des Imports - habe es gerade noch einmal probiert), und die sollte ja geräteunabhängig sein (da vom gleichen Geo-Service gefüttert).
Oder übersehe ich hier etwas?

Yes, t-mo, I'm talking about an INCLUSIVE AND.
Yet, not behind the scenes, as this would violate the new Locus search architecture (or at least would complicate things), and on iOS this even might be impossible (I cannot judge here).
This is the reason I propose to follow the path Radim and Menion et.al have described and are going. BUT leave the Google API based search as a separate feature (with its own name), on Android.
As I pointed out earlier, OSM is not anywhere near a reliable or complete model of the world, even for hike/bike aspects, in particular for countries outside CZ/SK/AT/D scope.
BTW: even Bikers appreciate a laundromat from time to time :-)
Again, this is NOT playing one against the other, but COMBINING the strengths of both data sets in a minimal effort way.
Cheers
Michael
PS: there is a difference between Google Maps mobile data hunger and a (Google) API call size in bytes - orders of magnitude. Proven just today, in the middle of Germany.

Using online search a little bit and thinking about it a bit more, this is my summary:
- Google data repository is unmatched, beating Locus and any other searches hands down, whatever they try, for years to come
- Locus, for strategic reasons, also with iOS support in mind needs this independent online search
- on Android the Google API search is at no cost to Asamm, as Menion stated
- combining both searches technically seems not feasible, as per Menion's response
- to me, the obvious approach is
-- to have a Locus Search for Android and iOS alike
-- put a Google Search as separate function into the Android version

That would stop any need for tough comparisons and discussions, a d empower users to make their own choice, based on their needs.
Giving USERS a choice may not be a technician's first emotional approach, but is beneficial for all parties in the end.

And above approach would not add complexity to the UI a d user experience.

Hope is the last thing to die ;-)

Cheers
Michael

That approach is worth trying, thank you.

Map shading while recording or following a route - that seems avoidable luxury to me, to be honest, hence nothing really lost.

Map shading I consider a planning help - and for documentation; i.e. time limited exercises.

I'll report the measurements ASAP.

Hmmmm, in the log I just checked what happens when I left the scope of the amok HGT file: locus continued to use this old file, although Locus - and I - were already outside its scope.
So, what is the use of providing a wrong location object via API? Also: why at all use DTM files for that if you have current GPS position for free?
And Locus runs just fine if there is NO HGT file for the region you are in.
Hence just pretend there was no HGT file(s) at all while recording, and Locus will safe battery for everybody. Always.
Cheers
Michael

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!

TXs Menion.
It is still twice the darin compare to no file or small file.

As I had the logging still active from the past, I will send you the log in PM.
Looking into it I found 1000s of dealings with the HGT file of the current region, as long as recording is running. Although recording uses GPS only (the DTM option is off).

Can you pls. advise?

TXs and cheers
Michael

I think you are right, @Menion.
For yet another test I have put the 1sec 25 MB hgt in place in the SRTM folder again and let Locus run: typical massive battery burn.
Then I simply DELETED this hgt file (the activity spike in the middle of the graph, also did a bit of other stuff), and afterwards the battery drain went half the rate!!
To me that means that Locus indeed is reading this file over and over again.
But it also means that it would do that with the smaller file (3"). As it is 1/8th of the size, the drain effect is smaller. Yet, Locus could save battery even with 3" hgt files.
Good luck killing this beast ...

OK, understand your priorities, Menion.

Then at least the GM share with their plus codes needs to fly seamlessly (not "tap nearby, then ...")
And I have no idea how you will resolve the restricted data set problem.
The nicest and most consistent solution is in trouble, if you cannot trust the results (in the sense "why is so much missing ...").
Good luck for you and team!

Thank you Menion.
And yes, I'm using Sonny's 1sec.

What maybe of note: this S10 is on Android 12, while the Tab S6 lite is on Android 13, but does not suffer.

Very good background information, Menion, TXs a lot!

Yet, while on your server you must not use Google API, it would be not too hard to merge the local Android Google Search results with those from your server. Data feeds and presentation are two different architecture layers. And merging two feeds is no rocket science.
Once Locus server search is as comprehensive as Google Android API, the latter can be dropped. However, this may take years rather than months, I fear.
Do not get me wrong - I understand your strategy, and if you never start something new, you would never get there. But for the time being I strongly advise to combine the strenghts of both approaches rather than leaving the users with mediocre results (to be friendly) for unknown time.

Just my 2c.
Michael