Messages

Nach einem ausführlichen Beta-Test wurde gestern die neue Locus-4-Version in Google PlayStore veröffentlicht, die es erlaubt Locus auf /Android/media zu beheimaten.
Damit kannst Du mit TC, x-plore und anderen fähigen Dateimanagern noch zugreifen (wobei ich dies mit Android 14 noch nicht selbst testen konnte, aber mit Android 13, das ja weitere Restriktionen einführte selbst im Vergleich zum schon bescheuerten Android 11, was die vermeintliche "Sicherheit" betrifft).

Congrats to Menion and team, this is an incredibly heavy release!

The /Android/media option is really key to get the Android 11+, but in particular the Android 13+ mess under control, for people who cannot or do not want to employ the AFA version.
Adding this /Android/media feature for the SRTM folder is cool and essential to allow people to feed elevation data as they wish (like the Sonny 1" LIDAR data :-)

Cheers
Michael

PS: leaves the search challenges ... see current posts in other thread.

For Android there is still the option to have Google results via API, free of charge (as per Menion, last year's discussion).

But it is a decision by the Asammm search folks to not integrate that. It would be easy to merge those  results or keep this Google search as an additional option in your list, druki.

The earlier argument that Android and iOS should have same features is not valid anyways and a pretty bad excuse. Because the feature set for iOS will be smaller, for many years to come.

A solid search feature incl. Google search API is simply a question of will, not effort or anything else, I think.

Hi Menion, I get the point re. the distinction between those two functions.
However, when using Route Planner, I would expect that selecting a point on the map (in particular a visible POI, regardless if private or from LoMaps DB) would offer me this choice: Navigate or Planner.
In case of Planner, the selected point can be set as target by default. If it should be the starting point instead, it's a split second to reverse the order. In general the new Planner is really cool :-)
Did I miss a point or feature when trying yesterday (and today) ?
TXs and cheers
Michael

[@Tapio]

@Tapio
Choose location > under this menu is quite a lot of options, so I would rather stick with the united system across the app. Anyway, what is unexpected on the "Navigate to" call?

The search is unexpected. I already know where I want to navigate to and don't need the search. Most of the time when I use "Navigate to" I want to nav from gps pos to screen center.

Wouldn't it be more logical if it came up with the screen as attached?

The route planner should appear first. Then I choose whether I want to set the start or the destination. If I then go to Select destination, Tapio's screen should appear. From there I have all the options, including search.
If I go to navigate from a POI. Then the procedure should be the same. Only that the destination is already selected and I only have to set the start.

I started swearing yesterday when trying to route with the latest beta ... Your point is spot on, Tapio!

I triggered this feature years ago and have been happy ever since, although I have 1000s of tracks in the database. You see about 10 tracks in the result list, and they are properly ordered by increasing distance.
So, what's the problem, as the distance is indicated in red in the second results line.

Ich habe diese Funktion vor Jahren angestoßen und bin seitdem sehr zufrieden damit, obwohl ich Tausende von Tracks in der Datenbank habe. In der Ergebnisliste werden etwa 10 Titel angezeigt, und sie sind korrekt nach zunehmender Entfernung geordnet. Wo also ist das Problem, insbesondere da die Entfernung in rot in der zweiten Zeile angegeben wird.

Running always the latest AFA beta, I experience Cloud Sync going nuts since some time. Every few minutes it starts replicating, again and again and again, ...
Any idea, Menion?
TXs and cheers
Michael

PS: "deleting" is the most frequent message, but it has not emptied my databases to zero - yet.

Dafür ist BRouter (die Routing-Engine hinter LoRouter) schlicht nicht gebaut. Und Locus als solches auch nicht optimiert. Für KFZ über längere Strecken ist die aktuelle und (über die Fahrzeit) projektierte Verkehrslage essentiell. Wer soll/will denn für diese Daten zahlen??
Umgekehrt: lasse Google einmal eine Wanderung routen - Frust garantiert :-)

Wow, Locus root directory on Android/media!
That solves the Locus photo access, too, I suppose.

Seems so:
https://docs.locusmap.eu/doku.php?id=manual:advanced:customization:online_maps

The URL string has to have x/y (lon/lat) included. Are they in the right place (order)?

What you could try is this: use a tool like x-plore or TC which still can access /Android/data structures.
x-plore offers a ftp server (I cannot comment if TC can, too). Or you zip the whole stuff and have a single file to transfer.

Diese .db-Dateien sind sqlite-DBs; dafür gibt es Werkzeuge zum netten Anschauen. Ein Hex-Editor dafür grenzt an Masochimus :-))

Die POI-.db von OAM sind eine Umformatierung der Mapsforge-POIs. Das ist nötig, weil Locus jene nicht versteht, was OK ist, da Locus ja auch die Adressen mit hineinpackt, und vielleicht noch andere Sachen.

Arghhhh, meine Formulierung in Post #16 war etwas mehrdeutig. Mein Thema waren die Dateinamen und Umrisse der jeweiligen Karten, nicht deren Karten- oder POI-Inhalte für die abgedeckten Flächen!
D.h. es gibt nicht für jede OAM-Karte eine LoMap mit gleichem (Außen-) Zuschnitt; und umgekehrt. Für die meisten aber sehr wohl.

@Menion: WOW, THAT's a comprehensive lesson - TXs a lot!!
And those details explain why I have seen different behaviour of various apps over time.

For Locus I suppose and saw that not the complete /Android/data structure is transferred, because it can include huge volume (my tracks.db e.g. has 1.1GB), right?

So, let's see what Ahiker's situation really is, as the initial post did not include much of it.