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