Locus Map 4, discussion (alpha)

[john_percy]

@menion Would you like one of my photos to try? I think they are all from my phone camera so it might be worthwhile to check if there is something odd with them?

Sent from my moto g(6) plus using Tapatalk

[Menion]

We may give it a try to verify it really isn't this issue. Just send me it on our help desk please locus.map@asamm.com , thanks. Anyway, I expect this won't be the real reason of this problem.

[balloni55]

for me the same isue with photos as John reported with PRO and LM4
photo taken with OpenCamera is visible
photo taken with samsung camera is not visible
as thumpnail
https://www.dropbox.com/s/zg0907y2znd4fz9/desktop.zip?dl=0

BTW, what means the green or blue triangle in thumpnail of LM4?

[Menion]

Thanks, as I've already wrote in topic with a recent version, I'll have to look at it.
Colored corners are there only for testing purposes to see from where the image comes (memory, disk cache, downloaded).

Btw. seems that our few months long work starting to work https://www.facebook.com/watch/?v=666660640589165

[Tapio]

Btw. seems that our few months long work starting to work https://www.facebook.com/watch/?v=666660640589165

Use case? Looks like personally I do not need it. 😔 Just one device... Sometimes I copy the whole db from stable for use in Beta.

[jonny.blue]

Btw. seems that our few months long work starting to work

Two devices ... and therefore:   

[Menion]

@tapio
if you won't need it, you don't have to use, it will be definitelly optional service.
Anyway, together with web site for planning & sharing, it will be ... ahh finally .

[Jochen]

@menion :This is really good news. I recommend Locus Pro to almost everyone I know, but a lot of them stay with or decide themselves for komoot. But if there is a website like the one from komoot with  Highlight Pictures and maybe with better BRouter Routing and an easy way to use it, I think no one would choose komoot anymore.
Take your time for developing it. Good luck.

Kind regards

Jochen 👍 👍👍

[Andrew Heard]

Btw. seems that our few months long work starting to work https://www.facebook.com/watch/?v=666660640589165

Let's rock.... Got it!

[Tapio]

@tapioAnyway, together with web site for planning & sharing, it will be ... ahh finally .

Again, What is the use case? What is it I am not seeing? In the video, I am just seeing "syncing between two own devices" - but now you mention "web site for planning and sharing". Jochen mentioned Komoot alternative.
I am feeling stupid now.

[Menion]

What you see, sync data between two devices, show that there is not a simple direct connection between devices on the table, but that points/tracks/groups are uploaded into the big database from one device and then downloaded to the second device. Once this will be working, it is the first step for another service that need this, like > drawing track on the web and send to your devices once saved, or sharing some points/tracks with your friends over the simple link or editing points/tracks on the web as well etc.

[slarti76]

What you see, sync data between two devices, show that there is not a simple direct connection between devices on the table, but that points/tracks/groups are uploaded into the big database from one device and then downloaded to the second device. Once this will be working, it is the first step for another service that need this, like > drawing track on the web and send to your devices once saved, or sharing some points/tracks with your friends over the simple link or editing points/tracks on the web as well etc.

Will it be possible to define, per device, what folders to sync? So there's one big database on the server, but the devices don't need to sync everything?
And is it correct that the sync is not yet available in the test build? Sorry if I missed something, I'm new to the LM4 party

[michaelbechtold]

After some years of Locus usage, the Tracks DB can exceed one GB easily.
Is this sync feature capable of handling such?
Is it reasonable to try at all ? For everybody ?

I am still in favor of providing a secondary, local Track DB with easy way to move/copy between the active and the secondary. (So, if you need to sync a historic trail, this is still possible easily.)

And only the active one goes into sync.

[slarti76]

After some years of Locus usage, the Tracks DB can exceed one GB easily.
Is this sync feature capable of handling such?
Is it reasonable to try at all ? For everybody ?

I am still in favor of providing a secondary, local Track DB with easy way to move/copy between the active and the secondary. (So, if you need to sync a historic trail, this is still possible easily.)

And only the active one goes into sync.

I think my proposal would solve that, too: Just define Archive folders that are not synced normally. So you only have to upload the whole DB once, and after that set only the currently used folders to sync. Of course there must be an option to create a local backup of the whole DB somehow - so in case something goes horribly wrong on the server, you could just copy the local copy over the current DB and start anew with syncing.

[Menion]

@slarti76
current there is no plan to define what should and what should not be synced. But probably a good point. It should save us a few cents on the server and users may be happy not to sync some private data. Anyway in the first versions, it will for sure be "all or nothing".
And yes, it is correct, it is currently not available even to the rest of the Locus team . And during August, it will be for sure ready for test for the brave one .

@michaelbechtold
we count with this. There is too many unknowns, so we are counting with the worst cases first. Currently, first initial sync of my 400 MB database took almost 2 hours, so 1 GB ... well, we will have to improve performance a little bit .

Secondary database is a nice idea. It is not just about sync as you wrote slarti, it is also about performance. 1 GB database may suffer by slowness because table with points ... it really long, so simple load of track may be few times slower than from empty database.