<p dir="ltr"><br>
Il 15/feb/2015 15:43 "Dirk Hohndel" <<a href="mailto:dirk@hohndel.org">dirk@hohndel.org</a>> ha scritto:<br>
><br>
> On Sun, Feb 15, 2015 at 11:19:50AM +0100, Davide DB wrote:<br>
> ><br>
> > My user opinion:<br>
> ><br>
> > Reverse geocoding YES<br>
> > Dive site tags ABSOLUTELY NO<br>
> ><br>
> > We cannot use TAGs for everything. Tags were invented for folksnomies<br>
> > not  taxonomies.<br>
> ><br>
> > Country/State/Place is a taxonomy.<br>
><br>
> Yes. And as many people have pointed out there will not be a location<br>
> taxonomy. Not in a project that I maintain.<br>
><br>
> But I understand that there are otherwise very reasonable people who<br>
> really want to be able to track Country/State/Place of their dives.<br>
> So adding tags is an excellent way to do just that.<br>
><br>
> One person can track certain aspects of the site in tags (say, shore,<br>
> boat, wreck, cave). Other people can use the tags as a poor man's<br>
> implementation of a taxonomy. Or you can do both.<br>
><br>
> As I'm writing this, I'm wondering... should tags for a site be<br>
> automagically shown as part of the tags of any dive at this site?<br>
> So if you mark a site as "shore" then any dive at that site is a shore<br>
> dive? I think that would be very convenient...<br>
> And it means that we can very easily extend the filter function to cover<br>
> things like "search for all my dives in Sweden" (hint: ZERO).<br>
><br>
> > Dive site structure should be just a (optional***) text field above<br>
> > the main dive site location got from GPS and eventually from online<br>
> > dive site database or user edit.<br>
> ><br>
> > (***) Under geolocation settings prefs. users have the opportunity to<br>
> > enable/disable the dive site structure field and if enabled location<br>
> > structure is managed by geolocation format chosen by user preferences:<br>
> ><br>
> > country<br>
> > country/place<br>
> > country/state/place<br>
><br>
> This is the problem with taxonomies. Now we are starting to create<br>
> structure. I know at least on diver who always tracks the body of water. I<br>
> know another one who for reasons I cannot explain tracks the county.<br>
><br>
> I don't want to try to create a taxonomy that makes every one happy. I<br>
> don't want to have to think about the data structure below that. I don't<br>
> want to think about the insanity of trying to import from different data<br>
> formats.<br>
><br>
> With tags we can simply have a drop down that allows the user to pick the<br>
> separator and have each of the components that get added to the site name<br>
> be parsed out into tags. And then the user can filter for that, do<br>
> statistics on that, etc.<br>
><br>
> > Hence location structure text field IS NOT user editable: everything<br>
> > is taken from GPS point in a reliable manner (I agree with Linus on<br>
> > GPS point).<br>
><br>
> And I disagree on that. GPS reverse lookup is nice - but many sites have<br>
> no GPS. I have a ton of old sites in my dive log before I started tracking<br>
> GPS locations. I have no intention of faking the GPS points, nor do I want<br>
> to be excluded from having these sites tracked.<br>
><br>
> > Regarding localization I'm not a cartographer nor I ever played with<br>
> > Google or OpenStreetMap reverse geolocation API but I suppose that<br>
> > should be a way to control localization: Right now setting Subsurface<br>
> > in Italian language I see all places in Italian language but countries<br>
> > are always in English. I see Italy and not Italia regardless of my<br>
> > language settings. I do not know if Subsurface indicates any locale to<br>
> > Marble map either...<br>
><br>
> That's odd. I tried with German and French and the countries were returned<br>
> in the UI language. I wonder why they were returned in English for you...<br>
><br>
> > But again please do not mess everything with tags that was invented<br>
> > for Folksnomies not  taxonomies.<br>
> ></p>
<p dir="ltr">> > Country/State/Place is a taxsonomy.<br>
><br>
> Not in Subsurface.</p>
<p dir="ltr">Dirk do not fool yourself.<br>
Are you bending reality?</p>
<p dir="ltr">That is a taxonomy . it's a matter of fact.<br>
Online Database and services where you get the data have it as a taxonomy. It's the reason because you can access to them via an API because they are taxonomy. Otherwise Germany Italy apple and orange would be the same.<br>
I was repeating endlessly that I agree with you that we do not force a specific taxonomy and you left the user choose.<br>
You know what you can get from online services (I mean which fields) and you offer users what it makes sense for them.</p>
<p dir="ltr">I do not want having CCR PHOTO REEF WRECK PHOTO VIDEO with ITALY and TUSCANY.</p>
<p dir="ltr">At least you should divide them in two separate sets.</p>
<p dir="ltr">But really I do not understand why you would mix everything when you know exactly which kind of data you fetch from online services.<br>
I mean you fetch "Florida" and "Wakulla spring". You know exactly what they are but you save them as two tags.<br>
A big mess...<br>
</p>