Ok, spent the last half hour reading back up on what we discussed four
months ago.
Thanks Davide (as always) for reminding me that I completely forgot what
we discussed back then...
On Sun, Feb 15, 2015 at 10:36:17AM -0800, Dirk Hohndel wrote:
>
> 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.
Yes, so we need to add our TAGxonomy :-)
> > 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.
A dive site should get a tag style location taxonomy so we can easily
filter the sites. And that tag field is missing in our data structures /
UI. Oops.
> > > 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 need to go back and create a strawman implementation for this so we can
see how this would work with real data. Since my work on the cloud storage
is stalled until we have push support in Subsurface I may look into this
next.
> > 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.
I'll work in that direction. But I'll also add a way to trigger a manual
conversion - beacuse everyone who is using a current build and has saved
data in V3 format is left out...
I edited this old conversation to just bring the high lights back.
Now that we are all four months older and that some of us are four months
wiser... anything to add?
Henrik, Davide, others... will this fulfill what you are looking for?
/D
_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
