> On Sep 22, 2018, at 11:17 AM, Linus Torvalds <torva...@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 _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface