dive site handling

[Dirk Hohndel]

I love the discussion here... I wish more people would speak up, though...


> On Feb 23, 2019, at 7:48 PM, Doug Junkins <douglas.junkins at gmail.com> wrote:
> 
> At this point in our diving “career”, almost every dive is at a new site to us. What I’ve found is that, usually we are so focused before a dive on making sure our equipment is ready, listening to a dive briefing, etc. that we don’t think to mark our location with the phone app before storing our valuables away.

This is why the app has the "GPS service" mode which you turn on as you get on the dive boat and then turn off when you are done diving. It stores GPS fixes based on time / distance and then matches the best one to the dives that you logged. This was Linus' idea way back when we first started trying to get accurate GPS information. And it works fairly well. Of course having a Garmin Descent is even easier :-)

> My initial thought before I even mentioned anything to Dirk was that it would be nice to have a “choose dive site” button next to the “edit dive site” button that exists today on the main page defined in “desktop-widgets/tab-widget/maintab.ui” (similar to the idea Henrik presented in 2016). In my mind, the “choose dive site” would be an alternative to the existing method of selecting a dive site through auto-completion drop down and would not replace the existing functionality. The “choose dive site” would query an online data base of dive sites with some geographical filters to scope the choices. I also envisioned a social network aspect to the online database where you can have a network of connections to other divers and can scope the query of the online site data to either your own dive sites (which, to be honest, is redundant to the existing functionality in the app), sites of your connections, or “public” sites. The management of these connections and privacy settings could be done through a web interface instead of through the Subsurface app to limit the changes necessary in the app. The other requirement would be to be able to publish your dive site information from the app to the online database. Once you push your dive site information to the database, you would be able to set the privacy to private, connections or public.
> 
> I’ve looked back through the archives from April 2016 that Dirk linked to, as well as the thread from September 2018 about GPS and dive site management that arose from the Garmin import issues. Obviously there is a lot of history there that I would miss as a new user. It seems that the level of abstraction between dive data and dive site information has been contentious in the past. I also understand that there are would be a lot of privacy concerns about sharing dive site information, or more importantly, dive data.
> 
> After reading some of the history in the archive, I realize that my idea above does not address several issues:
> 
> 1) After you edit the information for a dive site, does that change apply to all dives in the past that share the same site?
> 2) After you edit the information for a dive site, does the change get updated in the online database automatically, or do you have to republish it? If it is republished, are people that have used that site themselves notified of the change?
> 3) Since the dive site unique identifier is derived from the site name and the time that the site record was created, should the uuid be stored in the online database and be consistent for everyone that has selected that site from the database, or does each subsurface user have a new uuid created locally when they first use the site? Or can we add a field to the local record that references a global uuid for the site in the database?
> 
> I’m sure there are many more issues that I am not aware of.

This indeed opens a whole lot of other issues.
- do we want to create our own database?
- wouldn't it be much better to connect to existing ones? At least some have APIs that would allow that.
- this requires a backend service... having done a couple of those I know how much pain that is. I'll be open to maintaining yet another one if we have decent value for our users - but this would HAVE to be well designed

I think the first step should be to clean up the way we treat dive sites and how they are connected to dives and the user experience around that.
Because once we have a better view of that 'create dive site' interaction, hooking in the option to search for the GPS fix in some form of backend service should be fairly independent from the rest of all this.

> Whatever the direction, I am willing to help develop some of these capabilities in Subsurface. I don’t have experience developing in Qt, but I am willing to learn. Being a network geek, most of my experience is in Python and Perl (obviously I’m dating myself), so I am especially keen to help on the web service side to do some rapid prototyping.

You have no idea how much I love to hear this. We need more active developers :-)

Most of us didn't know Qt 6 years ago :-)

/D