[Tagging] More flexible categories (was: Re: Removal of "amenity" from OSM tagging)

[Daniel Koć]

W dniu 18.05.2015 16:29, Marc Gemis napisał(a):

> So you want to replace shop=bakery by bakery=yes, shop=butcher with
> butcher=yes, etc. ?
> 
> This means that you cannot write a query that retrieves all shops in a
> town. You would need a list of things for which the value is "yes".
> But you cannot summarize the things, because there is no "category" to
> which they belong and the list is open-ended.
> Don't know whether that is a good idea.

I think it's good to get rid of most fixed categories from the object 
description, because they make more and more problems with the advent of 
new objects, which are not as typical as it once seemed to be. You can 
easily find some ongoing discussions (and some more in the archives) 
about what category is proper for:
- travel_agent - shop, office, both or something different?
- ice_cream - amenity, shop, both or something different?
- golf_course - landuse, man_made, both or something different?
- uncertain trees -> natural (maybe woods), landuse (maybe forest or 
orchard) or something different? [for me area=trees would be nice and 
clear, so some categories may be useful, but a pair trees=yes probably 
has the same meaning]

They were ad-hoc defined and can be overlapping or not relevant for some 
cases. The same problem relates to many objects, but they are not 
considered fixed and compulsive, so we can more easy change them later.

I think some top-level tags that may still be useful in tagging are 
"building", "highway", "area" or "water", because they are really 
generic and visible for the mappers.

However my solution is not lack of any other categories, as you have 
understood it, but rather moving them to the Wiki to make them more 
flexible, extendable and possible to be refined - just like categories 
in Wikipedia. It can be also some other kind of meta-database, but OSM 
Wiki seems to be the most full and coherent documentation we have today 
and it already tries to mimic the categories from the tags 
(RelatedTerms) and other relations (Wikidata links).

> no difference in those cases. But sometimes you want all things in a
> category: e.g. buildings or shops . Dropping the category might not
> make some problems harder to solve than just keeping them.

Flexible categories will also have some quirks - for example we may end 
up with "travel_agent" being in multiple categories (like "shop" and 
"office"). Of course, the philosophical discussion will not stop 
immediately, but:
1) average mapper may stop worry about it and map the ground truth
2) if a better category name is found, we just need to change metadata 
and not deal with massive mechanical edits in the database.

That also means the software will need to decide what to do with 
possible multiple categories, but holding back the system from being 
more clear and flexible just because it's easier to analyze fixed values 
in the data rather than dynamic ones in metadata would be a huge mistake 
for the future. But still we may make the transition easier by creating 
some legacy mappings (I wrote about it here: 
https://lists.openstreetmap.org/pipermail/tagging/2015-May/024650.html 
).

> maybe I just misunderstood what you want to change.

I guess my propositions are too out-of-the-box and abstract (moreover 
they're still developing...) to be taken as they are. =} That's why I 
appreciate the discussion and all - even the most critical - responses. 
Thank you very much for your remarks and questions!

-- 
"The train is always on time / The trick is to be ready to put your bags 
down" [A. Cohen]