Why GUID ?

[fgd3]

Originally Posted by nohal

They are detected and handled - the one coming later is changed. Product of mixing import with load. If someone has a better idea, it's welcome...

1. GUID conflicts are not detected and handled. Try the 11-step test I suggested in #5 and you'll see that.

2. It doesn't seem to me that better ideas are welcome. Piotr and I have offered better ideas but you focus on defending your scheme for using GUIDs. Better idea #1: Generate a new GUID when an object is changed. Better idea #2: Remove GUIDs from the .gpx files.

We're not trying to be difficult, Pavel, and we do appreciate the work you've done. But the GUIDs for routes and waypoints in .gpx files aren't working correctly. Either we agree about the cause and misunderstand one another, or I'm right and can't explain it to you, or you're right and can't explain it to me. In any case, the answer is more communication. I read your posts and try to understand what you write and respond, patiently, to the best of my understanding. I'd like you to do the same.

Fabbian

[fgd3]

Originally Posted by nohal

Fabbian...
Enough. The guid is in the extensions section which is there exactly for this reason, it has absolutely no influence on other programs using our GPX and is 100% according to the standard.

Howgh

Pavel

I don't understand that. My point was that if the GUIDs are supposed to identify objects in an interconnected world it won't work if different programs operate on those objects. I don't know if other programs would preserve OpenCPN extensions but I know OpenCPN throws away extensions it doesn't recognize. I would expect that to happen with other programs as well, so your GUIDs would be lost when the objects are passed through another program. That's not the behavior you want in an interconnected world, is it?

Fabbian

[fgd3]

Originally Posted by fgd3

1. GUID conflicts are not detected and handled. Try the 11-step test I suggested in #5 and you'll see that.

Pavel,

I took another look at this. If you follow the eleven steps from #5 you'll wind up with three .gpx files which have different objects but the same GUIDs. However, if you import those three files and then export them the new second and third files will have new GUIDs. You detect collisions at import time. I still think that's incorrect, but it explains why you thought they were being detected and handled and I didn't.

Assume the three files were written with the same GUIDs, then, in a later session only one was imported. No collision is detected, so the conflicting GUIDs remain in the files indefinitely. I don't know if that might have consequences later.

Fabbian

[nohal]

Fabbian,
I'm very happy, that you finally found out how the things work. I hope you also understand now, why it is so important what the scope we are talking about is. The scope of our current implementation is one OpenCPN instance and the last bug I'm aware of (the loss off sharing info for routepoints) stays to be fixed to make it work as designed and expected.
The rest is really just a coincidence and guids in the "exported" gpx, and it is again very important to uderstand that it means user wanted to transfer the data out of the implementation scope, are there just because there aren't two buttons in the routemanager. Nothing more, nothing less.

Of course I would like to extend that scope, but it will get tricky (and will pose new challenges) as we will have to start identifying all those Anns, Betis and Zoes to make it work.
What I would also like is make the guid a primary identifier to the objects, which it now is not by design, but if changed would probably make happy all you guys who think it is the only use this (almost)random string can and should have.

And no, we will never be able to change the files on user's disk(s) just because we don't like their contents

Pavel