W dniu 01.06.2015 7:15, Marc Gemis napisał(a):
On Mon, Jun 1, 2015 at 12:48 AM, Warin <61sundow...@gmail.com> wrote:
The mixed ones in particular are hard to mentally recall, organise.
Do you think a tagging schema with several different sub tags is
easier ? Just use the presets in case you don't remember.
Sub tags may not be the answer (especially if the "mixing" is going on a
level above the primary tag), but the presets won't help you too in such
cases, because they're made only for easy finding typical objects.
Once you're out of a comfort zone, you're lost - there are no easy hints
or rules how to tag some similar or more general things. You just have
to create completely fresh tags and hope other will agree. That is true
for seasoned mappers, but even more true for casual ones.
Where/ how do you want to organise ? I usually use search, so I don't
encounter the classification problem often. And isn't the
classification problem a rather personal problem? E.g. some apps want
to group pubs that serve, restaurants, fast food etc. in one category.
I think OsmAnd does.
Every data consumer is of course free to use a different
grouping/classification from the one that is in the raw data.
Sure, but the OSM itself tries to make classification a hard
requirement, because it's a first class citizen in our current schema.
You _have_ to decide whether it's a shop=travel_agency or
office=travel_agent. Sure, the presets make it easier here (just one
true k=v), but what if Wiki pages are unsure? That's still a lottery
then - you just buy a ticket somebody else took the numbers for you.
Also look at the reception_desk "classification" problem. Some want to
classify it as amenity, others as a tourism feature. That just depends
on your needs. There isn't always a classification that works for
everyone.
But we're just mentally caged in a "*=reception_desk schema", so you
still have to be sure what class is this object. In my view you could
tag it only "reception_desk=yes" if you don't know or care for
classification, but you're still able to make it
"reception_desk=tourism" for example, if that's what you're sure about.
I envision classification as a metadata level - we can still have
default one, but outside the GIS database, which would make it easier to
extend it if needed (the more objects, the stronger need to have
something extendable and with more layers). Others can still use our
classification or make their own. Taking the categories outside the
database and letting mappers tag only what they are sure is a win-win
situation IMO.
Reorganisation should bring big benefits, placing e.g. fountain under
tourism does not bring huge benefits IMHO.
I agree, just changing the categories for objects is not gonna work.
I'll agree that introducing the reception_desk key was/is problematic
because of the choice of the top level tag.
The need to choose top-level tag for it is the problem itself.
On the other hand I do not see why we couldn't tag some of them as
amenity and others as tourism and have both documented. It's pretty
easy for data consumers to support both.
And what about presets? Will there be two of them?
And what about another kind of reception desk we haven't heard of yet?
It's easy to believe we already have all the tools for mapping the world
just because we know our city/town/village/country in general (or even
some other countries to some extent), but this may not be enough in the
future.
I think we should concentrate on ground truth ("this is a reception
desk") and make classification based on it (and other hints, if
available), not the other way around.
Take a look at e.g. historic places. They support all kind of
combination for the same things (building=farm, historic=yes or just
historic=farm). They process the data before putting it on the map, so
those things appear the same for the users of that map.
I agree, but you see only the half of the issue. Of course we know just
a "compact" version sometimes (like amenity=reception_desk or
tourism=reception_desk), but we have no tools to chop it to say it's
really "reception_desk=yes + amenity=yes" or "reception_desk=yes +
tourism=yes".
That's the key problem here: we can always glue things together to make
them more complex, but we have no system to extract more general
properties if we don't know details or we want to tag something similar
but with other details!
As I understood the power_sockets problem is that some want to
generalize the "power_socket" concept. Do we always have to try to
find the most general concept and add X number of subtags to say what
we really want to say ? Or can we sometimes just live with the
specialty object (charging place for cars).
We can definitely live with specialty objects! Wikipedia have already
showed that human knowledge is not easy to categorize in a hard way,
because we tend to see some important things as different. So let's not
drop the typical objects, just let it make easier to create not typical
tags when the object is less typical, because once we took all the low
hanging fruits, there will be a need to get the rest.
And you have just showed us that mapping between some complex objects
and more primitive ones is possible, so we can always express complex
ideas in both forms, while we can express simpler, more general things
only when we can name them - and currently we lack a lot of those
primitives, because we try to see only complex things how they are used,
not what they "consist" of.
So let's use the "car_power_socket=yes", because it's popular thing and
easier to express this way, but let it also be the object present in
categories "car" and "power_socket", so we can have related things in a
handy category (like car repair or car washing) and we can create new
power sockets and have them also neatly categorized (like
"power_socket=yes" or "power_socket=home_and_office" - and
"power_socket=car" of course as a synonym for "car_power_socket=yes").
I think the use cases are important, when I'm looking for something to
charge my car, I won't be looking for a socket where I can charge a
computer, and vice versa. Two totally different use cases. In those
situations I would accept a specialty tag for each of them. I know the
world is not black and white and in many cases it will be harder to
decide on a general tag with subtags or a specialty tag.
I support your opinion - use cases are very important!
But currently we live in a "case only" world with no ability to make
anything more general (or to show something is similar) if needed.
--
"The train is always on time / The trick is to be ready to put your bags
down" [A. Cohen]
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
