Dive site tags [was: IMPORTANT information about current master: dive site management]

[Davide DB]

I try to recollect all the main question/replies here:

> Yes. And as many people have pointed out there will not be a location taxonomy. Not in a project that I maintain.

Ok I shut up ;)

> But I understand that there are otherwise very reasonable people who really want to be able to track Country/State/Place of their dives. So adding tags is an excellent way to do just that. One person can track certain aspects of the site in tags (say, shore, boat, wreck, cave). Other people can use the tags as a poor man's implementation of a taxonomy. Or you can do both.

As I wrote we are mixing apples and oranges here. Of course also
"shore" and "ccr" are apples and oranges (just to cite two common
tags) but tags that refers to a location are really different form
other tags so mixing them is a mistake.
Only the fact that you are writing so much code, a special UI and
there are online services for them it's the real demonstration that
they are first class citizen [cit.] so continuing to say that we will
never get a taxonomy is a bit of a fig leaf :)

> I don't want to try to create a taxonomy that makes every one happy. I don't want to have to think about the data structure below that. I don't
want to think about the insanity of trying to import from different
data formats. With tags we can simply have a drop down that allows the
user to pick the separator and have each of the components that get
added to the site name be parsed out into tags. And then the user can
filter for that, do statistics on that, etc.

That is a use case. We are aguing here because there several use cases
involved. We can try to describe different actions/scenario.

> One way around that is to tag the tags. we have this concept of a tag
> source. Maybe that can be used here to show which attribute from geo
> location was used to create a tag - and allow the user to remove all tags
> that are "country" or "city" or "state". One problem with that approach is
> that today we only have this in memory, but that could be a simple
> extension of our syntax: store these tags as
> country{}Germany
> state{}Baden-Württemberg
> state_district{}Regierungsbezirk\ Tübingen
> county{}Bodenseekreis
> town{}Meersburg
> suburb{}Riedersweiler
>
> Where the optional part before the {} is the source (in this case it's the
> attribute given by the reverse geo lookup API of openstreenmap).

The above quoting is exactly what I meant when I wrote:

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.
I was repeating endlessly that I agree with you that we do not force a
specific taxonomy and you left the user choose.
You know what you can get from online services (I mean which fields)
and you offer users what it makes sense for them.

I do not want having CCR PHOTO REEF WRECK PHOTO VIDEO with ITALY and TUSCANY.

At least you should divide them in two separate sets.

But really I do not understand why you would mix everything when you
know exactly which kind of data you fetch from online services.
I mean you fetch "Florida" and "Wakulla spring". You know exactly what
they are but you save them as two tags.

Tags and taxonomies for Lightroom:

http://www.fastpictureviewer.com/taxonomies/

Look at the UI where you choose how they behave.

My original idea was: Let's user choose what he want for their logbook:

* None
* country{}
* state{}
* county{}
* town{}
* suburb{}


> And I disagree on that. GPS reverse lookup is nice - but many sites have no GPS. I have a ton of old sites in my dive log before I started tracking GPS locations. I have no intention of faking the GPS points, nor do I want to be excluded from having these sites tracked.

Valid point! I did not think about it. Let's add another user case.

If you want to store location attributes in a flat way, you should at
least separate in two different sets. But again, once you have a
separate set or you save the source attribute than you have a hidden
taxonomy :)

> As I'm writing this, I'm wondering... should tags for a site be automagically shown as part of the tags of any dive at this site? So if you mark a site as "shore" then any dive at that site is a shore dive? I think that would be very convenient...
> And it means that we can very easily extend the filter function to cover things like "search for all my dives in Sweden" (hint: ZERO).

Hummm. It depends... User must apply these tags with a pinch of salt.
I have at least three different dive spots in my logbook where I can
dive from boat or shore.
Again I have several dive spots in which you could do completely
different dives. I never differentiate them:
The dive boat anchor on "Giglio Island - Punta del Fenaio" and I could
go on the left (reef dive) or the right (wreck) or staying on the sand
doing macro photography. The mooring buoy it's the same.

A completely different example of my tags: CCR, PSCR, OC. The same
dive could be dove in all three ways. (Right now with the introduction
of dive type I have redundant tags. I will remove them when the
multifilter will filter the dive type). I agree I would be a fool
using CCR as tag in a dive location.

I saw you added "Adding integration with more online divelogs" to GSOC_2015.
you cite diveaboard.com. I have an account there. From what I see they
have an heavy use of Google map reverse geocoding.
If you have GPS point, no problem (maybe) but otherwise a sort of
location structure to interface with them would be necessary.

PS
> That's odd. I tried with German and French and the countries were returned in the UI language. I wonder why they were returned in English for you...

I do not know. I tried in Italian and German again and they stay in
English. Actually they are a bit messed up. Some name is in Italian,
some in English but countries in English.