Re: [OSM-talk] Planned rendering changes of protected areas

[Martin Koppenhoefer]

2017-12-03 4:05 GMT+01:00 Daniel Koć :

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


the protected area tag definition implies governmental protection, e.g.
there's the sentence: "If there are no results, ask the appropriate
(government) administration". It is unfortunate and must not remain like
this, but it is the current state.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Planned rendering changes of protected areas

[Daniel Koć]

W dniu 11.12.2017 o 14:43, Greg Troxel pisze:


The property that is denoted by leisure=nature_reserve is mostly
separate from the protected area information.  It means that humans are
able to hike in a land wich is in a natural state.


In the meantime I've made a reality check with Poland lately and now I 
think that local conventions could not be simply translated into 
protection class, so I agree that they are separate probably. For 
example most of national parks in Poland are IUCN class 2, but two of 
them are class 5. See my current report:


https://github.com/gravitystorm/openstreetmap-carto/issues/603#issuecomment-350587768

So now I would not advocate for deprecating "nature_reserve", as this is 
local specific type/name of protected areas. What I still think is 
wrong, is the key "leisure=". I think "boundary=protected_area + 
protected_area=nature_reserve" would be better (we already use such 
scheme for amenity=social_facility for example).



You're basically saying "I care about X, and you care about Y, and my
caring about X is more important, so you are wrong."


I care for proper naming and clear database scheme, not for any 
particular features. Leisure is just a popular activity related to many 
nature reserves, but not for all - think of strict reserves. But all of 
them are meant for nature protection, by design.



That's one person's opinion about some things.  The real world is
complicated and "protected" is very complicated.Certainly around me
there are "wildlife refuges" that allow deer hunting (to protect plants
and toher animals from deer!).


Yes, you are right that there are many views on how the protection is 
implemented. However "protection" is an umbrella term that binds all of 
the nature reserves (including "hunting allowed", "leisure allowed" or 
"voluntary protection"), but "leisure" does not include all of nature 
reserves.



What I don't understand is why you dislike leisure=nature_reserve so
much.  If you want to have boundary=protected_area control the rendering
if both are set, whatever.  But there seems to be some notion that
poeople using that tag causes you trouble, and that you have some basis
to demand that they stop.


Of course I have some trouble, otherwise I wouldn't notice. But that was 
just a trigger to see the real tagging problem, which is bigger than 
just rendering. As I understand you, what you think is "any tag you 
like" is the only policy that really counts, no matter if the scheme is 
precise, coherent and has at least basic classification.


For example I think that:

boundary = protected_area
+ protected_area = nature_reserve/national park/landscape reserve/...
+ protect_class = n

is better than:

leisure = nature_reserve
boundary = national park
boundary = protected_area + protect_class = n

The first one allows to add many properties in a reach and structured 
way, while the second:

- has no hierarchy
- implies "leisure" for every nature reserve
- does not allow to use boundary=national park + 
boundary=protected_area, because they share the same key


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

Re: [OSM-talk] Planned rendering changes of protected areas

[Greg Troxel]

Daniel Koć  writes:

> W dniu 07.12.2017 o 17:04, Greg Troxel pisze:
>> I also object to deprecating leisure=nature_reserve.  The protected_area
>> scheme is too complicated for most people to deal with fully and
>> leisure=nature_reserve has proved itself to be useful.
>
> This way or another it seems to me that leisure= key is wrong and
> using boundary=protected_area (or even just boundary=) is proper.

The property that is denoted by leisure=nature_reserve is mostly
separate from the protected area information.  It means that humans are
able to hike in a land wich is in a natural state.

> Leisure is just a common, but not the inherent property of nature
> reserve - the protection is:

You're basically saying "I care about X, and you care about Y, and my
caring about X is more important, so you are wrong."

I'm not arguing that boundary=protected_area be deprecated or removed.
Just that the existtence of boundary=protected_area does not make
leisure=nature_reserve pointless.

> "Usage of a leisure key, actually, might contradict a protection
> status in a lot of cases, where nature reserve doesn't allow any
> leisure activities. Ownership and enforcement are totally different
> things from protection level. For example, in Russian Federation,
> there are huge state-owned protected areas with limited access
> intended for hunting. They have strict protection enforcement and they
> usually are equal to class 4 or 6. Private hunting lands with similar
> access restriction, management level, and enforcement exist in other
> countries. Someone might argue that if hunting is allowed, it is not a
> protection, but that's just a personal idea of protection."

That's one person's opinion about some things.  The real world is
complicated and "protected" is very complicated.Certainly around me
there are "wildlife refuges" that allow deer hunting (to protect plants
and toher animals from deer!).



What I don't understand is why you dislike leisure=nature_reserve so
much.  If you want to have boundary=protected_area control the rendering
if both are set, whatever.  But there seems to be some notion that
poeople using that tag causes you trouble, and that you have some basis
to demand that they stop.


signature.asc
Description: PGP signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Planned rendering changes of protected areas

[Daniel Koć]

W dniu 07.12.2017 o 17:04, Greg Troxel pisze:

I also object to deprecating leisure=nature_reserve.  The protected_area
scheme is too complicated for most people to deal with fully and
leisure=nature_reserve has proved itself to be useful.


This way or another it seems to me that leisure= key is wrong and using 
boundary=protected_area (or even just boundary=) is proper.


Leisure is just a common, but not the inherent property of nature 
reserve - the protection is:


"Usage of a leisure key, actually, might contradict a protection status 
in a lot of cases, where nature reserve doesn't allow any leisure 
activities. Ownership and enforcement are totally different things from 
protection level. For example, in Russian Federation, there are huge 
state-owned protected areas with limited access intended for hunting. 
They have strict protection enforcement and they usually are equal to 
class 4 or 6. Private hunting lands with similar access restriction, 
management level, and enforcement exist in other countries. Someone 
might argue that if hunting is allowed, it is not a protection, but 
that's just a personal idea of protection."


[ http://www.openstreetmap.org/user/kocio/diary/42861#comment40293 ]


Agreed.   To me, the real rendering issue si the lack of showing
protected area, and the tendency to show these features by an edge
marking rather than some kind of fill.


There are some tricks to make rendering better and I'm gonna try them, 
but lack of classification of nature reserves is a bigger problem than 
just rendering on osm-carto.


We also use a workaround for airports and it works, but using hacks at 
all means that there is a deeper problem.


With rivers we don't even have a hack and this is the same problem with 
lack of classification for very popular kind of objects.


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

Re: [OSM-talk] Planned rendering changes of protected areas

[Greg Troxel]

Christoph Hormann  writes:

> On Thursday 30 November 2017, Daniel Koc4‡ wrote:
>>
>> I'm thinking about changes in rendering of protected areas on
>> osm-carto and I wanted to give community a hint, because it's a
>> popular kind of objects.
>
>> 1. Currently leisure=nature_reserve (old scheme) and boundary=* (new
>> scheme) are frequently tagged in parallel, and it looks like the old
>> scheme is used as a hack just to make it visible on default map.
>
> Presenting leisure=nature_reserve as an 'old scheme' and 'boundary=*' as 
> a 'new scheme' is a serious mischaracterization.  The tags 
> leisure=nature_reserve, boundary=protected_area and 
> boundary=national_park all started being used around the same time.  
> There is no old and new here.
>
> 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.

I also object to deprecating leisure=nature_reserve.  The protected_area
scheme is too complicated for most people to deal with fully and
leisure=nature_reserve has proved itself to be useful.

>> 2. The old scheme is too generic and it causes visual clutter,
>> because all of the protected areas are displayed at once.
>
> 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.

Agreed.   To me, the real rendering issue si the lack of showing
protected area, and the tendency to show these features by an edge
marking rather than some kind of fill.

>> 3. New scheme has many classes defined, which would allow us to fine
>> tune the rendering (different zoom levels and only some of them).
>
> 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.

Agreed.


signature.asc
Description: PGP signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [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ć"  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 

Re: [OSM-talk] Planned rendering changes of protected areas

[Daniel Koć]

W dniu 03.12.2017 o 11:06, Christoph Hormann pisze:


As said before: *do not mix rendering and tagging discussions*.


I don't fully understand what you're suggesting (it's a long, complex 
sentence), but I feel you're  accusing me of something bad. Please note 
that the first point about general osm-carto purpose in the link you 
gave is clear about the link between rendering and tagging:


"It's an important feedback mechanism for mappers to validate their 
edits and helps to prevent unfavorable fragmentation of tag use."


[ 
https://github.com/gravitystorm/openstreetmap-carto/blob/master/CARTOGRAPHY.md#general-purpose 
]


I'm talking about them on their own merits, because they are autonomous 
parts of OSM "ecosystem", but that doesn't mean they are not connected 
in any way, so I talk about these links too.


It's a simple observation: tagging limits and shapes what we render, 
rendering have an influence on the way we use tags. It's better to be 
aware of it to mitigate "tagging for rendering" (which means *tagging 
the wrong way* just to see something, not the feedback loop!) for example.


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

Re: [OSM-talk] Planned rendering changes of protected areas

[Christoph Hormann]

On Sunday 03 December 2017, Daniel Koc4� wrote:
>
> 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.

You are clearly out of line here - the suggestion that the standard 
style might be entitled to steer the mappers to use a different tagging 
because it is deemed more desirable by you is presumptuous and in clear 
violation of the existing design principles of the style[1].  It is a 
clear case of the tail wagging the dog.

If you want to render/not render certain tags for cartographic reasons 
that is completely up to you.  If you want to point out that 
documentation for certain tags is lacking that is most welcome.  
Likewise if you want to create a proposal to deprecate certain tags and 
replace them by others.  But creating little argument buildings 
attempting to prove certain tags are bad and others are good for the 
sole purpose of justifying rendering decisions that are based on 
wishful thinking that the mappers will adjust to the desires and needs 
of your style to make it work is not acceptable.  Don't do that.

As said before: *do not mix rendering and tagging discussions*.

[1]https://github.com/gravitystorm/openstreetmap-carto/blob/master/CARTOGRAPHY.md

-- 
Christoph Hormann
http://www.imagico.de/

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Planned rendering changes of protected areas

[Daniel Koć]

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 

Re: [OSM-talk] Planned rendering changes of protected areas

[Andy Townsend]

On 30/11/17 13:46, Daniel Koć wrote:

Hi,

I'm thinking about changes in rendering of protected areas on 
osm-carto and I wanted to give community a hint, because it's a 
popular kind of objects. There is a fresh discussion about it from 
this comment on:


https://github.com/gravitystorm/openstreetmap-carto/issues/603#issuecomment-347879897 



In short:

1. Currently leisure=nature_reserve (old scheme) and boundary=* (new 
scheme) are frequently tagged in parallel, and it looks like the old 
scheme is used as a hack just to make it visible on default map.


(snipped)

Actually one more thing (prompted by SK53 on IRC) - the area of a nature 
reserve is sometimes != the protected area, as noted here:


https://github.com/gravitystorm/openstreetmap-carto/issues/603#issuecomment-348480276

I can think of a few examples locally - one for example is signed as an 
SSSI* but not a nature reserve:


http://www.openstreetmap.org/way/53745064/history

also apparently the "reserve" area at Muston 
http://www.openstreetmap.org/#map=15/52.9219/-0.7766 doesn't match the 
protected area.


Obviously this is orthoganal to what gets rendered and what doesn't, but 
there's certainly a case for using both tags.


Best Regards,
Andy


* Site of Special Scientific Interest.  Probably maps onto a 
"protect_class" or something.



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Planned rendering changes of protected areas

[Paul Johnson]

On Thu, Nov 30, 2017 at 9:38 PM, Eugene Alvin Villar 
wrote:

> On Fri, Dec 1, 2017 at 8:58 AM, Paul Johnson  wrote:
>
>> On Thu, Nov 30, 2017 at 6:05 PM, ajt1...@gmail.com 
>> wrote:
>>
>>> On 30/11/2017 13:46, Daniel Koć wrote:
>>>
 1. Currently leisure=nature_reserve (old scheme) and boundary=* (new
 scheme) are frequently tagged in parallel, and it looks like the old scheme
 is used as a hack just to make it visible on default map.

>>>
>>> Just to chuck one example in - I've tagged lots of
>>> "leisure=nature_reserve" and almost no "boundary=protected_area;
>>> protect_class=XYZ".  The reason is simple - nature reserves where I'm
>>> likely to be mapping often have a sign saying "XYZ nature reserve".  There
>>> isn't going to be a sign helping me work out what "protect_class" in OSM it
>>> is, so that doesn't get mapped.  It's also nothing to do with "what gets
>>> rendered"; I actually render my own maps and map quite a lot of stuff that
>>> isn't displayed there :)
>>>
>>
>> Seems like it wouldn't be too difficult to consider the two as equivalent.
>>
>
> Not exactly. Some protected areas are cultural/social/heritage protected
> areas. Specifically those tagged with protect_class=21 to 29.
>

I meant the specific protect_class tags referring to nature preserves
specifically.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Planned rendering changes of protected areas

[Eugene Alvin Villar]

On Fri, Dec 1, 2017 at 8:58 AM, Paul Johnson  wrote:

> On Thu, Nov 30, 2017 at 6:05 PM, ajt1...@gmail.com 
> wrote:
>
>> On 30/11/2017 13:46, Daniel Koć wrote:
>>
>>> 1. Currently leisure=nature_reserve (old scheme) and boundary=* (new
>>> scheme) are frequently tagged in parallel, and it looks like the old scheme
>>> is used as a hack just to make it visible on default map.
>>>
>>
>> Just to chuck one example in - I've tagged lots of
>> "leisure=nature_reserve" and almost no "boundary=protected_area;
>> protect_class=XYZ".  The reason is simple - nature reserves where I'm
>> likely to be mapping often have a sign saying "XYZ nature reserve".  There
>> isn't going to be a sign helping me work out what "protect_class" in OSM it
>> is, so that doesn't get mapped.  It's also nothing to do with "what gets
>> rendered"; I actually render my own maps and map quite a lot of stuff that
>> isn't displayed there :)
>>
>
> Seems like it wouldn't be too difficult to consider the two as equivalent.
>

Not exactly. Some protected areas are cultural/social/heritage protected
areas. Specifically those tagged with protect_class=21 to 29.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Planned rendering changes of protected areas

[Paul Johnson]

On Thu, Nov 30, 2017 at 6:05 PM, ajt1...@gmail.com 
wrote:

> On 30/11/2017 13:46, Daniel Koć wrote:
>
>> 1. Currently leisure=nature_reserve (old scheme) and boundary=* (new
>> scheme) are frequently tagged in parallel, and it looks like the old scheme
>> is used as a hack just to make it visible on default map.
>>
>
> Just to chuck one example in - I've tagged lots of
> "leisure=nature_reserve" and almost no "boundary=protected_area;
> protect_class=XYZ".  The reason is simple - nature reserves where I'm
> likely to be mapping often have a sign saying "XYZ nature reserve".  There
> isn't going to be a sign helping me work out what "protect_class" in OSM it
> is, so that doesn't get mapped.  It's also nothing to do with "what gets
> rendered"; I actually render my own maps and map quite a lot of stuff that
> isn't displayed there :)
>

Seems like it wouldn't be too difficult to consider the two as equivalent.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Planned rendering changes of protected areas

[Martin Koppenhoefer]

sent from a phone

On 30. Nov 2017, at 23:09, Daniel Koć  wrote:

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


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. It appears to be very detailed at first glance, but if you 
look at the actual tagging almost one third misses the most basic information 
(protect_class) and the long list of additional tags suggested in the wiki 
contains some questionable items and instructions. E.g. protection_aim, 
protection_ban and protection_instructions don’t seem to be suitable for a tag 
value, even more as it is not documented how to apply them.
E.g. protection_object: the wiki says it should describe what is protected (but 
not in detail, says again the wiki: “Preferably don´t list species or elements 
- therefor you should give a website-url.”), in actual values “recreation” is 
leading, second is “timber”: 
https://taginfo.openstreetmap.org/keys/protection_object#values
valid_from is a rarely used duplicate of start_date, etc.

My suggestion for osm carto is to look at both tagging schemes for nature 
reserves. I wouldn’t drop support for leisure =nature reserve 


cheers,
Martin ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Planned rendering changes of protected areas

[ajt1...@gmail.com]

On 30/11/2017 13:46, Daniel Koć wrote:
1. Currently leisure=nature_reserve (old scheme) and boundary=* (new 
scheme) are frequently tagged in parallel, and it looks like the old 
scheme is used as a hack just to make it visible on default map.


Just to chuck one example in - I've tagged lots of 
"leisure=nature_reserve" and almost no "boundary=protected_area; 
protect_class=XYZ".  The reason is simple - nature reserves where I'm 
likely to be mapping often have a sign saying "XYZ nature reserve".  
There isn't going to be a sign helping me work out what "protect_class" 
in OSM it is, so that doesn't get mapped.  It's also nothing to do with 
"what gets rendered"; I actually render my own maps and map quite a lot 
of stuff that isn't displayed there :)


Best Regards,

Andy




___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Planned rendering changes of protected areas

[Daniel Koć]

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

Re: [OSM-talk] Planned rendering changes of protected areas

[Paul Johnson]

On Thu, Nov 30, 2017 at 7:46 AM, Daniel Koć  wrote:

> Hi,
>
> I'm thinking about changes in rendering of protected areas on osm-carto
> and I wanted to give community a hint, because it's a popular kind of
> objects. There is a fresh discussion about it from this comment on:
>
> https://github.com/gravitystorm/openstreetmap-carto/issues/
> 603#issuecomment-347879897
>
> In short:
>
> 1. Currently leisure=nature_reserve (old scheme) and boundary=* (new
> scheme) are frequently tagged in parallel, and it looks like the old scheme
> is used as a hack just to make it visible on default map.
>
> 2. The old scheme is too generic and it causes visual clutter, because all
> of the protected areas are displayed at once.
>
> 3. New scheme has many classes defined, which would allow us to fine tune
> the rendering (different zoom levels and only some of them).
>
> 4. The new scheme looks like more general than the old one, so it's all
> that's we really need.
>
> Therefore I think rendering of leisure=nature_reserve should be dropped on
> osm-carto, so boundary=* would take over. In this case the areas should be
> tagged with a new scheme to be visible there. That might lead to
> deprecation of leisure=nature_reserve in the future.


 I'm OK with this.  I wouldn't mind some kind of subtle fill where
appropriate.  Class 24 areas probably should render something closer to
administrative boundaries currently do.  Any hatch in that case would need
to be insanely subtle in order to not overwhelm other areas that have
hatches or it'd just make a real mess of things in the western US
(especially in my area where it's a 2-3 hour drive in the shortest
direction to leave such a region).
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Planned rendering changes of protected areas

[Christoph Hormann]

On Thursday 30 November 2017, Daniel Koc4� wrote:
>
> I'm thinking about changes in rendering of protected areas on
> osm-carto and I wanted to give community a hint, because it's a
> popular kind of objects.

I have no definitive opinion on the tagging question but i consider your 
approach here highly questionable.  More details on that in the 
following.

> 1. Currently leisure=nature_reserve (old scheme) and boundary=* (new
> scheme) are frequently tagged in parallel, and it looks like the old
> scheme is used as a hack just to make it visible on default map.

Presenting leisure=nature_reserve as an 'old scheme' and 'boundary=*' as 
a 'new scheme' is a serious mischaracterization.  The tags 
leisure=nature_reserve, boundary=protected_area and 
boundary=national_park all started being used around the same time.  
There is no old and new here.

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.

> 2. The old scheme is too generic and it causes visual clutter,
> because all of the protected areas are displayed at once.

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.

> 3. New scheme has many classes defined, which would allow us to fine
> tune the rendering (different zoom levels and only some of them).

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.

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

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?

On a general note: Please do not mix tagging discussions and rendering 
discussions - that is a recipe for desaster.  If rendering 
considerations lead you to realize tagging issues and you want to 
discuss those that is fine 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.

-- 
Christoph Hormann
http://www.imagico.de/

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Planned rendering changes of protected areas

[Daniel Koć]

Hi,

I'm thinking about changes in rendering of protected areas on osm-carto 
and I wanted to give community a hint, because it's a popular kind of 
objects. There is a fresh discussion about it from this comment on:


https://github.com/gravitystorm/openstreetmap-carto/issues/603#issuecomment-347879897

In short:

1. Currently leisure=nature_reserve (old scheme) and boundary=* (new 
scheme) are frequently tagged in parallel, and it looks like the old 
scheme is used as a hack just to make it visible on default map.


2. The old scheme is too generic and it causes visual clutter, because 
all of the protected areas are displayed at once.


3. New scheme has many classes defined, which would allow us to fine 
tune the rendering (different zoom levels and only some of them).


4. The new scheme looks like more general than the old one, so it's all 
that's we really need.


Therefore I think rendering of leisure=nature_reserve should be dropped 
on osm-carto, so boundary=* would take over. In this case the areas 
should be tagged with a new scheme to be visible there. That might lead 
to deprecation of leisure=nature_reserve in the future.


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