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
