Planned rendering changes of protected areas

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Planned rendering changes of protected areas

Christoph Hormann-2
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Planned rendering changes of protected areas

Paul Johnson-3
In reply to this post by Daniel Koć


On Thu, Nov 30, 2017 at 7:46 AM, Daniel Koć <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Planned rendering changes of protected areas

Daniel Koć
In reply to this post by Christoph Hormann-2
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Planned rendering changes of protected areas

Andy Townsend
In reply to this post by Daniel Koć
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Planned rendering changes of protected areas

dieterdreist
In reply to this post by Daniel Koć


sent from a phone

On 30. Nov 2017, at 23:09, Daniel Koć <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Planned rendering changes of protected areas

Paul Johnson-3
In reply to this post by Andy Townsend


On Thu, Nov 30, 2017 at 6:05 PM, [hidden email] <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Planned rendering changes of protected areas

Eugene Alvin Villar
On Fri, Dec 1, 2017 at 8:58 AM, Paul Johnson <[hidden email]> wrote:
On Thu, Nov 30, 2017 at 6:05 PM, [hidden email] <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Planned rendering changes of protected areas

Paul Johnson-3
On Thu, Nov 30, 2017 at 9:38 PM, Eugene Alvin Villar <[hidden email]> wrote:
On Fri, Dec 1, 2017 at 8:58 AM, Paul Johnson <[hidden email]> wrote:
On Thu, Nov 30, 2017 at 6:05 PM, [hidden email] <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Planned rendering changes of protected areas

Andy Townsend
In reply to this post by Daniel Koć
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Planned rendering changes of protected areas

Daniel Koć
In reply to this post by dieterdreist
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]

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Planned rendering changes of protected areas

Christoph Hormann-2
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Planned rendering changes of protected areas

Yves
In reply to this post by Daniel Koć
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ć" <[hidden email]> 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]

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Tagging/rendering relations

Daniel Koć
W dniu 03.12.2017 o 18:43, Yves pisze:
> I do agree with Christoph here, tag depreciation should be discussed
> outside of the scope of osm-carto.

It would be interesting for me to hear the exact reasons why do you
think that?

I would also like to know how do you think should we talk about the
relations between tagging and rendering in an acceptable way?

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

Rendering is my primary motivation to look at these tags and I see
nothing wrong with being open about it. This is one of many rendering
styles and one of many uses of OSM data, and data consuming is also
important thing to consider. Not the most important, but still something
to think about.

When designing tags we think about different problems - if it's easy for
a mapper to tag, if the system is coherent, if the names are clear, so
thinking about classification is equally valid for me - and it's good to
know why the classification might be needed at all. I don't talk about
data analysis, because I don't do that, but I suspect classification
would help that too.

--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Tagging/rendering relations

Yves
Le 3 décembre 2017 19:07:24 GMT+01:00, "Daniel Koć" <[hidden email]> a écrit :

W dniu 03.12.2017 o 18:43, Yves pisze:

I do agree with Christoph here, tag depreciation should be discussed
outside of the scope of osm-carto.


It would be interesting for me to hear the exact reasons why do you
think that?

Because the discussion can be heated by the fear of seeing something 'disappear' from the map overnight.
I don't have a particular idea concerning the orthogonals tags mentioned here. But it seems to me they could be discussed better as tags in a more general way, then the maintainers of osm-carto could propose with their own rendering choice.
Yves

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Tagging/rendering relations

Daniel Koć
W dniu 03.12.2017 o 19:31, Yves pisze:

> Because the discussion can be heated by the fear of seeing something
> 'disappear' from the map overnight.

Well, the fear might be there, but the discussion was already here, it
was not too heated, and that was just my conclusions after the
discussion. I also wrote the clear TL;DR summary that rendering should
for now show everything - and then the criticism hit the list, when
there was not declared to "disappear" anything, let alone over night.

So it has to be something different, I guess, and I still don't know
what is it?

> I don't have a particular idea concerning the orthogonals tags
> mentioned here. But it seems to me they could be discussed better as
> tags in a more general way, then the maintainers of osm-carto could
> propose with their own rendering choice.

That went just like you said: I came with the tagging problem triggered
by designing rendering, we talked about the tagging problems, and I
proposed my choice - one for tagging, the second one for rendering.

However it's not that easy nor productive to make everything separate.
It was parallel discussion in the osm-carto ticket and the arguments
were not heard on the list. Making more threads doesn't help to
understand the problem and it's better to avoid it.

--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Planned rendering changes of protected areas

Greg Troxel-2
In reply to this post by Christoph Hormann-2

Christoph Hormann <[hidden email]> 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.

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk

signature.asc (167 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Planned rendering changes of protected areas

Greg Troxel-2

Daniel Koć <[hidden email]> 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.

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk

signature.asc (167 bytes) Download Attachment
12