[Tagging] Micro- and macromapping with area=*

Daniel Koć daniel at xn--ko-wla.pl
Mon Mar 30 22:37:16 UTC 2015


W dniu 30.03.2015 22:24, fly napisał(a):

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

You seem to be talking about interpreting data already in the database 
("forest is an area" - of course! =} ), while I'm talking about trying 
to get them into the database ("what kind of area is this?"). There is 
much more things which are not "sure" and "usual", so how should we deal 
with this problem?

> Do not see that much differences to define several cases.

Which differences in cases do you mean? Micro-/macro or just micro- 
cases?

The first one is about extending already existing schemes (micro-), 
while macro- is about building hierarchy which does not exist yet. The 
second (different micro- cases) are obvious for me.

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

Not only highway definition, I'm afraid...

OSM was started as a middle-scale map of a big European city, hence:

1. Highways were meant to be just crossing lines from GPS (=just routing 
and macro-to-middle-scale rendering).

2. Churches were meant to be - well, typical churches (no need to add 
strange tag "amenity=place_of_worship" for "building=church", because 
it's obvious - isn't it?!).

3. Monuments were meant to be just monuments (no scale recognition - 
like building/statue/plate - probably, no monument/memorial dilemma and 
surely historical - no matter if the monument is old or new).

- and many other simple assumptions which may be more or less true for 
London and even European/Western cities, but fail at the global and 
micro scale.

Now OSM is more general and more specific in many ways. We handle those 
specific features to some degree (it works, although it's getting hard 
to manage so many loosely-connected cases), but we're pretty bad in 
terms of generalization and types hierarchy. The worst thing is we don't 
even care for being more consistent and systematic, we just keep digging 
deeper to be more specific...

> 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 stick with whatever once you know for sure what kind of area is 
this and which tagging scheme is proper.

But if I see a grassy area (hence "area=grass") over there or on the 
aerial image, how should I know if it's:
- natural=grass?
- landuse=grass? (is it used?)
- landcover=grass?
- man_made=grass? (maybe it's made of plastic?)

Wiki does not help me, it adds some more hard choices:
- landuse=meadow (what about natural=meadow, landcover=meadow, 
landuse=meadow?)
- natural=grassland (what about landcover=grassland?)

Now I may start to dig into wiki pages to get definitions. I'm lucky if 
I speak English - many of them are not translated to my language and 
probably won't be (and these which are, can be outdated). And that's 
just one place...

Sorry - out of time! Too confusing, too much to check - and it was just 
simple grassy area...

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

Again - I see some area populated with trees. It may be landcover or 
landuse, but surely it is the area.

That's not to say we should drop all the existing namespaces. Maybe they 
can be useful, maybe it's too hard to get rid of the old cruft - it 
doesn't matter; what really matters is we just need some more general 
namespaces. If we know that "area=grass" is used, we can make it 
"landuse=grass" - or maybe just "area=grass + landuse=yes" (why not?!).

-- 
Piaseczno Miasto Wąskotorowe



More information about the Tagging mailing list