[Tagging] Micro- and macromapping with area=*

[Mateusz Konieczny]

Mapping street areas should not use [highway=*; area=yes] -
[area:highway=*] is much better.

highway=pedestrian, highway=footway for squares are special cases as square
may and typically is traversed using any route.
Also some [highway=service; area=yes] fit (some parkings and similar
places) as it is OK to drive in any direction.

That is not a case for highway=motorway/.../tertiary/.../cycleway/.. (at
least normal ones, there are probably some weird places).


2015-03-30 17:02 GMT+02:00 Daniel Koć <daniel at koć.pl>:

> 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.
>
> ***
>
> 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 )!
>
> ***
>
> 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):
>
> 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?"
>
> "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 )."
>
> [ https://lists.openstreetmap.org/pipermail/talk/2015-March/072375.html ]
>
> ***
>
> What do you think about both micro- and macroscale changes in scope of
> areas?
>
> --
> Piaseczno Miasto Wąskotorowe
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20150330/7985abdc/attachment.html>