Silly problem with dive sites and GPS downloading

Dirk Hohndel dirk at hohndel.org
Sat Sep 22 14:07:09 PDT 2018


> On Sep 22, 2018, at 11:17 AM, Linus Torvalds <torvalds at linux-foundation.org> wrote:
> What happens is that you download your dives for the day, and you are 
> reall yhappy to just get the location data automatically. But the Garmin 
> doesn't know the _name_ of the dive site, obviously, it just has the GPS, 
> so you edit the name, and you're all done. Great. No problem.
> 
> Now, you're on a dive vacation, and the end of the *next* day, you 
> download the new dives for _that_ day, and you get all the GPS data for 
> the new dives too. Everything is fine, right?
> 
> No, not everything is fine. Because what happens is that the 
> libdivecomputer download doesn't just download the new dives, it starts 
> downloading _all_ the dives from the Garmin Descent, and parses them, and 
> in the process eventually notices "Oh, I already had this dive", and 
> that's when it stops downloading.
> 
> That still sounds fine, right? You never see the old dive, because we 
> noticed it was old, so it doesn't matter.
> 
> Wrong again. As part of parsing the dive download, it obviously parses the 
> GPS data, and it generates the dive site information for the GPS data.  
> And this happens REGARDLESS of whether the downloaded dive is actually 
> used or not. 

now THAT is the actual bug, IMHO.
We should only keep dive sites that are referenced from dives that we keep.
This isn't a case that we've had before since as you correctly point out we didn't
use to create dive sites when downloading from a dive computer, but regardless,
a dive site that was created as we parse a dive which we then ignore should also
be ignored.

> And, in fact, because we use the same name, and the same dive time, we are 
> guaranteed to create the same dive site uuid when we do this. See above 
> about *why* we very intentionally do this. So when we download a dive - 
> whether we will actually *use* that dive later or not - we will be filling 
> in the dive site information with the data we got from the dive computer.
> 
> ... and in the process we will be overwriting the data that we filled in 
> manually yesterday. The name of the dive site, but also possibly even the 
> GPS of the dive site (maybe the user decided to edit that using the map, 
> because while the automatically downloaded GPS data was "correct", maybe 
> the user wanted to change it to be the actual under-water location using 
> the satellite data, rather than the place where you started the dive or 
> where you surfaced.
> 
> There are a few obvious solutions to this mess:
> 
> a) the uuid approach and indirection just isn't worth it.
> 
> b) just make the libdivecomputer download not use the dive time, but 
>    "time of download" of something for the dive site time, and thus 
>    effectively generate a new uuid for every download.
> 
> c) notice when we already have a pre-existing matching uuid, and just use 
>    the old information for the newly downloaded dive.
> 
> 
> (b) is what the patch below actually implements. It will cause merge 
> conflicts if you download the same dive on two different machines without 
> having done a cloud sync in between, but honestly, you'll probably get 
> those merge conflicts anyway, and it shouldn't be fatal.
> 
> (c) is the other approach that would make sense, but the way the dive site 
> code is organized, it's just simply a more painful patch. It might be the 
> better approach, though.

Or my suggestion (d) to not create a dive site when not accepting the dive.

But yeah, I'm ok with (b) for now.

> I've added my sign-off to the patch, although the above explanation should 
> be made into a commit log entry to explain it.

I'll apply this to master

> PS. We have another pending problem with the dive site situaiton: the 
> Garmin Descent Mk1 gives us both entry and exit coordinates, and having 
> done four drift dives with it, I actually really *would* like to have our 
> mapping to show it as not a flag, but as a line between two points. But 
> right now we only associate a single GPS coordinate with the dive, and 
> because the Garmin reliably gives an exit coordinate but not an entry one 
> (if you jump into the water before it gets a GPS fix), the downloader will 
> just use the single exit point for the automatic dive site.
> 
> But that pending problem is an enhancement, not a bug.

Yes, and we already had people who said that they want us to associate a
path with the dive. And my answer to this continues to be that the visualization
is a pain and that I am not convinced that the accuracy of these GPS coordinates
is nowhere near good enough to make all this worth it.

/D


More information about the subsurface mailing list