Messages

@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

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

@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

@Menion: I rushed to see the results from taking the Tab S6l config, so I did not care about wrong paths (EXT SD IDs of course differ). After the that test I started to correct the 4 of them:
1) backup - no problem while processing, neither after restart
2) maps - on the Tab (small INT SD), this is on EXT SD; on S10 it used to be in the main Locus folder (INT SD/Locus). Processing: a list of maps, well known to me, runs across the screen; after restart, maps is EMPTY !! (Real losses, as I did not expect such and did not backup those upfront)
There is definitely a logic error. Locus must NEVER delete anything from the target folder; IN PARTICULAR if the source is non-existent!
3) mapsVector - same amok. That one did not hurt, because it were LM3 maps, supposed to be updated anyway
4) srtm - OK, like #1
So I have been busy for a while ...

Config difference analysis to come later.

It's a long was to ...

I definitely agree a properly working share fron Google Maps is a must, if the use if the API Service from GM is discarded.

Re. overcrowding and zooming: Locus will hardly have a proper priority of items to show anytime soon. It cannot, I think, hence no criticism.

But Locus already has a smart system to deal with overcrowding (I recently taught it to Inge, whom I brought to Locus some time ago): it's the grouping. As long as there are numbers, pan and zoom.
Just my 2c.

Navigation shows a failure: the distance to next turn freezes at its initial value, while the voice announcements adapt to the nearing turn.
You can re-calculate, and the story just repeats.
Running latest Beta

@Radim & Jan: did I miss a statement re. my proposal to include Google API search again?

Even the combined power of OSM, Wikipedia and Locus Communities will be able to provide comprehensive results, not in decades. Which is not a criticism of the communities approach, which is the only way once you are offline, e.g.. It's about amending above sources with the power of Google Maps - as an option.
And if this should be a financial burden, you can restrict that option to silver or even gold only.

Or is Google search active under the hood already? (I think not, because some searches failed that would deliver in earlier versions.)

Can you pls. advise?

TXs and cheers
Michael

The search we Locus had so far allowed to select the search engine. There should be no step back from that.
In fact, there should be what the Locus search team built so far PLUS the search engine selection (only active when internet connection exists).
Such combines the strengths of the existing with the new functionality.

Tried online search, with disappointing experience, when it comes to results.
Reason: the Locus object repository is way too weak.
Do we have to use Google Maps first, then transfer the results to Locus?
Or did I miss a magic configuration option?

x-plore, dem man alle Rechte auf Nachfrage gegeben hat (leider jetzt pro Unterverzeichnis von /Android/data), kann auch unter Android 13 Operationen im INTERNEN Speicher ausführen.
Gestern habe ich allerdings gelernt, dass seit Android 13 der Zugriff auf /Android/data auf EXT SD gar nicht mehr funktioniert.
Immerhin ist /Android/media noch zugreifbar.

Wahrscheinlich hat Google zu viele Schwachköpfe von Apple abgeworben ...

Die Tracks kommen NICHT aus dem Dateisystem, sondern aus tracks.db im Locus-Ordnersystem.
Ich würde ein Backup von vor der Operation einspielen und dann noch einmal importieren, aber ohne Sichtbarkeit.

When will V4 be generally available, i.e. in app LoMaps downloads deliver V4 maps rather than the old V3?

See my response in the German thread.
If you had an old LM3 Pro install, maybe with Locus root folder directly on top of the SD card, then a new install of LM4 will not find that, except you have an AFA side load.

Der beste Weg ist die Themes als ZIPs z.B. im Download-Folder zu sammeln, dann ein ZIP öffnen und Locus als Handler auswählen.
OAM hat ein Locus-Action-Script, da geht es direkt.

Fully agree, Andrew.
For the Web Planner, the cost impact is minimal (not so for the 1" downloads, though), so there is no justification to not use it.
"Consistently" (Web Planner versus App) being "wrong" is not a good idea, I think.