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