Exporting dive sites as XML

Robert Helling helling at atdotde.de
Thu Apr 11 02:13:35 PDT 2019


> On 11. Apr 2019, at 10:26, Dirk Hohndel <dirk at hohndel.org> wrote:
>> Regarding the import, I’m thinking about having a checkbox that allows you to ignore sites with X meters (to be defined in an input box) from an existing dive site, but I’m wondering if that should be a silent ignore, or should there be a log visible showing whether each site was imported or ignored. Or, alternatively, do I replicated the functionality to import dives from a dive computer where each site to be imported needs to be selected before executing the import?
> This is a question to those most likely to use such a feature, right?
> I don't think I'm part of that group - conceptually having silent ignores
> is more likely to cause confusion...
> In my dive log I have several cases where I have the same dive site, same
> name, with slightly different GPS locations depending on the tide and
> therefore the entry point for the dive... which goes back to an argument
> that Linus made a while ago that this should be ONE dive site and that the
> dive itself should mark its entry point...
> What I'm trying to say is that what we decide to do here also has impact
> on the overall design of how dive sites are treated in Subsurface.

this is really a tough one. Let’s keep in mind in which direction this (if it takes off at all) might go to: Rather than sharing your own dive sites between a few of your own log files (or maybe with your wife or your close friends), this whole dive site management becomes really powerful as soon as some big dive site collections are created (like all dive sites in a country, a continent or even globally) with the collections shared essentially between all Subsurface users. This would allow you pretty much automatically fill in dive site data based only on GPS since pretty sure, somebody will have dived the same dive site at some point in the past. These collections will contain hundreds or thousands of dive sites so manual import selection is not viable. These collection could also be used to figure out where it is actually worth going to. Another aspect is of course language: We might want to remember the langue of a dive site description so that I can decide to only import those that are in a language that I can understand.

I am not saying that we need to implement all this right now, just keep in mind that this is a direction into which things might develop.

Regarding identifying dive sites that are in some sense close enough: This is not just a matter of comparing two sites: Most of my local dives are in lake Starnberg: https://goo.gl/maps/msX7Mv29mz72 along a roughly 1 km stretch on the east coast. In principle you can enter the water at almost any place along that stretch but there are definitely distinct dive sites, I can think of at least five names people use for different entry points with dives hardly ever overlapping. Would you want to group all into one single site as any two GPS fixes of entry points are connected by other entry points which are pairwise close by? Or do you want to treat those as all different?

In the current system, I have five dive sites that I refer to by name.  But as soon as I start importing other people’s dive site collections they will use different names. So what shall I do?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20190411/907675b9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2019-04-11 at 11.12.14.png
Type: image/png
Size: 122497 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20190411/907675b9/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 528 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20190411/907675b9/attachment-0001.sig>

More information about the subsurface mailing list