W dniu 13.03.2015 13:03, Martin Koppenhoefer napisał(a):

indeed, man_made=works is working the same way as amenity=school, it
is used on the whole area, and also place_of_worship is used on the
whole sacred area (which typically coincides with the church).

That's what we have now (forgetting the buildings functions issue for a moment):

amenity=school & building=school
landuse=religious & building=church
landuse=industrial/man_made=works & building=industrial (?)

and I see the pattern like this:

area=school & building=school
area=religious & building=church
area=industrial/works & building=works

Just "area" instead of "amenity/landuse/man_made/..." hell - isn't it easier and more elegant? And that's only plain namespace cleaning, without going into basic blocks I wrote yesterday (like probably school -> "education + children_facility") and maybe dropping k=v scheme.

Please note that above rough tagging scheme is reusing existing key/value names as if we've created the system from scratch, to better illustrate the idea. In practice any system transition should respect current uses and avoid reusing names to not cause confusion.

for me the logic is simple: use the tag on the whole area to which it
applies.

But it's not that simple to know what tag should it be.

we actually do this. We have tags for buildings, that are just about
buildings, and we have tags for functions, that can be inside
buildings, or outside, or both, etc. and we have attributes, which can
be added to those objects to further describe them.

And that's great - at least buildings are coherent and allows being general when needed! You can spot a building and you know what the rules are:

1. The key will be always "building" - not anything else (like "house" or "architecture"). 2. If you don't know anything more about it, "yes" is safe, general value you can always choose (and if you know the form, you are welcome to choose something specific).

What if we could have the same level of clearness for areas? For example natural=wood vs landuse=forest - you see the area covered with trees and:

1. You are not sure what the key should be (is it maintained or not?).
2. You have no safe general value, because "wood" implies "natural" key - but again: you may not know if it's really not maintained.

"Area=trees" might be the kind of close analogy to "building=yes" in such cases. BTW: it's still available ( http://taginfo.openstreetmap.org/keys/area#values ) and such use isn't even disallowed in the light of our current documentation ( http://wiki.openstreetmap.org/wiki/Key:area ). What's holding us back?

or highway=road (wouldn't suggest the tag service=food, as service is
used for service roads).

The same as I stated above - I know what "area" and "service" tags mean currently, but these names are accidentally the best tools I would use to describe real objects. I try to show how one could think outside the box we have.

you shouldn't "subtract" IMHO, because this will become impossible to
parse. This sounds like amenity=drinking_water, drinkable=no to me, or

Here we agree at last. =} But in my scheme it would be easy to tag "water + drinkable/drinkable=yes", "water + not_drinkable/drinkable=no" or even just "water" if you are not sure - three cases instead of just one which indeed is not extendable.

That's probably because we started from handy collection of simple, medium-scale objects and grow much more since then. I admit, that set was very common sense and we made a lot of careful patching and extending of it, so hats off - it's still usable, but we start to hit the wall:

1. The collection is long, hard to remember and navigate (not handy anymore). 2. Some "simple" objects appear to be complex in fact - they can have different form and function (hence 2a. "building=church + tourism=museum") or even more than one function (2b. "shop=fashion + shop=jewelry"?...). 3. Streets are just lines with no width (or have predefined width on rendering according to this street's type) - but it's simply false once we have better zooming capabilities (so we have not only tagging problem in the micro scale). 4. There are many differences in the world comparing to the streets of London (so the large scale bites us too, including plain colonialism reminiscences!).

Solutions I see:
4. must be still patched and extended, I guess (but as a European I'm not disturbed too much by this, so I don't really know). 3. is rather easy (we can just add street areas - see http://wiki.openstreetmap.org/wiki/Proposed_features/Street_area ). 2. is harder (2a. was subtle meaning shift because building=church was probably considered something more than just architectural form for a long time; 2b. is apparently technical problem with k=v model)
1. at least partial redesigning is needed (no easy solutions here).

You are trying to reinvent a language, but I think you miss an
important fact: language only works with context (also very important:
order and grammar, subject predicate object etc.) - even if you
understand every single word of someone speaking in a foreign language
with a different cultural background (or maybe in an antique text),
you will not understand the meaning of the text. For example ancient

Of course, you're right! And I love cultural anthropology (I have studied it once). =}

But that's exactly the problem 4. I mentioned: we have to deal with too many hidden assumptions (and even en_GB/US/* subtleties...), not too few! No artificial language/code will carry all the shades of meaning, but we use it when we want to say something which can be understood universally - and that's really the case when talking about world mapping project, isn't it?

If it was just tagging, scheme like "amenity=school" could be any kind of school - but we decided it should describe a very specific kind of school (children only, not driving etc.), so we write it down on Wiki. How is it better than "education + children_facility" then? It is more precise in itself, yet gives us more flexibility, while we still can give this special combination the same meaning we do now, so we can make the transition very smooth (1:1).

Would you still have anything against it? And what would it be?

included in "everybody"? ;-). If tags become universally usable and
derive their meaning from other tags, they will loose their meaning at
all (IMHO) and we will end up in a big mess.

IMO we are in a big tagging mess now and it's slowly getting worse.

yes, sometimes (in quite rare occassions) our "top level" tags are
indeed very specific, and would benefit from more hierarchy (more
generic top level tag, with one level subtag)

I would say - many times (see all the "area=*" examples).

--
Piaseczno Miasto Wąskotorowe

_______________________________________________
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Reply via email to