[OSM-talk] Planned rendering changes of protected areas

[Yves]

I do agree with Christoph here, tag depreciation should be discussed outside of the scope of osm-carto. 
Daniel, this all thread looks like you want to promote a tagging scheme for the primary reason you can't make it look nice on the slippy map. That's really not helping tagging discussions! 
You should restart this all thread on tagging@ without osm-carto in mind. 
Yves 

Le 3 décembre 2017 04:05:52 GMT+01:00, "Daniel Koć" <daniel at xn--ko-wla.pl> a écrit :
>Thanks for the comments! They help me to get the bigger picture, which 
>is not visible from just the tag names and definitions.
>
>TL;DR summary: I think that for now we should render all the existing 
>tags with osm-carto, but make some of them appear earlier to encourage 
>smooth migration to a more precise scheme.
>
>W dniu 01.12.2017 o 01:55, Martin Koppenhoefer pisze:
>
>> there is no problem with 2 different tags fitting for the same kind
>of 
>> thing. These are also different in scope, leisure=nature_reserve is 
>> for all kind of natural protected areas, while
>boundary=protected_area 
>> is for all kind of protected areas.
>
>My general findings are:
>
>1. As I currently understand it, nature reserve is _always_ a type of 
>protected area, to begin with.
>
>We were talking on osm-carto ticket with some people about private 
>reserves and even when someone told me "it's not about protection!"
>this 
>term was used immediately in the same sentence (or in the next one). =}
>
>I guess they meant "it's voluntary and not formal", but still it's 
>intended as a protection of nature, so it's just a special, weak type
>of 
>protection.
>
>2. The problem seems to be for a mapper to be more precise, since a 
>typical survey can reveal a sign with a name "XYZ nature reserve". 
>However this is not about just a name.
>
>Boundaries are not visible on the ground easily, so a mapper who draw 
>them have to use some other sources and I believe there are more 
>informations available. Otherwise the area shape is probably not 
>verifiable, which would be bad anyway. And I think all of them are 
>areas, not the points (node would mean probably "here is the protection
>
>area, but exact shape is not shown at the moment"), so boundary is also
>
>a sure thing.
>
>3. The name tag leisure=nature_reserve states that it's about leisure 
>(which of course might be for a given object), but it's always about 
>protection. So even if the value have merits, this key assumption is 
>wrong in general and misses more important property 
>(boundary=nature_reserve has only 35 uses).
>
>4. Another problem is lack of coherent definition of protection other 
>than numbers and high-level classes.
>
>The numbers seems to be derived from IUCN scheme ( 
>https://en.wikipedia.org/wiki/IUCN_protected_area_categories ), but 
>wider: only categories 1-6 is IUCN-based and I don't know about the
>rest.
>
>Especially class 7 is interesting for us: "*nature-feature area*: 
>similar to 4. but /without/ IUCN-level.", so i guess it's for all the 
>non-IUCN classified nature reserves. Probably most of the time this 
>should be clear from the boundary shape source.
>
>It would be good to have more standardized subtags for common features:
>- "nature" - protection_object=* is the same mess as numbers, when 
>talking about hierarchy levels, so maybe some subtag like 
>"nature_reserve=yes" would be useful
>- "private" owner type (not the access type) - 
>governance_type=private_landowner would be great (if really used...)
>- "voluntary" - but that might be clear from the lack of government or 
>international authorities influence
>
>What about the solutions?
>
>> My suggestion for osm carto is to look at both tagging schemes for 
>> nature reserves. I wouldn’t drop support for leisure =nature reserve
>
>In summary, we have 3 popular but overlapping types now:
>
>1. leisure=nature_reserve (77 264)
>2. boundary=national_park (16 583)
>3. boundary=protected_area (62 016)
>
>Their general properties and relations:
>
>1. has a wrong key, but nice value name, and is a subtype of 3.
>2. has a nice value name and a proper key, it's also subtype of 3.
>3. is very broad with precise, but not so common name, it also has 
>subtypes, which are useful for official classification, but are not 
>clear for all the other types of conservation
>
>Therefore I would advice to:
>
>1. Discourage leisure=nature_reserve and make it a subtag of 
>boundary=protected_area, like:
>     a) nature_reserve=yes - 2 uses
>     b) protected_area=nature_reserve - 22 uses
>     c) protected_area=nature - 61 uses
>if needed, otherwise just use a protect_class=7 or other class if
>known.
>
>2. Drop boundary=national_park, since it's easy to identify them all
>and 
>they are equivalent for boundary=protected_area + protect_class=2
>anyway.
>
>That's about cleaning the tagging. For rendering I would show all of 
>them as currently, just using different zoom levels, starting from z8 
>currently (this might change in the future, of course):
>- z8+: national parks and wilderness areas (both are big by definition)
>- z9+: important natural protected areas (class 1-6, with hatched 1a 
>probably)
>- z10+: other natural protected areas (class 7, maybe also 12, 14 and
>97-99)
>- z11+: protected areas without class and leisure=nature_reserve
>
>This is just a rough sketch, however it have some nice properties:
>- all the existing schemes are visible (boundary=national_park can be 
>dropped later)
>- more important objects are rendered first
>- less precise tagging is rendered late
>
>Another important factor might be their size (so for example small 
>national parks wouldn't be shown on z8), but it needs a lot of
>worldwide 
>testing.
>
>-- 
>"My method is uncertain/ It's a mess but it's working" [F. Apple]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20171203/d30476d8/attachment.html>