dive site handling

[Dirk Hohndel]

> On Feb 24, 2019, at 2:33 PM, Berthold Stoeger <bstoeger at mail.tuwien.ac.at> wrote:
> 
> On Sunday, 24 February 2019 23:11:36 CET Dirk Hohndel wrote:
>>> On Feb 24, 2019, at 12:20 PM, Berthold Stoeger
>>> <bstoeger at mail.tuwien.ac.at> wrote:> 
>>> To me it seems somewhat questionable to create a new dive site for every
>>> new GPS location anyway. Perhaps detach these two things?
>> 
>> The problem is how else would we do this?
>> From a workflow perspective... I have a GPS dive computer. I download from
>> it. It provides me with GPS information. So after the download I should
>> have an un-named dive site with the correct GPS information, shouldn't I?
>> What would be a better workflow?
> 
> My intuition would be to save the GPS information with the dive and use that 
> to suggest sensible dive-sites when doing the dive site association. Little is 
> gained by automatically generating a new dive site for every dive, if it has 
> to be consolidated afterwards anyway.

Totally true. And we already do that. But since today we have no way to
create a dive site FROM that info in the dive, it's created when the dive
is created. But you are completely correct - it would make a LOT more
sense to switch to a model where you explicitly create the dive site from 
information in the dive.

> An "autogen" flag as you suggested might also be viable.
> 
> I wonder if GPS entry & exit should be optional dive fields that are 
> independent of the dive site. After all, you might dive the same site from 
> different entry points, no?

See the email I just sent... the infrastructure for this already exists :-)

> Of course, this all needs some tuning concerning the map, etc.

The map so far doesn't show those additional points at all.
More stuff to be added, I guess :-)

/D