W dniu 30.11.2017 o 17:38, Christoph Hormann pisze:
There are 62k uses of boundary=protected_area and 77k of
leisure=nature_reserve and 31k of the combination - which does not
really support your idea that the latter is used just as a hack.
How would you detect such a hack then?
In my opinion 31k is a serious amount (about a half of both) that is a
strong suggestion of the problem, at least.
That is frankly just nonsense. If rendering (or not rendering) features
with leisure=nature_reserve, boundary=protected_area or
boundary=national_park causes visual clutter in a map depends on if and
how you render these features. That is the responsibility of you as a
map designer. Blaming a tagging scheme for not being able to do that
without visual clutter is a bit strange.
It's easy - with leisure=nature_reserve you don't have any
classification system, so you have less tools to make a proper rendering
decisions. The other solution is guessing or accepting the mess, which
are poor options for me.
Have you looked at if these classes are actually used consistently at
the moment? A tagging scheme with ~25 numerical codes as classes with
fairly brief and abstract descriptions is not usually destined for
success in OSM.
We don't need to check every single one of them, probably just selecting
a nature related subset of them would be enough. Not everything should
be rendered (like "community life" or "earth-moving area") and even just
selecting national parks from the rest would be clear win for a start.
4. The new scheme looks like more general than the old one, so it's
all that's we really need.
Which is just another way of saying boundary=protected_area is much less
meaningful than leisure=nature_reserve since the latter at least
specifies it is nature protection while the former does not.
Just look at the classification, there's a cluster of such classes:
https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area#Nature-protected-area
You are also contradicting yourself here - in 2. you say "the old scheme
is too generic" and here you say "the new scheme looks like more
general" - which is it?
By "generic" I mean "lacking details", which is bad.
By "general" I mean "encompassing all of this and more", which is good.
but then drop arguing for certain tagging
ideas based on your perceived needs for rendering. Tagging decisions
should be based on how mappers can best document their knowledge about
the geography. Not on what some developers find convenient for
rendering.
In my opinion there's a better tagging scheme for documenting that
knowledge, that's why I suggested deprecation. But that is just the
opening of discussion, not the final solution.
--
"My method is uncertain/ It's a mess but it's working" [F. Apple]
_______________________________________________
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
