Locus Map - cloud/sync server

[Menion]

@balloni55
ah so @janaton was correct when told me that there may be a problem with the icon of the group. Thanks for the video, I've added this to my tasks for the next days. Seems it works correctly for points, but not for groups with custom (but not available) icons.

Behavior with attachments is currently correct. They are not currently synchronized, anyway, it is a task with will work on, during the next months as well.

[michaelbechtold]

@balloni55
...
I've just uploaded new version "MapGooglePlay_3.48.0.6_964_beta", so give it a try. I believe it will works correctly now.
...

Hi Menion,
looking at Google Drive I only see the 960 version from late August. How to get to the 964, pls ?
TXs and cheers
Michael

[Menion]

Check link in the first post. I work on sync and routing separately, so every topic has its own versions. Once, sync will be considered as "final", I'll merge them.

Sent from my Pixel 2 using Tapatalk

[Andrew Heard]

Just a very low priority thought, and I'm sure there is help topic elsewhere... With public sharing of tracks it becomes even more useful to implement a feature where the start or end of a recorded track can be optionally deleted so that the home address can be obfuscated/ hidden. Of course this is already possible via the track editor, but is too tedious for most users just to hide their home address.

[Tapio]

I wouldn't call it "backup" btw. - It syncs deletions to server. With the term backup, people would eg. expect to get accidentally deleted tracks back - which is not possible.

[michaelbechtold]

Hi Menion and Janaton,
I am reading about conflict resolutions, even deletions and in particular the latter rings alarm bells.
To save users and Asamm from trouble (and believe me, when that goes out into the wild, life WILL become wild ...) Istrongly propose at least two things:
- any sync run shall create a separate, human readable log file which includes all points and track actions in a meaningful description
- any overwrite should not be a physical overwrite in the DB, but rather creating a new point/track and makr the earlier one "invisible"
- same for deletions
- then add a cleanup function that physically removes those flagged entries
- and if you want to be really nice, also offer to restore (with "restored-DATE") inserted into the object name
If you think this may puzzle users, you can offer such as "safe mode" :-)
Just my 2c
Cheers
Michael

[Menion]

@Andrew Heard
good point, we probably forget on this important point. I've added this to list of things to discuss on our next meeting, thanks.

@tapio
correct, backup is little bit "missleading"

@michaelbechtold
hmm quite a complex change. I believe that such backups won't be necessary on the server-side. Ondřej (@janaton) already tried to do something similar, but in the end we declined this concept. I'll add this as a note to our discussion as well, thanks for the tip!

[michaelbechtold]

Hi Menion,
I am not talking about server side. Today you notify about the last update. Locally on the device.
That could be a history of more than one.
When ypou tap the "?" you get some stats today. Very technical. That should be a drill down for each category: addition, deletion, change. All locally on the device, as you must have this information there anyway. Hence no complexity.
The flagging etc. I propose below is also LOCAL, not on the server side.
Resilience ...
Cheers
Michael

[michaelbechtold]

Now some test results:
- tracks DB is nearly 1 GB in size
- waypoints has about 35,000 entries (6 MB)
- this is the sequence of events
- S10 has the latest DB, sync, runs through
- Note 3: started sync around 16:30 - still not finished, now at 8% of the points
- LG G5: it had an older version of the DBs, a bit smaller. Sync started - everything flattened
- Tab S6 lite: DB grew massively in size (now 1.4 GB), but seems to work at least. However, now with a new sync start, the points are flattened (groups are still there, but empty)

[michaelbechtold]

New observation on the Tab: all groups are there twice, some appear even a third time. Many of them are not complete.
Quite a mess !

[Menion]

Do I understand correctly, that you have more devices, everyone with your own version of the database and you started full sync on all of them? Then all your data are merged on the server and downloaded on all devices!

During the first sync, you have an options to perform "full-sync" so merge current device data with data already existing on the server or start sync as a new device, so all local data are deleted and data already existing on the server are downloaded -> and this option should be used on all secondary devices!

[michaelbechtold]

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.

[janaton]

Hi michaelbechtold,
thanks for your time, testing sync and giving us feedback.I would like to reveal a little bit of technical side of sync algorithm and explain why sync is not working as you would expect.

Each object in device database (point, track) has to be uniquely identified. We use unique numeric ID for this purpose. If you have multiple devices (e.g. D1, D2) there is absolutely no guarantee that point[#1] (point with id=1) in D1 is the same as point[#1] in D2. This is true in the case when you transfer DB from D1 to D2 but in general we can not assume this.

Possibly, we could try to match objects by all properties but it is not correct, in my opinion, too. Let's imagine, that we have exactly the same point[#1] on D1 and D2. When you make minor modification to point[#1] on D1 then point[#1] on D2, which was previously the same, is now different one.

In order to match objects server side we added another ID to client DB -  UUID (example: 162d3708-b2d1-458d-8054-d8e866fb9b10) which is used as unique identification of object across all your devices (as explained, simple numeric ID can not be used for this).

After rolling out new Locus version including synchronization (UUIDs will be automatically generated) then you should be able copy and paste objects between devices and sync should have no issue with it (objects will be correctly paired using UUID) and synced correctly - no duplicates should occur.

Unfortunately, in your case, each device will generate different UUIDs on every device thus you will need to sync these changes manually, once. I will discuss this scenario with @Menion. Hopefully, we will by able to come up with some idea to make this merge easier .

I hope that my explanation is good enough for you and understandable. If not, do not hesitate to ask me .

[Tapio]

I can totally feel what MichaelBechtold is saying. Currently, the user cannot see what is about to happen and what is stored on server side. Backup/sync means a lot of complexity after all.
I am speaking very general. Experience is telling us, there will be a lot confusion, (assumed) data loss etc... A lot of users in need of support. Lots of pain for the dev side. I think it is crucial that a user can easily see/understand what exactly will happen to the data after he presses "sync".

Just one aspect of the pain: I am convinced users will at first understand this as a backup system, as it is happening with RAID systems. So when they accidentally delete a track on client side, they likely expect to get it back via a sync -which will not happen. Which will delete on server side as well.

You opened pandoras box  

[Frivold]

I have tested the new version now, and i like it very much! But one thing is missing, when I tap on a point in map, then I don't get the context-menu, that I am used to. (Fex guide too, detail etc).