Messages

OAM hat Spitzenkarten, die ich auch seit Jahren nutze.
Und in extra Verzeichnissen ablege, je nach Gerät auch auf externe SD-Karte.
Diese Kartenquellen (Andoid-Folder)können im Locus-Kartenmanager explizit hinzugefügt werden.
Auch mehrere verschiedene.
Über den Store bekommst Du LoMpas (die durch die offline-Adress-Suche Vorteile haben - POIs sind auch bei OAM dabei).

Nimm Nord und Süd, die reichen.
In Locus gibt es einen Modus Karten automatisch zu wechseln.
Hat manchmal Nebenwirkungen, geht aber grundsätzlich.

Hi Locus team,
I think I read a reply from Locus team some time ago that Sonny's LIDAR data would be used for downloads into the local app data storage (folder srtm). From a discussion and test (based on 3.5.1) yesterday I concluded I should test with LM4, too. And I found that the 3" SRTM data is used (2.5 MB file) rather than Sonny's fine grane LIDAR data (1").
Can you pls. clarify?
TXs and cheers
Michael

Es gibt eine MASSIVEN Geschwindigkeitsunterschied zwischen interner (schnell) und externe (langsam) SD.
Ob es in Android 11 (oder gar schon 10) einen Unterschied zwischen /Android/data und /Locus gibt weiß ich (noch) nicht.

Looking at my LocusMap web (sync being done) and going in "PLANNER"/"MY LIBRARY", I can find all my tracks OK, but I have no access to my waypoints...
Normal?

I had the same observation and question and Menion explained that this will come in a future release.

[@michaelbechtold]

@michaelbechtold Thank you for your feedback. I am already looking into your synced data that I have on the server. I can see a lot of points uploaded but no tracks so I am just guessing that synchronization process did not start sending tracks, yet. That is the reason why you can not see any tracks in the web planner.

Regarding battery drain - yes, there is constant http communication and also a lot of operation to the local LM database so I would not be surprised by more power consumption ... but I am not Android developer so rather wait for @menion for his opinion. It is fore sure possible something not optimal is happening there ...   

Hi Janaton and Menion,
as it seems the amok already starts with the waypoint DB (6 MB originally), and sync did not reach the track DB work before it broke in the morning.

As the numbers are massive, I am well aware that transferring would take time and energy. I observed and mentioned the drain, but not as a complaint.

Good luck with the data that I uploaded as per Menions PM.
Cheers
Michael

I fully agree re. the value you get for the silver and gold subscriptions. And hey, it's less than a beer or a prosecco!
But I also agree with the family aspect our Aussi friend has laid out. This should get fixed.
Just my 2c.
Cheers
Michael

PS: do not forget Wolfgangs "allow use "location always" for locus,"

...On the map itself, this doesn't matter s the information is all visual but once it becomes textual it is potentially confusing. I don't see a way of resolving this however.

Hello John,
what you highlight is just another example of missing governance in OSM. A system that works internationally, needs to have internationally uniq rules for the same thing. There can be tons of diversity, as occurence of details differs a lot between parts of the world. But the same thing needs to be categorized the same way all over the planet. Otherwise you'll end up
- either with nightmares for all developers who want to serve the customers by adding piles of exceptions
- or users have to live with the frustrations and exercise such "mapping" in their own minds. And hopefully turn to OSM to shout.
In my work for the world overview maps I suffered quite a bit. Most crazy example was a peak of 28000 (well - meters in OSM), beating Mt.Everest hands down. Now - some bloke added the evelation in feet. If he'd only put "ft" or alike behind the figure ...) Until now I ended up checking the OSM elevation against SRTM elevation and checked the most relevant cases from the candidates that show a factor of 2.5 to 3.5. Did more than 1000 fixes in OSM so far (then became a bit tired ...).
In the end only a lot of people have to speak up and influence the OSM community to behave more consistently.
Just my 2c.
Cheers
Michael

[@Frivold]

@Frivold
... If there will be more people interested in the old behavior, I may create an expert setting for this behavior.

Hi Menion,
expert setting for LM4 is the perfect way. With the search capability in settings, there is no added complexity. And an additional expert setting take more like minutes than hours of work, right ?
Pls. count me as "interested", too :-)
TXs and cheers
Michael

Da fehlen eine Reihe von Informationen zur Situation:
- wie sind die Einstellungen zur Karten-Wahl (offline, Vektor) ?
- hast Du die Karte an Locus durch die Kartenverwaltung bekanntgemacht ?
- welche Europa-Karte siehst Du ? Online ? Oder eine Offline-Raster-Karte (denn Europa-Vektorkarten sind mir nicht bekannt - viel zu groß) ?

TXs for your nightly response, Janaton.
Let me go through the points one by one:
1) Main concern -  we could accidentally mess up versions and expose something obsolete
Much more serious is a sloppy delete - from user side as well as on your side. A code that deletes ONLY if there is a specific flag set in a DB row if very straight forward and can be verified. A "free" delete as today is more risky in any regard. Risk x (# users ...)

2) Additional complexity - clean up made asynchronously (implement task manager, cleanup logic located away from sync code)
Yes, there is some more complexity. But one more daemon running on the server does not make a huge difference. And again, cleanup logic is very simple.

3) Increased storage requirements that you need to handle history
If you want to stay in control of this, then drop my idea to have users trigger the cleanup (and yes, users may forget forever ...), but rather establish a rule like "Restore up to one week from deletion". This limits the additional storage, and lets you stay in control. A restore (triggered by a user) is a simple removal of the deleted flag, followed by a sync.

4) We agreed that we don't want to offer versioning functionality to user thus keeping history would be more or less for support and emergency situations (something would go terribly wrong).
I do NOT propose any versioning, but only a limited safeguard against accidental deletions. Big difference!

Regards to the whole team.
Michael

TXs Janaton, for your explanation. As I am in Comp.Science since 40 years, I exactly understand your message.
Yet, what I propose is a UUID based on a hash of the whole record (all point or track data, no device specifics inluded!). As we are not fighting off NSA here, it can be a "cheap" one.
Then all those special cases are gone, right ?
If the hash is identical across devices, your existing algorithm will automatically do the right thing - ignore. If not, sync.
And I still do not understand what is complex about careful handling of deletions (flagging, detailed sync history, user triggered cleanup).
TXs and cheers
Michael

Nach einer längeren Pause gibt es eine aktualisierte Version der Welt-Übersichtskarten (Einstellungen -> Karten -> Erweiterte Funktionen -> Lade Standardkarte):

Versionsinformationen:

Mit dem Schmelzen in der Ant-/Arktis werden die dortigen Forschungsstation immer relevanter. Die Liste für die Antarktis wurde auf den Stand der aktuellen Wikipedia gebracht. Und erstmals werden die Stationen der Arktis gezeigt.

In diesem Zuge wurden die Abdeckung für ZL 7 bis 10 erweitert - <a href="#Legende"><b>siehe dort</b></a>. Der Preisverfall von Speicherkarten ist jedenfalls viel massiver als das Wachstum der Dateigrößen :-)

Weiterhin sind die Siedlungen, Fähren und Kraftwerke jetzt auf dem Stand vom 5.7.2020 (leider erst mit dieser Ausgabe 1.1)

Auf dieser Datenbasis wurden auch hunderte von Provinz-Hauptstädten hinzugefügt.

Erstmals wird eine Karte mit PNG-Tiles angeboten; d.h. alle Ebenen die am Ende zusammengefügt werden sind im verlustfreien PNG-Format erzeugt. Die Qualität hat ihren Preis: knapp 6 GB für ZL 1 bis 10. Sinn macht dies (nur) für Exporte bzw. Screenshots mit höchstauflösenden Smartphones. (Die PNG-Ausgabe 1.1 ist erst ab 28.8. verfügbar)

Alle anderen Weltkarten bis ZL 10 haben in den höchsten ZLs eine Komprimierung mit JPEG-Qualität 70, die regionalen Karten mit ZL 11+ sind in JPEG-Qualität 60 kodiert.

https://www.openandromaps.org/en/downloads/general-maps
https://www.openandromaps.org/downloads/ubersichts-karten

After some break there is an update available for the world overview maps (Settings -> Maps -> Advanced features -> Pre-load global map):

Release notes:

The melting in the Ant-/Arctic makes the research there ever more important. Their list is updated according to current Wikipedia information, now with the Arctic stations, too.

In doing so, I extended the map coverage for ZL 7 to 10 - <a href="#Legend"><b>see here</b></a>. The collapse of memory card prices more than compensates for the increase in map sizes :-)

Settlements, Ferries and Power Plants are based on the 5th of July 2020 OSM database information.

From this data base, hundreds of province capitals have also been added.

For the first time a world map in PNG format is offered; i.e. all information of all zoom levels is rendered in loss free PNG format. That quality comes at a price: nearly 6 GB for ZL 1 to 10. That makes sense (only) for exports or screenshots from high res. devices. (Release 1.1 of PNG only available from Aug. 28th..)

All other world maps up to ZL 10 are compressed to JPEG quality 70 for their highest zoom levels. The regional maps with ZL 11+ are coded with JPEG quality 60.

https://www.openandromaps.org/en/downloads/general-maps
https://www.openandromaps.org/downloads/ubersichts-karten