Messages

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

@Jan: appreciate you see the looooong way ahead :-)))

What I do not understand: before the new search system, Locus DID use Google APIs, right? Not exactly maybe as GM itself does, but good enough to leverage the huge dataset Google has.
I do not see any reason that would stop you to feed such a Google API result set as an ADD-ON to your datasets.
Once your and Google datasets are comparable in size, you can drop that API call :-)
OSM alone is definitely not the way to go. When you do some maths like number of OSM objects/country size or /population, you will see that CZ, Germany and very few others stand out. The rest is not exactly desert, but way below practical or reliable.

Also, pls. mind what Tapio wrote below. The Google + location format is a must indeed.
And pls put priority to those fixes rather than taking users hostage.

TXs for your understanding.
Cheers
Michael

TXs Menion.

I just sent you a link to the huge ZIP on GD.

Doing a brute force search through the debug data, I found the 6 hgts you mention. Beyond that I am not used to that kind of internals - you are :-)
None of those 6 is the N50E008 where the tracking happens.
On the other hand this local hgt SHOULD not be touched anyway ...
This is from an S10, Android 12.
And the effect is reproducible at will: whenever the 25MB-version of N50E008 is in the Locus srtm folder, the battery drain goes up 2-4 fold, compared to no file N50E008 or the small version.

Good luck and kind regards
Michael


FS/data/tombstones/tombstone_20:    fd 107: /storage/6561-3431/srtm/N47E005.hgt (owned by RandomAccessFile 0xf7e876a)
FS/data/tombstones/tombstone_20:    fd 109: /storage/6561-3431/srtm/N46E005.hgt (owned by RandomAccessFile 0x863ca2f)
FS/data/tombstones/tombstone_20:    fd 119: /storage/6561-3431/srtm/N47E006.hgt (owned by RandomAccessFile 0x14b64f8)
FS/data/tombstones/tombstone_20:    fd 150: /storage/6561-3431/srtm/N46E006.hgt (owned by RandomAccessFile 0xb75b036)
FS/data/tombstones/tombstone_20:    fd 167: /storage/6561-3431/srtm/N45E005.hgt (owned by RandomAccessFile 0x248bd41)
grep: FS/data/tombstones/tombstone_20.pb: binary file matches
FS/data/tombstones/tombstone_28:    fd 120: /storage/6561-3431/srtm/N53E006.hgt (owned by RandomAccessFile 0xc2c58e3)
grep: FS/data/tombstones/tombstone_28.pb: binary file matches

PS: it can easily be that Locus touches the "local" hgt in any case, 1 or 3 alike, but the battery cost would be multiple in case of 1sec, depending on what it is doing.
Also shading and dynamic elevation are OFF, of course

Thank you Menion.
Just checked: Use offset: NO, SRTM data: don't use, Medium filter (for GPS I suppose)

Can confirm - really bad.

@Menion: after a dozen tests or so, narrowing down the effect, this is the outcome:
- tracking with screen off, record only when moving, device always in the same place, hence only the normal GPS "noise" movements
- if the hgt file of the area is a 3sec file, the battery burn is 4%/h
- if the hgt file of the area is a single 1sec file, the battery burn is 12%/h
- if the srtm folder is full of 1sec files, the burn jumps to 20%/h
- this is regardless of INT or EXT SD

That strongly points to Locus doing (useless?) hgt file operations which tracking. At least I cannot explain why Locus should look at hgt files while it records a track.

Can you pls. check and advise?
TXs and cheers
Michael

I ran a number of tests today and this is the pattern:
- the pure existence of an empty SRTM folder on EXT SD does not harm
- putting the hgt of the track area into the SRTM folder increased the burn from 4% to 6%/h
- moving this stuff to INT SD does not help
- putting 100 1sec hgts into the INT SRTM folder blew up the burn to 12%/h

S10, Android 12.

Question to @Menion: why would Locus deal with ANY hgt file while recording??

Die neue Version der Suche nutzt leider intern nicht mehr Google Maps API.
Habe deren Such-Entwicklings-Team gerade eine Nachricht geschrieben.

Ein Downgrade ist riskant, wenn man nicht technisch gut drauf ist (von Google Drive alte Version laden, alle Daten sichern (!!!), 4.17 de-installieren, alte version (4.15 sollte tun, vielleicht auch 4.16) aufspielen, Daten restaurieren.
Euer aktueller Ort ist nicht gerade der, wo man so etwas zum ersten Mal probieren sollte ...

@search team: https://forum.locusmap.eu/index.php?topic=8460.msg71808;topicseen#msg71808

People are relying on Locus when traveling - DO NOT LET THEM DOWN!

There is not even a way to search in Google Maps and share into Locus (I tried multiple ways, also Plus Code)

- Locus (o.Ä.) ohne genauen Standort macht ohnehin wenig Sinn ...
- wichtig ist auch: IMMER zulassen (d.h. auch im Hintergrund, nicht nur "bei Nutzung"
- Locus vom Energiesparen ausnehmen (die Einstellung dazu tickt jede Marke etwas anders)
- Locus als "Service"

More food for thoughts, Menion:
Moving the SRTM folder one level down does not help on S10 (Android 12, while Tab is Android 13)

@Menion: now the brain twister for you:
- S10 with erroneous SRTM path is back to 4%/h
- Tab S6l with a working 30,000 hgt SRTM folder takes 1%/h
- difference is: the S10 SRTM is directly at EXT SD top level, which the Tab SRTM is in a LocusEXT sub-folder.

Any idea why that is?

@Menion: once I had the 4 directories adapted to the S10, I ran another test.
And it went back to disaster: 20%/h

Then I renamed the huge srtm folder on EXT SD without adapting in Locus and started yet another test.
It seems we are back to 4%/h

The config differences between original S10 and original Tab are tedious to walk through.
The differences between original Tab (4%/h on S10) and adapated config (20%/h) are in the areas you can expect: screen positions and some paths.

I'm now testing the S10 without access to the srtms and the Tab with access to ist srtms - stay tuned ...