[Tagging] man_made=works

[Daniel Koć]

W dniu 01.06.2015 7:15, Marc Gemis napisał(a):
> On Mon, Jun 1, 2015 at 12:48 AM, Warin <61sundowner at 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]