[OSM-talk] "Second decade" visions

Daniel Koć daniel at xn--ko-wla.pl
Sat Mar 14 02:54:34 UTC 2015


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



More information about the talk mailing list