On Wed, Jun 17, 2015 at 4:16 PM, Dirk Hohndel <[email protected]> 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 _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
