Dive Site Duplicates [was Re: Dive site management on daily build 4.4.2.669]

Davide DB dbdavide at gmail.com
Wed Jun 17 07:23:01 PDT 2015


On Wed, Jun 17, 2015 at 4:16 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
>
> Let me try to explain. Every aspect of the information we have about a
> dive site could change. The user could edit the name, the description,
> could move the GPS coordinates. To them it's still the same dive site. And
> the dives that reference it by its UUID need to still be connected to it.
>
> So we cannot use a hash of the information contained. It has to be a
> unique but otherwise random itentifier.

Ok I understand now. It make sense.

> Now an interesting question comes up when we import data from a different
> source. We have some dives loaded already and we are adding more dives to
> it. We could conceivably try to see if we have matching dive sites and
> then adjust the UUID of the imported dives accordingly. So if the new file
> contains a dive site with the exact same name and a GPS location within
> 20 meters, we could say "it's the same site" and instead of adding a
> second copy we could simply put the correct UUID into the imported dives.

Ok, this was the matching algorithm we spoke about few days ago.
I think the 20/25m area for gps fixes is already implemented because I
run an import with the latest build and 8 dives with very near gps
created 7 dives. Now just three.


> Would you file a bug so this doesn't get forgotten with everything else
> going on right now?
>

Yes of course


-- 
Davide
https://vimeo.com/bocio/videos


More information about the subsurface mailing list