Messages

Auch Europa hat Christian bis auf wenige Staaten schon neu gerendert.

Hi Mips,
ich kann nicht für Christian sprechen, aber ich kann berichten, dass Christian aus dem Urlaub zurück ist und an einem Preprocessing arbeitet, das die Verwüstungen (*) in Nordics kompensieren soll. Erste Erfolge hat er bereits.
Haben wir also noch ein wenig Geduld.
Gruß
Michael

(*) die sind akademisch nicht einmal falsch, aber für die Nutzung der OSM-Daten ein Problem.

Hi Tapio. Would it be possible to create a Quick install like Andrew at Voluntary? When I give the Tapiola.zip to the Android/Media folder ... Mapsvector/_Themes, my locus doesn't see him.

Tapio's zip alone works like a charm.
Download, click (in a file manager), select Locus as handler, wait some seconds until Locus has created its internal extract, enjoy!

AllTrails Web Site does a good thing: put the top level name in all the places where a segment name was.
But that would be tedious.
You can do a similar thing yourself using Notepad++ e.g. on a PC to do a "substitute all" for each file.
Maybe there is a program for PC that does that, too.

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!

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

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

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.