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 <[email protected]> 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 > _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
