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.

Messages - michaelbechtold

Pages: [1] 2 3 ... 44
The NMEA data is RAW data, coming from Android level, BEFORE interpretation by Locus.
I once had a phone that had a faulty GPS module (or wiring after a repair) and would deliver only 30% of the expected points, and also with huge delays.

Hi Thomas, would you mind sharing the Android MEMU download that is working fine for you ?
TXs and cheers

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

Locus Map (4+) / Re: Locus Map - cloud/sync server
« on: November 03, 2020, 23:59:29 »
Well, Menion, I know I had an older copy of the DB on that device which ended up with duplicates.
That did duplicate in my earlier testing phase and we discussed it. "Works as designed" in the end, right ?

Locus Map (4+) / Re: Locus Map 4, discussion
« on: November 02, 2020, 18:58:41 »
@Menion re. LG G5: there is a LM Pro on the device, too.
Once I could not install, I did two tests:
1) reboot - not helping
2) uninstall LM free/beta - not helping either.

Locus Map (4+) / Re: Locus Map - cloud/sync server
« on: November 02, 2020, 18:55:25 »
I have data duplication, too - the DB is now nearly 2 GB in size ...
But I can remedy, as this device is not used for active tracking :-)

Locus Map (4+) / Re: Locus Map 4, discussion
« on: November 01, 2020, 18:56:16 »
Hi all,
I could install sucessfully LM ...967 ... on several Android 10 devices (Samsung and Huawei), but it consistently (even after reboot) fails on a LG G5 (Android 9), although 3.8 free space are available.
Any similar experience and/or ideas?
TXs and cheers

Locus Map (4+) / Re: Locus Map - cloud/sync server
« on: October 31, 2020, 22:32:22 »
I did a quite systematic test with three devices  in summer and stumbled across the same issues.
Followed by a discussion wit Menion.
Bottom line: there needs to be ONE master for the initial SYNC, other need to be empty followers.
The reason why: the finger print is not by content, but by some meta data combination, incl. time stamps of the local device (or so).
I strongly proposed to go to a hash across contentand title (and ignore the usual suspects that may differ for thechnical reasons). Such would avoid any of those problems (after some deeper analysis and proper solution design).
But it is not the way they built it - until now ...

Locus Map (4+) / Re: Locus Map 4, discussion
« on: October 01, 2020, 11:22:58 »
...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.

Locus Map (4+) / Re: Locus Map 4, discussion
« on: October 01, 2020, 11:11:07 »
... 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

Troubles & Questions / Re: Data Transfer In Android Phone
« on: September 24, 2020, 10:20:48 »
A file manager app.

"FX" is good.

Last update a year ago or so.
I am using X-plore (from a CZ guy :-).

[DE] - deutschsprachiger Forumsbereich / Re: Problem mit
« on: September 18, 2020, 23:37:28 »
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Ɵ) ?

Locus Map (4+) / Re: Locus Map - cloud/sync server
« on: 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.

Locus Map (4+) / Re: Locus Map - cloud/sync server
« on: 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

Locus Map (4+) / Re: Locus Map - cloud/sync server
« on: September 13, 2020, 08:36:46 »
Well, what you describe is a copy/paste, not a sync.
I had the suspicion that on the older devices there were some tracks that I had not manually transferred to the latest device (S10) in the past (waiting for your sync feature :-)).
So they would NOT be a fresh install, but rather a full-sync for a good reason.

Is there a way to access the server for my account and have a list of what is there ? You know, I do not need fancy features for this kind of fundamental testing.

Pages: [1] 2 3 ... 44