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

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
The following users thanked this post: Tapio
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.
The following users thanked this post: martin.fd
Quote from: sbouju on April 01, 2021, 23:42:56
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...
I had the same observation and question and Menion explained that this will come in a future release.
The following users thanked this post: sbouju
Quote from: janaton on March 25, 2021, 10:05:47
@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.
The following users thanked this post: Menion
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.
The following users thanked this post: freischneider
PS: do not forget Wolfgangs "allow use "location always" for locus,"
The following users thanked this post: balloni55
Quote from: john_percy on October 01, 2020, 09:35:18
...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.
The following users thanked this post: Menion
Quote from: Menion on October 01, 2020, 07:42:34
... 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
The following users thanked this post: balloni55
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ß) ?
The following users thanked this post: uliloc
Web portal & sync / Re: Locus Map - cloud/sync server
September 15, 2020, 07:19:07
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.

The following users thanked this post: Tapio
Web portal & sync / Re: Locus Map - cloud/sync server
September 14, 2020, 16:18:14
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

The following users thanked this post: janaton
Nach einer längeren Pause gibt es eine aktualisierte Version der Welt-Übersichtskarten (Einstellungen -> Karten -> Erweiterte Funktionen -> Lade Standardkarte):


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.
The following users thanked this post: Tapio
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.
The following users thanked this post: Andrew Heard
Hi slarti76,
you can find the LIDAR based DTMs at
I doubt Asamm would volunteer to host the 25MB/piece data ...
The following users thanked this post: slarti76
Great news: the latest LM4 test apk (#943) fixes the issue of "... no points ..." if you have more than about 60 POI DBs installed in total (installed, not visited, was the issue). Tested on my S10 - hope that persists on others ... Thank you, Menion !!

Tolle Neuigkeit: the neueste LM4-Test-APK (#943) hat das "... keine Punkte ..." gelöst für den fall von mehr als etwa 60 installierten POI DBs (installiert war das Problem, nicht besucht). Auf meinem S10 getestet - ich hoffe das gilt auch für andere ...
The following users thanked this post: Menion