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
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
