Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - michaelbechtold

Quote from: freischneider on March 11, 2024, 18:59:05
Quote from: Tapio on March 11, 2024, 13:27:31
Quote from: Menion on March 11, 2024, 09:25:15@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

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 :-)
Locus Map / Re: [APP] - version 4.21.+ ( 1/2024 )
February 17, 2024, 07:46:25
Wow, Locus root directory on Android/media!
That solves the Locus photo access, too, I suppose.
Maps / Re: Problem with online map source
February 03, 2024, 13:49:45
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.

PS: in general, Google transfer is limited to the app install itself, and private app data for some apps only, as far as I experienced.
If there is a recovery possible or not totally depends on the backup strategy you employed over the years:
- if you had set up the Locus backup to Google Drive, you are fine
- if you had the backup to another folder on the old Pixel and copied manually (does not sound like that, though), you'd be fine as well
- if you have LM 4 Gold with tracks and points replicated into the Locus remote storage, you'd be fine, too (but would have noticed on the new device, I suppose, as Locus should download the stuff)
- if you have another third party cloud feed for tracks (and maybe points), there is a way at least.
The POI and the track databases reside in /Android/data/ folder.
If you should have zip backup files from Locus, you can re-import them from Locus.
If you have only gpx or kml files from somewhere, you can import them into Locus and re-populate its database.
Other than above, I fear your tracks would be history.

Any more thoughts from a Locus export colleague?
PS: FALLS das noch funktioniert, kannst Du die LoMap map-Datei entsorgen bei Platzmangel und trotzdem die Adress-Suche genießen.
Die Adresssen und POIs im LoMaps .db-File sind per Namenskonvention mit ihrer Karte verbunden. D.h. sie müssen den gleichen Namens-Präfix haben. So wie bei den OAM .map s und .db s auch.
Vor Jahren habe ich das einmal probiert: das Locus .db-File passend zu der OAM-Karte umbenannt.
Das funktioniert wegen unterschiedlichen Karten-Zuschnitten nicht generell, aber in weiten Teilen.
Wäre einen Test wert mit aktuellen Karten, Steffen?