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

Dirk Hohndel dirk at hohndel.org
Sun Feb 15 10:36:17 PST 2015


On Sun, Feb 15, 2015 at 06:09:38PM +0100, Davide DB wrote:
> 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 ;)

I'm beginning to see the problem. I may not be using my words correctly.

What I'm trying to say is this:

I don't want to present the user with this:

Country:        ____________
State:          ____________
State district: ____________
County:         ____________
Town:           ____________
Suburb:         ____________
Body of water:  ____________
Site name:      ____________

So I'm thinking about the concept of "tags" in order to address that.
Let's call it "structured tags". Let's call it a taxonomy. Let's call it
whatever makes you happy.

> 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.

Yes, you are right.

We should have location tags separate from the overall tags.

And your example that dive sites can be boat or shore, wreck or reef
convinced me that this isn't the right way to do this, so those tags will
indeed stay on the dive.

> > 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.

Yes.

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

Agreed.

> At least you should divide them in two separate sets.

Yes

> My original idea was: Let's user choose what he want for their logbook:
> 
> * None
> * country{}
> * state{}
> * county{}
> * town{}
> * suburb{}

OK... so this is in the preferences... hmm. If we go with my proposal and
store this in a tag list structure and encode the source as what attribute
they reflect... this could end up being simple, extensible, and flexible.

I worry about adding more options and I worry about the UI, though. It's
easy to do this when you have GPS data. Without it, how do you present
this to the user?

And an existing user upgrading to 4.5... right now I do the conversion
before the UI starts. That doesn't really work as we can't show a progress
bar... But we could do a "first start" screen. So if the data file is of
V2 format (either default file or command line argument) we at first don't
open it... we show a welcome screen that explains that we now have the
dive site feature. We ask them which attributes they want to keep in their
dive site list. And we can ask them for the language they want (so even if
you run the UI in English, you might want the country, etc. in Finnish).
Then we process the file (and show a nice progress bar).

Hmmm... this could work.

> > 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.

Can you give a few sample GPS locations where you get some component of
the reply in English? So an English country name, the rest in Italian? Or
everything in English?

There are three major providers of these reverse lookup services.
Google has a very low max usage count per IP address per day unless you
pay. So for a prolific diver (or someone who tests this a couple of times)
it would be very easy to run into that limit. Bing has a more reasonable
limit (I think 30k requests a day) so that would be an alternative.
Openstreenmap through MapQuest doesn't appear to have a firm limit, that's
why I picked them, but it's possible that the quality of their data isn't
as good.

/D


More information about the subsurface mailing list