dive site handling

[Dirk Hohndel]

Hi Berthold

> On Feb 24, 2019, at 1:01 AM, Berthold Stoeger <bstoeger at mail.tuwien.ac.at> wrote:
> 
> From the comments so far, it seems to me that there are at least four, 
> probably more, not completely independent problem fields.
> 
> 1) The UI. We want a list of dive sites with add / edit / remove / search 
> functionality.

I think Henrik's proposal could be a starting point. Add country. What else?

> 2) Dive site fields. Is one GPS coordinate sufficient?

Linus had posted about this a while ago, and then he and I discussed the idea a little more
on board a dive boat; let's see if I can recall what we came up with:

A dive site has one GPS fix. That's the canonical spot where the site is. For example
for Ulong Channel, you could pick this: https://goo.gl/maps/DBa6VX1Q8Ey <https://goo.gl/maps/DBa6VX1Q8Ey>

A dive is associated with a site, but can also be associated with any number of GPS locations.
Maybe start and end. Or even a path. So a dive at Ulong channel may have these two GPS
fixes:
https://drive.google.com/open?id=1lrEQYMwaqD-ZS5-xDRcy8lNV962ooR80&usp=sharing <https://drive.google.com/open?id=1lrEQYMwaqD-ZS5-xDRcy8lNV962ooR80&usp=sharing>
(wow, that took me a while to figure out how to create such a map with two fixes)

In other words. A dive itself might have no location information. Or include a dive site
that has no GPS fix. Or a dive site which does have GPS information.
But ADDITIONALLY, a dive can also have any number of GPS fixes itself.

The way we decided to do that was that we allow dive strings (under Extra Info)
with the magic names GPSn to carry that additional information. And that's already
implemented in the Garmin downloader. So a recent dive of mine included this:

<divesites>
<site uuid='c31e090c' name='Fan-tastic' gps='-17.316311 177.962188'>
</site>
</divesites>

And as part of the divecomputer entry:

  <extradata key='GPS1' value='-17.316491, 177.962047' />
  <extradata key='GPS2' value='-17.316311, 177.962188' />


Today we have no UI to edit this information or to visualize this information. But
we have a way to store it :-)

> 3) Semantics of editing dive sites. Copy on write?

That should be optional. I tend to think that it makes no sense to have two different
dive sites in my data that are actually the same site. But others may have a different
view on this. With the logic explained in (2) above I think it makes sense to have one
dive site and have variations to entry / exit point stored in the dive. But again, that's
just my personal preference.

You could ask "change current dive or all dives at this location?" or something like that.

> 4) Synchronization of dive sites between distinct dive logs.

That's what Doug was talking about (and others before him). A simplistic version of
this shouldn't be hard to do - but the devil is in the detail...
This is something that should be completely separate from the above, frankly.
And it needs a lot more design discussion (as Doug mentioned).

> Since I was planning on integrating the dive site handling into the undo-
> system anyway, I propose that I realize 1) while I'm at it. Since I recently 
> replaced dive site UUIDs by pointers I hope that I still have a decent 
> overview concerning this part of the code base. But give me a week or two 
> (first I want to finish the grunt work of undo of the notes-tab).

Cool.

> For 2) to 4) I'll not interfere, as what we have so far is adequate to me.

I think it would be very nice if you could comment on 2 and 3 above and make sure
that the combination of ideas still makes sense.
The ability to edit extra fields would need to be part of the undo system. A first
implementation could just allow the user to edit the entries as text. And then
maybe someone could connect a map / graphical interface?


/D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20190224/f9e222bf/attachment.html>