Exporting dive sites as XML

[Doug Junkins]

My hope is that an XML file import and export of dive sites will meet 99% of these use cases without being tied to building a back-end service. People can share XML files of exported dive sites with friends and, if a more public dive site catalog/directory is developed, the output of that could be an XML file that is downloaded with the selected dive sites that a user wants to import.

It may not be as sexy as a new social network, but it should meet most users needs.

-Doug

> On Apr 11, 2019, at 8:26 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
> 
> On Thu, Apr 11, 2019 at 11:13:35AM +0200, Robert Helling wrote:
>> 
>> 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'll admit that I hadn't intended to create a new social network. Nor had
> I contemplated building the back-end service that supports all this, but
> if this is where people want to take it, I'm certainly willing to
> entertain the notion.
> 
> From a design perspective that means that any text we store needs to
> tagged with the corresponding language string - otherwise how would you be
> able to maintain translations into different languages, right? Because for
> my own dive log I pick the language I care about, but if I want to be able
> to share dive sites outside of my immediate circle of friends and family,
> that consistency in language becomes less obvious.
> 
> This impacts a lot of things from keeping that information at runtime to
> data format at rest. One obvious first simplification to make is to design
> in a backwards compatibility to our likely initial state: if no language
> information is stored, it's assumed to be in the language that Subsurface
> is running in. That (I think) would allow us to release a 4.9 version that
> doesn't track language, yet.
> 
> Somebody please check my logic here :-)
> 
>> 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?
> 
> I think the logic proposed by Doug and others makes sense. If you have
> your own named dive sites, then those should be preferred. If you are
> searching for a dive site near where your dive was, then we should show a
> list of those within N meters of the location (that either comes from your
> GPS info or from something that you picked on a map) should be shown on
> the map and you can decide which one to pick. Would that solve your
> problem?
> 
> /D
>