[Tagging] Micro- and macromapping with area=*

fly lowflight66 at googlemail.com
Mon Mar 30 20:24:28 UTC 2015


Am 30.03.2015 um 17:02 schrieb Daniel Koć:

In general area=yes/no is broken. Usually, there should not be a problem
to get the information from the object (type).

With some tags which are valid for closed (area) and unclosed ways we
have problems and the best we can do, is to define one solution as
default and mark the opposite with an additional tag (area=yes/no).

> Lately I was trying to rethink our general tagging schemes and came up
> with the impression that areas half-designed part of OSM tagging system.
> 
> IMO we have 2 problems with it: small one in microscale and a big one in
> macroscale, but most probably we can deal with them separately.

Do not see that much differences to define several cases.

> ***
> 
> In microscale we have some common uses of area=yes tag as area hint,
> like with highway=footway, highway=pedestrian or highway=service. But I
> think we also need some other like (a) highway=cycleway + area=yes or
> (b) highway=crossing + area=yes (both are quite easy to extend) and more
> complicated, but highly needed (c) street area scheme like in
> http://wiki.openstreetmap.org/wiki/Proposed_features/Street_area .
> 
> We won't see the issue just looking at the taginfo usage statistics:
> 
> http://taginfo.openstreetmap.org/tags/area=yes#combinations
> 
> but it's easy to understand there's something wrong with having some
> popular area types being tagged and rendered as such, while some other
> are still considered just a point or a line. And it's not the future,
> it's already here at z19 (z18 is still rather fine) - for example some
> streets can be even 4 times wider than on default rendering (see the
> holes between footways and the streets at
> http://www.openstreetmap.org/#map=19/52.23171/21.02082 )!

Right the definition of highway is a complete mess. Would be much more
consistent to use area:highway=* for all areas and to render highway=*
only as lines with width=* or a default width.

> ***
> 
> Macroscale is harder, because general hierarchy of tags is treated as
> given and I think we need to fix this hierarchy a bit. The problem is
> best visible when compared to buildings and I already wrote about it on
> Talk list, so let me quote relevant parts:
> 
> "That's what we have now (forgetting the buildings functions issue for a
> moment):

No, your definition is wrong, please, do not publish this as it does not
help to get the right definition in users' heads and it will not help
our problem as talking about broken examples is a fail.

> 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?"

We do not need the definition of area in a tag, see above. It does not
give any extra information.

Additional, we do not always need landuse=* to define an area, so I
rather stick with amenity/man_made/natural/place_of_worship.

> "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.

Once again, we do not need to define that it is an area as the object
already includes the information.

wood vs forest is an topic on its own and how about landcover=* ?

We have some problematic tags beyond highway=* like barrier=*wall where
we might still need area=* but this should be only a handful of tags.

Cheers fly



More information about the Tagging mailing list