Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add rendering for boundary=protected_area #603

Closed
daganzdaanda opened this issue Jun 4, 2014 · 102 comments

Comments

@daganzdaanda
Copy link

commented Jun 4, 2014

After #563 is sorted, maybe we can have a look at http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area and the values of protect_class there.
If I understand correctly, these aren't rendered at all at the moment. But the tag is used, and sometimes replaces the less specific leisure=nature_reserve.

@matthijsmelissen

This comment has been minimized.

@dieterdreist

This comment has been minimized.

Copy link

commented Jun 5, 2014

This classification system also has the advantage of specifying the
level/importance of protection (e.g. regional, national) so we can choose
more easily the appropriate zoom level to show these.

Requires to take a look at key "protect_class" at the same time, to choose
appropriate colours, because this is not only for nature protection but
also for cultural protection (e.g. historic monuments).

@astoff

This comment has been minimized.

Copy link

commented Jun 10, 2014

Here are some thoughts about rendering protected areas.

Compatibility with existing data

Because most applications, and in particular renderers, do not yet recognize the tag boundary=protected_area, there are not many objects using this tag (at least in Brazil). However, there are quite a few areas tagged with the combination boundary=national_park, leisure=nature_reserve, protect_class=*, plus other ancillary tags defined in the protected_area wiki page. Example: https://www.openstreetmap.org/relation/3425868. It would be important that the renderer treats this case correctly

Levels of protection

As @dieterdreist mentioned, the value of the tag protect_class key can be used to determine the "importance" of the corresponding area. In the case of nature reserves, the simplest distinction to make is between "integral protection" and "sustainable use" areas. The former can be rendered in a more prominent way. At least in Brazil, integral protection areas are those with protect_class between 1 and 3, and sustainable use areas are those with protect_class between 4 and 6.

I also wanted to remark that there are some vast, but somewhat lax kinds of protected areas, which sometimes include whole towns inside them (in Brazil, they always have protect_class=5). Example: http://www.openstreetmap.org/relation/3426617. It might be a little challenging to find an appropriate way to render those.

I like this idea: #563 (comment).

Indigenous lands

Besides rendering areas with protect_class ranging from 1 to 7 (which correspond to nature reserves of various kinds), it would be nice to render areas with protect_class=24 (indigenous areas and the like). This could be done in a style similar to nature reserves, but with a different color. Here is an example of a region containing several such areas: https://www.openstreetmap.org/#map=8/-6.932/-54.009.

@matkoniecz

This comment has been minimized.

Copy link
Collaborator

commented Jul 1, 2014

Following, as I've been using this key quite a bit.

You can use "Notifications" settings (in sidebar on the right, under labels) to follow/ignore single ticket.

@matthijsmelissen matthijsmelissen added this to the New features milestone Aug 18, 2014
@matthijsmelissen matthijsmelissen changed the title boundary=protected_area is not rendered Add rendering for boundary=protected_area Sep 24, 2014
@olegseliverstov

This comment has been minimized.

Copy link

commented Oct 7, 2014

@pnorman

This comment has been minimized.

Copy link
Collaborator

commented Oct 7, 2014

Seems to overlap with existing established tags. What types of protected areas are there that are not covered by the tags already rendered?

@daganzdaanda

This comment has been minimized.

Copy link
Author

commented Oct 7, 2014

There is some overlap, especially with leisure=nature_reserve and boundary=national_park. But this scheme is a lot better, IMHO it should be encouraged by rendering.

I would give all the Nature-protected-areas (protect_class=1-7|97-99) a fat green border and a label based on the area size. It might be sensible to make some class(es) more prominent, that could be done with a full colour fill or a even thicker border.

I've no idea how common resources-protected-areas (protect_class=11-19) are, and if they are mapped a lot. I would still give them an outline, maybe thinner than the first group, or another colour. If these get mapped to much and interfere with the general readability, we could remove the rendering again.

Social-protected-areas (21-29) are also worth rendering, especially 24. Maybe a thick yellow border? Class 25 is military, we got that covered already.

I believe that an area can have more than one class associated, so we should think about what to do with lists like protect_class=5;12

@pnorman

This comment has been minimized.

Copy link
Collaborator

commented Oct 7, 2014

There is some overlap, especially with leisure=nature_reserve and boundary=national_park. But this scheme is a lot better, IMHO it should be encouraged by rendering.

Where there is an adequate existing tagging scheme, we don't particularly want to encourage a new incompatible one, as it makes it harder for all data consumers.

Social-protected-areas (21-29) are also worth rendering, especially 24. Maybe a thick yellow border? Class 25 is military, we got that covered already.

Aboriginal lands have existing tagging, generally boundary=aboriginal_lands

@matkoniecz matkoniecz modified the milestones: 3.x - Needs upgrade to mapnik or openstreetmap-carto.style, New features Oct 7, 2014
@matkoniecz

This comment has been minimized.

Copy link
Collaborator

commented Oct 7, 2014

protect_class is not in the database.

@matthijsmelissen

This comment has been minimized.

Copy link
Collaborator

commented Oct 7, 2014

boundary=protected_area has 23 079 instances, not exactly rare compared to leisure=nature_reserve (51 632) and boundary=national_park (11 362).

@matkoniecz

This comment has been minimized.

Copy link
Collaborator

commented Oct 7, 2014

Note that half is tagged also with protect_class http://taginfo.openstreetmap.org/keys/protect_class#overview

@dieterdreist

This comment has been minimized.

Copy link

commented Oct 8, 2014

Il giorno 07/ott/2014, alle ore 23:09, Paul Norman notifications@github.com ha scritto:

There is some overlap, especially with leisure=nature_reserve and boundary=national_park. But this scheme is a lot better, IMHO it should be encouraged by rendering.

Where there is an adequate existing tagging scheme, we don't particularly want to encourage a new incompatible one, as it makes it harder for all

the currently supported scheme has some limitations because if a nature reserve is not defined on the national level the only alternative is leisure=nature_reserve. This is then used for all kind of protected areas (municipal, provincial, regional, international level) making it hard to determine the importance (besides size). Also "leisure" is not well fitting for a nature reserve in general but in particular for those cases where access is limited or restricted. These are old concepts, and the "new" scheme protected area was introduced to overcome these limitations.=

@astoff

This comment has been minimized.

Copy link

commented Nov 18, 2014

Where there is an adequate existing tagging scheme, we don't particularly want to encourage a new incompatible one, as it makes it harder for all data consumers.

I have imported and manually mapped a number of protected areas in Brazil (both nature reserves and indigenous lands), and I would say that the boundary=national_park / leisure=nature_reserve scheme is not well suited for us here, while the protected_area scheme fits our needs perfectly.

Before moving to the new tagging scheme, we had to use boundary=national_park and/or leisure=nature_reserve on a number of areas that were neither national, nor parks, nor leisure-oriented (for instance, state-owned biological reserves).

More importantly, with the old tagging scheme there is no way to distinguish very strict conservation areas (e.g., national parks) from less strict ones (national forests, protected landscapes, etc.).

Aboriginal lands have existing tagging, generally boundary=aboriginal_lands

It would be pretty weird to use this tag anywhere the term "aboriginal" is not used -- including the US, where one talks of "indigenous" or "native" people. The word "aboriginal" may even be considered politically incorrect in some places. That's why the numbered values for protect_class make much more sense.

boundary=protected_area has 23 079 instances, not exactly rare compared to leisure=nature_reserve (51 632) and boundary=national_park (11 362).

Note also that there one fifth of all nature_reserves (10 642) also have the tag boundary=protected_area. The explanation for this is that people want to use the new tagging scheme, but keep leisure=nature_reserve for rendering purposes (at least that's what we have been doing in Brazil).

@planemad

This comment has been minimized.

Copy link

commented Feb 6, 2015

In light of the difficulties implementing rendering of boundary=protected_area fully, can we atleast start recognizing some of the tag combinations to enable the migration of tags from national_park and nature_reserve?

My suggestions is to start rendering [boundary=protected_area][protect_class=2] exactly like [boundary=national_park].

Starting step would be to add the protect_class key so that we can start playing around. Not sure what the procedure for this is?

@matthijsmelissen

This comment has been minimized.

Copy link
Collaborator

commented Feb 6, 2015

In light of the difficulties implementing rendering of boundary=protected_area fully, can we atleast start recognizing some of the tag combinations to enable the migration of tags from national_park and nature_reserve?

Unfortunately not, the entire problem is that we currently can't use protect_class as this key is not loaded in the database.

@planemad

This comment has been minimized.

Copy link

commented Feb 6, 2015

@math1985 when do database keys get updated? This will probably be scheduled for sometime right?

@tilmanb

This comment has been minimized.

Copy link

commented Feb 6, 2015

See #1286 . It will be done at some point in the future.

@matthijsmelissen matthijsmelissen referenced this issue Apr 28, 2015
0 of 6 tasks complete
@ianmcorvidae

This comment has been minimized.

Copy link

commented Jun 15, 2015

I don't know if this is the same problem or a different one, but http://www.openstreetmap.org/way/353717755 is tagged with both boundary=protected_area and leisure=nature_reserve; it renders as leisure=nature_reserve at z13 and higher, but z12 and lower the area doesn't appear at all. http://www.openstreetmap.org/way/163135968 by comparison, tagged only with leisure=nature_reserve, renders properly at all levels. Seems like some sort of conflict.

@jfirebaugh

This comment has been minimized.

Copy link

commented Jan 18, 2016

I changed the recommended tagging for U.S. National Forests to boundary=protected_area and updated the forests in USFS Region 6 before realizing this would cause them not to be rendered on osm.org. I'm considering reverting to tagging for the renderer with boundary=national_park despite widespread agreement that this is incorrect.

Am I correct in interpreting that the consensus here is that boundary=protected_area should be rendered, and now it's just a matter of database update cadence?

@skylerbunny

This comment has been minimized.

Copy link
Contributor

commented Jun 11, 2018

I'd like to suggest that at some point, a trigger is just going to have to be pulled here. boundary=protected_area has as many relations as leisure=nature_reserve, to name one example. I suspect a lot of those cases (and I'm guilty of them myself) are a matter of of 'tagging for the renderer', in this case, OpenStreetMap Carto.

In the name of moving forward on this, may I suggest:

  • Render ways and relations with the tag boundary=protected_area as follows:
    • closed ways (meaning areas) with the tag boundary=protected_area are rendered in the same style as leisure=nature_reserve (border names with green outlines and a center label)
    • Relations with boundary=protected_area and type_boundary with closed polygon rings are rendered in the same style as leisure=nature_reserve (border names with green outlines and a center label for each closed ring)
  • In cases where leisure=nature_reserve, landuse=forest, boundary=national_park, and leisure=park (all four are ones where osm-carto will render a name and area) already exists on one of the above objects, simply do a check to 'not render it a second time'.

All of the above said, let's not worry about what zoom level they're seen at, which countries do or don't have a certain percentage of these, and so on. I understand the concerns, but we'll be here forever and this will never get executed if we get bogged down in that - we're already four years in, and doing nothing will never make this problem simpler; it will actually make it even more complicated as people continue to use whatever tag they feel best to make sure osm-carto rendering appears and the core problem (double/triple/+ tagging) diverges even more than it already has.

The above is not a perfect solution, and it won't take into account all the edge cases where people are using (yet more) tagging for the renderer, but it at least gets 'what's already out there' rendered somehow, and will allow removing these most common redundant and often incorrect tags over time preferentially for 'protected area'. Once some of this cleanup is done, we can move on to differentiating the various render styles for different protected areas by zoom level, type, and so on.

'National parks and state parks look the same' is a problem we can handle if the only difference is 'which protect class they're under'. There are too many if/then/elses with all of the tagging on the board, while also not rendering what people are clearly moving toward.

@dieterdreist

This comment has been minimized.

Copy link

commented Jun 11, 2018

@kocio-pl

This comment has been minimized.

Copy link
Collaborator

commented Jun 11, 2018

It's doable for some types (IMO related to the nature), especially after we have set a size rule - the only one that makes sense here.

@kennykb

This comment has been minimized.

Copy link

commented Jun 12, 2018

[TL;DR: +1 on using size to decide what to render. -1 on removing nature_reserve tags until a better option for rendering is available. I don't care whether national parks look like state parks. Protect_class is of minimal value to the renderer.]

Choosing which objects to render based on size is entirely sensible.

Rendering at least something is a must. Otherwise, you punish mappers for 'doing it right'. Objects like US National Forests are nature reserves only by stretching the term far beyond anything that looks reasonable, but they are too important not to render, and there is a fragile working consensus that nature_reserve as temporary tagging is 'least worst' until the rendering situation improves.

Because of that fragile consensus, removing 'leisure=nature_reserve' tags from these objects before offering a reasonable alternative would be a hostile act. I for one put in a fair amount of work trying to get the protected_area tagging right, and I'd be quite cross if I were to be rewarded for that by seeing New York State lands disappear from the map.

'National parks look the same as state parks' is a non-problem around here. New York's larger state parks are of size comparable to the US National Parks, they have similar usage patterns (including extensive opportunities for backcountry recreation in some very wild land), they are managed by a sovereign entity (US has a principle of dual sovereignty; for the central government to take these over without the state's consent would likely precipitate a constitutional crisis), and some of them are protected more strongly (requiring a constitutional amendment to reclassify them).

The maps that I render are targeted chiefly toward hiking. I find it most useful to derive the rendering style based on access (access=* and foot=*) - those, rather that protection class, are what determines "can I hike here?" (And I still have 'foot=permit' about, because the next question is "can I drive straight to the site or do I need to do paperwork first?" )

Protection class, in fact, falls even beyond 'protection title' when I'm working with special-purpose maps locally. 'Wilderness', 'Wild Forest', 'Primitive Area', 'Canoe Area', 'Forest Preserve' are all class 1b, but have different regulations on where one may camp, whether equestrians and cyclists are permitted, what tools are allowed for trail work (need prearranged permission to possess a chainsaw in Wilderness) and so on. By contrast, there's little difference to the back-country traveler around here between a class 1b Wild Forest and a class 6 State Forest - as long as tree harvesting isn't in progress in the State Forest, the rules are pretty much the same.

These are specialized uses. On the main map, probably the only distinction that would be relevant to most users would be to distinguish class 1 (1a, 1b) from lower classes, and I'd be happy without even that.

@skylerbunny

This comment has been minimized.

Copy link
Contributor

commented Jun 12, 2018

It's doable for some types (IMO related to the nature)

https://taginfo.openstreetmap.org/keys/protect_class#values

I'd say if you rendered (1, 1a, 1b, 2, 3, 4, 5, 6, 7), and prioritize that render above other types when they exist on the same object, that's more than enough for now. Even if all 9 were rendered identically (for example how nature_reserve is since they're basically 'nature stuff') this would put 70% of all extant protect_class boundaries on the map.

The remaining 30% is split between lower priority stuff:

  • 19, 'There isn't a more specific class for this' natural resource area'
  • 27, public land, which may be very broad and might want to be rendered less prominently anyway
  • 22+24, which probably want to be rendered in a color other than green, and can be taken up later
  • Others which are in the low single digit % of use so far.
@kocio-pl

This comment has been minimized.

Copy link
Collaborator

commented Jun 13, 2018

I guess I can simply reuse this code example now: #2830 (comment), but with the whole Nature-protected-area range (1-7, 97-99), because now we don't have to classify them - they will be shown on the map as early as they are big enough.

@sig-pnrnm

This comment has been minimized.

Copy link

commented Nov 2, 2018

Hi,
I do not have the level in English, nor on OSM, to understand all the subtleties of this subject.
However, I wanted to point out that we have a problem in France of rendering as regards the "Regional Natural Parks" (PNR).
These are rendered on most proprietary maps, but not on OSM.
Also, it is common for well-intentioned contributors to add the tag "leisure = nature_reserve" to allow the display of these parks.
As a geomatician in one of these parks, I find it hard to convince my colleagues to not use "G**gle maps" where PNRs are rendered.
It would be nice to be able to manage this simple case: the PNR can be identified by this combination of tags:

  • boundary = protected_area
  • protect_class = 5
  • protection_title = parc naturel régional

Thanks for your help !

(edit)
I add the link to the french discussion about it : http://gis.19327.n8.nabble.com/Rendu-OSM-des-Parcs-naturels-regionaux-PNR-tp5908000.html

@sig-pnrnm

This comment has been minimized.

Copy link

commented Nov 2, 2018

To illustrate, here is the rendering of PNRs when they had the wrong tag (leisure=nature_reserve).
Today, they are no longer visible, which is a shame.
rendu_pnr_osm

@Adamant36

This comment has been minimized.

Copy link
Contributor

commented Nov 2, 2018

In California a lot of people tag protected areas as leisure=park to get them to show up on the map. Some of them got re-tagged to boundary=protected_area recently. Which led to notes and messages by people who thought the places had been deleted when they didn't and then were upset that they were not being rendered anymore. Even though the places are still mapped. I share their feelings. Protected areas in California are major areas. As I am sure is true for ones in other places. They should be rendered.

@dieterdreist

This comment has been minimized.

Copy link

commented Nov 2, 2018

@Adamant36

This comment has been minimized.

Copy link
Contributor

commented Nov 2, 2018

@dieterdreist, yeah leisure=park is totally not right. Which is why they get re-tagged. Although, then people will add the park tag to them again. nature_reserve works sometimes. I don't like the leisure insinuation with it for a protected area though. As a lot of protected areas are either not accessible to the public or have very strict usage rules. I don't think anyone is going to tromp through a protected marsh due to how it is tagged on OSM, but its something I think about. Anyway, I prefer the protected area tag over nature reserve, which is to general imho, because it allows for more specific tagging of the classification of protection the place has. Maybe boundary=protected_area can at least be rendered the same as nature reserves. I don't see any reason why they couldn't be.

@dieterdreist

This comment has been minimized.

Copy link

commented Nov 2, 2018

@kocio-pl

This comment has been minimized.

Copy link
Collaborator

commented Nov 2, 2018

I still plan to do implement it, since it looks like this is parallel type which is not possible to classify related to natural reserves. I just didn't find the time to return to this particular problem yet - #2830 was first try, but I had to rethink the issue to understand it better.

@sig-pnrnm

This comment has been minimized.

Copy link

commented Nov 2, 2018

Rather than want to manage all categories of "boundary = protected_area", the easiest way could be to go step by step, on combinations of tags that do not pose problems.

In French, there is an expression that says "the best is the enemy of good": everything in its time.

So, while "preaching for my parish" (not sure that this expression exists in English), I would suggest that you integrate the combination of tags proposed below to the main rendering: it has no ambiguity!

    boundary = protected_area
    protect_class = 5
    protection_title = parc naturel régional

For other categories/combinations (or for this one if there is debate), this could be managed in individual issues ?

@kocio-pl

This comment has been minimized.

Copy link
Collaborator

commented Nov 2, 2018

Nobody yet claimed that individual classes are the problem, you are the first to suggest it. Why do you think so? My take is to use the whole section of similar classes.

@sig-pnrnm

This comment has been minimized.

Copy link

commented Nov 2, 2018

This may be due to my bad English level!
I see that the subject seems complex, but I do not understand all the complexity!

@kocio-pl

This comment has been minimized.

Copy link
Collaborator

commented Nov 2, 2018

I took some time to look into the problem and here are some key findings (which evolved through the time):

Of course now I have to recollect things once again, but this is doable. Most of the hard work (research) has been done already.

@dieterdreist

This comment has been minimized.

Copy link

commented Nov 2, 2018

@Bibi56

This comment has been minimized.

Copy link

commented Nov 2, 2018

Nobody yet claimed that individual classes are the problem

As Dieter said, it was not the blocker but in this long thread, it's easy to (mis)understand that some classes may be difficult to render, Sylvain just suggests to start with the easy cases (related to natural protection).

@kocio-pl

This comment has been minimized.

Copy link
Collaborator

commented Nov 2, 2018

As far as i remember I was planning to render metaclass Nature-protected-area (1-7,97-99), and not to render Resources-protected-area (11-19) nor Social-protected-area (21-29).

@kennykb

This comment has been minimized.

Copy link

commented Nov 2, 2018

@kocio-pl

This comment has been minimized.

Copy link
Collaborator

commented Nov 3, 2018

I don't know. There's a general hint how to assign protection class - in short, it might need searching by name or discussing it in a proper place:

https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area#Protect_classes_for_various_countries

@sig-pnrnm

This comment has been minimized.

Copy link

commented Nov 13, 2018

Sorry to seem in a hurry for this rendering question, but do you have any idea when this change will be operational?
Are there still technical blocking points? (I'm not sure given my low level in English 😉)
It is true that I can not wait to be able to communicate to my partners on the rendering of the Regional Natural Parks in OSM 😃

@kocio-pl

This comment has been minimized.

Copy link
Collaborator

commented Nov 13, 2018

It is mostly tedious, boring job with the code, which was sketched in #2830. I cannot give you a time frame for this, since I have not too much time for OSM Carto lately. If somebody is willing to make a PR, it would be faster probably.

@matkoniecz

This comment has been minimized.

Copy link
Collaborator

commented Dec 8, 2018

It is likely that this issue will be closed by #3509 that introduces rendering for some classes.

Note that it is not rejection for potential rendering of other subtypes of boundary=protected_area. Please open new issues like #3520 to propose other related changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.