Exporting dive sites as XML

Dirk Hohndel dirk at hohndel.org
Thu Apr 11 20:26:38 PDT 2019

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


More information about the subsurface mailing list