gravitystorm / openstreetmap-carto

A general-purpose OpenStreetMap mapnik style, in CartoCSS
Other
1.53k stars 819 forks source link

Add rendering for boundary=protected_area #603

Closed daganzdaanda closed 5 years ago

daganzdaanda commented 10 years ago

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 commented 10 years ago

See also: https://trac.openstreetmap.org/ticket/3102 https://trac.openstreetmap.org/ticket/3461

dieterdreist commented 10 years ago

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 commented 10 years ago

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: https://github.com/gravitystorm/openstreetmap-carto/issues/563#issuecomment-44128610.

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 commented 10 years ago

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.

olegseliverstov commented 9 years ago

Besides it would be nice to render areas with protect_class=97 and 98 (important nature reserves) 97 - http://en.wikipedia.org/wiki/Natura_2000 98 - http://en.wikipedia.org/wiki/World_Network_of_Biosphere_Reserves and http://en.wikipedia.org/wiki/List_of_Ramsar_wetlands_of_international_importance

pnorman commented 9 years ago

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

daganzdaanda commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

protect_class is not in the database.

matthijsmelissen commented 9 years ago

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

matkoniecz commented 9 years ago

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

dieterdreist commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

tilmanb commented 9 years ago

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

ianmcorvidae commented 9 years ago

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 commented 8 years ago

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?

dieterdreist commented 8 years ago

2016-01-19 0:21 GMT+01:00 John Firebaugh notifications@github.com:

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?

I'm in favour of rendering it.

imagico commented 8 years ago

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?

I think the only question is if only some types of protect_class should be rendered (which is not possible at the moment) or if it would be an improvement to generally render boundary=protected_area right now in the same styling as leisure=nature_reserve or boundary=national_park. This is not an easy decision although if the US community can indeed agree on this kind of tagging (which seems appropriate for National Forests) that would be a big step in the right direction which should be supported by this style IMO.

dieterdreist commented 8 years ago

2016-01-19 9:57 GMT+01:00 Christoph Hormann notifications@github.com:

boundary=protected_area right now in the same styling as leisure=nature_reserve or boundary=national_park. This is not an easy decision

yes, rendering all of them in the style of a nature reserve seems strange, because the tag also includes socially protected areas like military areas (only 0,3% currently), historic buildings (heritage), special economic zones etc. From a practical point of view, the very most actually used values refer to natural protection, but there are currently 9,7% public land and 3,3% cultural assets (heritage, conservation). There are also 519 objects (2,7%) of political protection areas (reservations, indigenous areas) that would be very important to show (IMHO).

jfirebaugh commented 8 years ago

if the US community can indeed agree on this kind of tagging (which seems appropriate for National Forests) that would be a big step in the right direction which should be supported by this style IMO.

I believe there is a consensus in the U.S. community that National Forests should be tagged boundary=protected_area, protect_class=6. It's a bit of a chicken-and-egg situation though because we'd like that to be rendered first.

mboeringa commented 8 years ago

I think this needs to wait for a database reload and availability of hstore. @dieterdreist's figures and remarks about different types of protected areas as defined by the protect_class=x, clearly show to much noise that would occur if the main purpose of the proposed rendering is to make visible National Forests and similar nature protected areas. This really requires more dedicated rendering via the not yet available protect_class key.

matthijsmelissen commented 8 years ago

Am I correct in interpreting that the consensus here is that boundary=protected_area should be rendered

Yes, at least for certain protect classes.

now it's just a matter of database update cadence?

Yes - although cadence is a bit of an overstatement as no database update was done since this style was done, and there is not really a process in place.

astoff commented 8 years ago

I'm considering reverting to tagging for the renderer with boundary=national_park despite widespread agreement that this is incorrect.

@jfirebaugh The provisional tagging for the renderer we are using in Brazil is boundary=protected_area, protect_class=*, leisure=nature_reserve. We are doing this even for indigenous areas, since we want them to show on the map.

kennykb commented 8 years ago

I'm coming late to this, because I fell into it when attempting to repair a problematic 2009 import of New York State protected areas. (These include the huge reserves in the Adirondack Park - the largest park in the Lower 48, larger than the State of Massachusetts.) I have been attempting to avoid tagging for the renderer, and trying to follow recommended practice. The result is an extremely disappointing and confusing rendering, which sorely tempts me to go back to telling lies such as "landuse=forest".

I see that this issue has recently celebrated its second birthday. I understand fully the difficulty involved in rerunning osm2pgsql to get it to load the missing keys (or create hstore for the keys that don't have corresponding columns.) I'm fully aware of it, because I maintain my own PostGIS database of just North America, and can readily imagine scaling that to the planet. Nevertheless, now that two years have gone by, and there are still no visible plans for an upgrade to the rendering database that could enable this proposal, would it be fair to close this item with "Won't Fix"? In the alternative, is there anything that those of us who have an interest in this issue, some of whom have pretty fair programming and DBA skills, can do to help?

I suspect that the underlying issue is that this particular problem - rendering of nature areas - is not by itself important enough to justify a database rebuild. And that's fair enough. In that case, though, I strongly suspect that the rendering database we have is "good enough" and no future rendering issue will ever be important enough. That's actually pretty fair, too. It's unfortunate that such an impasse will, as a practical matter, lead to a certain amount of tagging for the renderer, but that sort of compromise is pretty typical for a mature project. You get to a point where the cost of breaking compatibility exceeds the benefit of a new feature or bug fix.

matkoniecz commented 8 years ago

I understand fully the difficulty involved in rerunning osm2pgsql to get it to load the missing keys (or create hstore for the keys that don't have corresponding columns.) (...) would it be fair to close this item with "Won't Fix"

Work on that is in progress, see for example #2128

glebius commented 7 years ago

What's the current status of the problem? I'm now working on marine protected areas in California, USA and I see that anything I add isn't rendered. Should I switch back to leisure=nature_reserve?

dieterdreist commented 7 years ago

sent from a phone

On 6 Mar 2017, at 07:08, Gleb Smirnoff notifications@github.com wrote:

Should I switch back to leisure=nature_reserve?

you could keep it as a fallback, it isn't wrong

kocio-pl commented 7 years ago

Rendering it is now possible (since v4.0.0). Now we need decisions which exactly types should be rendered and how?

talllguy commented 7 years ago

I think that the rendering should be based on the protection classification (tag is protect_class)

Here are some ideas.

protect_class my thoughts on style
1 to 7 Similar to nature reserve, as these are nature protected classes. I think that already rendered nature reserves and these can share the same green transparent border, but perhaps the boundary ones can have a hash, to denote their status as a bona fide boundary, similar to other boundaries on OSM.
11 to 16, 19 these are resource protected areas, so maybe something more like quarry where a hash or pictogram pattern is applied over and throughout the polygon. Tells users don't do something (dig, hunt, fish, swim, drink, etc.) anywhere inside the boundary
21 to 29 socially protected - these are mostly covered by other tags in terms of the thing that is protected inside the boundary, e.g. a church. The boundary shows the human constructed virtual "fence" around it. Maybe (not my expertise) a brown thick transparent border would be a appropriate. it might be a one off consideration.
kocio-pl commented 7 years ago

I think it's not enough to just define rendering of protect_class, we should also define what to show when class tags are absent (like protection_object= or maybe also protection_title=). Taginfo may be useful to find out which ones are really used.

Brown line (#734a08 - @tourism/@amenity-brown) is already used for zoo and theme park. Maybe something like dark orange would be good.

matkoniecz commented 7 years ago

I would show nature protected classes exactly like current nature reserves and do not render other protect_class, including cases where protect_class is missing.

daganzdaanda commented 7 years ago

I agree, let's start with the nature protected classes first. For classes 1-6 we can really just use the nature reserve style. Class 98 seems to be also for bigger areas.

But class 7 seems to be for smaller local areas, so they should only start to be rendered at maybe z13. I would add protect_class=97 to this rule, it covers the Natura 2000 / FFH areas, of which there are MANY in Europe, see https://en.wikipedia.org/wiki/Natura_2000#Current_status

Natura 2000 protects 27,312 sites with terrestrial area 787,606 km2 (around 18 percent of land of the EU countries) and marine area 360,350 km2 in 2017,

If people seriously start mapping these areas, maybe sometime we will have to finetune the rendering again. Natura 2000 areas can range from "a single church tower" to "large swaths of sea", which means using way_area might possibly be better than a one-size-fits-all cutoff at zoom 13?

matkoniecz commented 7 years ago

using way_area might possibly be better than a one-size-fits-all cutoff at zoom 13?

Yes, that is why using current rendering for nature reserves will be fine. Note that tiny ones are not rendered earlier. See for example http://www.openstreetmap.org/#map=18/50.06180/19.86085 and zoom out, it disappears earlier than on z13.

kennykb commented 7 years ago

these are resource protected areas, so maybe something more like quarry where a hash or pictogram pattern is applied over and throughout the polygon. Tells users don't do something (dig, hunt, fish, swim, drink, etc.) anywhere inside the boundary

Fine-tuning of the rendering may be needed in the future, sure. But I don't think that protect_class will be the chief key driving it.

I may be the only person on this thread who's actually mapped resource protected areas. The once I've done are all cases where the land access/use is less restrictive than 'private - no entry without the owner's permission': land that is either held publicly or else protected by conservation easements that allow for public access. 'protect_class=12 protection_object=water' is one I've used a fair amount. It doesn't mean 'don't swim' or 'don't drink' but rather 'don't operate a motor, don't camp, don't build a fire, don't hunt with lead shot (lead-free is ok in many of the areas).' I'm perfectly fine with nature_reserve rendering for these - in fact, I've tagged them with 'leisure=nature_reserve' in addition to the protect_class, so as to get at least some default rendering. ('Nature reserve' encompasses a lot of things.)

There are many other areas around here that are formally resource-protected, but the restrictions are on the landowner: 'don't build a house here', 'don't clearcut', 'don't discharge effluents', ... I haven't tagged any of those, nor do I intend to, since they're ordinarily not observable on the ground. (There are sometimes signs for truckers on major highways giving contact information for spill response teams.)

What interests me more, given that I'm a hiker, is 'access'. I don't care much about the default rendering - rendering it all as 'nature reserve' is fine - but in my own renderings, I want to be able to distinguish between 'open to the public without formalities', 'open to the public but with formaliies' - around here, there are some areas that have mandatory registration on the day of arrival, but are otherwise ordinarily open, 'open to the public with permission - permission ordinarily granted' (do I need to bring my New York watershed access card? Is access restricted in hunting season?), 'access for a fee', and less permissive access (as with areas with limited numbers of permits, advance clearing of dates, and so on).

The regulatory regimes surrounding these areas are complex, and we really shouldn't be mapping them. As a recreational user, the distinction between protect_classes 1b, 2, 4 and 12 is subtle and doesn't inform 'what may I do?' Locat trail maps tend to tag with regulatory regime, which usually follows land ownership. One series of which I'm fond uses 'green=state forest; tan=watershed management, open to public; pink=watershed management, New York permit required; gray=private conservancy (Nature Conservancy, Open Space Institute, Mohawk and Hudson Land Consetervancy, etc.), public access with restrictions' but that's often not observable on the ground, where the signage simply gives contact information about whom to ask for permission.

I don't ask OSM to tell me that 'wild forest' in New York means 'dispersed at-large camping allowed at least a quarter-mile from a road, 200 feet from a trail or permanent open water, below 3500 feet elevation, no parties larger than ten or staying longer than three days at a single site.' I'd be deliriously happy to be able to look up with some reliability: 'this area is designated Wild Forest. That area is Nature Conservancy land. That other area is watershed recreation land,' and then do the research myself on what I need to do for a trip.

+1 on using 'way_area' relative to the map scale. Some of the protected areas are a few city blocks in extent; others are of comparable size to urban counties.

Do consider the rendering for nested areas. '1b inside 2' is a common case here - a Wilderness Area that is part of a large park but enjoys stronger protection than the rest of the park.

matkoniecz commented 7 years ago

Do consider the rendering for nested areas. '1b inside 2' is a common case here - a Wilderness Area that is part of a large park but enjoys stronger protection than the rest of the park.

http://www.openstreetmap.org/#map=18/50.06180/19.86085 example is also covering this case

kennykb commented 7 years ago

http://www.openstreetmap.org/#map=18/50.06180/19.86085 example is also covering this case

Yeah. I just deal with it at a larger scale: http://www.openstreetmap.org/#map=10/43.9992/-74.3960

daganzdaanda commented 7 years ago

Great, I forgot we already use way_area for the natural reserves!

I had a look at the other classes. See https://taginfo.openstreetmap.org/keys/protect_class#values for the values that people already use, even when nobody is rendering the tag.

"Resources-protected-areas" Things with "class 16, longtime hazard area" could be definitely useful having on the map early. Maybe with a red boundary instead of green? Classes 11-15 would be of interest, too, as kennykb tells us. (BTW: there is also http://wiki.openstreetmap.org/wiki/DE:Key:hazmat to tag on roads in water protection areas.) IMHO these resource-protecting areas are more of local importance, so they should start at higher zooms (or have a higher way_area-threshold). Maybe they could be shown with a thinner boundary or a slightly different colour than nature reserves. I would not render catch-all classes like 19.

"Social-protected-areas" From this group, I really would like to see class 24, Political protection: reservation / indigenous area / aborigine. The rest, I don't think we need: Class 25 overlaps with military=* tags, so I don't think we need to encourage this. I do like adding historic and heritage tags, but I don't use boundary / protect_class for this and I would not want to see classes 22 and 26 on the standard map. Class 23, Protection in favor of economics: special economic zones, ... hm, sounds somewhat strange to me. But showing the extent of some free-trade zones might be interesting. Class 21, community life, seems a bit vague (who designates an protected area like that?) and I imagine we have other tags to describe what's on the ground. Class 27 seems to be wrong tagging, and 29 is a catch-all again.

One problem for mapping all these boundaries will be to get valid geometry - there are often signs for these protected areas, but mappers will often have to guess the exact extent. No idea if protectedplanet.net would be a valid source?

matkoniecz commented 7 years ago

"class 16, longtime hazard area" sounds similar to military=danger_area

One problem for mapping all these boundaries will be to get valid geometry

Areas are frequently imported from official sources.

daganzdaanda commented 7 years ago

"class 16, longtime hazard area" sounds similar to military=danger_area

Yeah, it is already in use with double tagging, see Chernobyl: http://www.openstreetmap.org/relation/3311547

But of course it may be something non-military like an industrial wasteland... We could use the same style as the military=danger_area, but having a visible difference might be important, too. (military related issues: #2405, #2670)

ljbade commented 6 years ago

I would like to see rendering of these areas.

I recently added an area with class of 12 for a place called Googong Foreshore that is primarily a water catchment reserve but is also managed as a conservation area and for recreation (hiking, fishing).

I was going to use leisure=nature_reserve but the response from the talk-au mailing list was that protected_area is more accurate.

I then discovered this area is not even rendered!

Please add this to the renderer soon.

kocio-pl commented 6 years ago

I'm afraid this is not possible now - please look at the discussion on #2830. In short: I have found that even "safe" set of protect_class (1-6) gave too much results in some places, like 777 polygons in Germany. Until somebody make a proper research and testing, it's not ready to be merged.

ljbade commented 6 years ago

That's unfortunate. I added the nature reserve tag as a workaround until the protected area is better supported.

kocio-pl commented 6 years ago

Feel free to research the subject - I would be happy to join then as a coder.

Klaus-Tockloth commented 6 years ago

Do not render leisure=nature_reserve anymore. Render only:

Strict protected areas (access not permitted), use a green hatch pattern (similar to military area): boundary=protected_area + protect_class=1

National parks: boundary=protected_area + protect_class=2

Do not render anything else.

kocio-pl commented 6 years ago

Do not render leisure=nature_reserve anymore.

Could you explain what's the reasoning behind it?

Strict protected areas (access not permitted), use a green hatch pattern (similar to military area):

Interesting idea! Could you give some examples?

National parks: boundary=protected_area + protect_class=2

Are you sure that this is a proper way of tagging national parks? I don't know this matter.

Klaus-Tockloth commented 6 years ago

Could you explain what's the reasoning behind it?

Rendering of all protect class areas is very confusing and disturbing. Germany has a lot of these area. E.g. the german state Nordrhein-Westfalen has over 3000 areas (luckily not all tagged in OSM).

bildschirmfoto 2017-11-29 um 16 08 40 https://www.openstreetmap.org/#map=12/51.8472/7.6532

Interesting idea! Could you give some examples?

https://www.openstreetmap.org/relation/2517094 https://www.openstreetmap.org/way/28151799#map=13/52.2897/14.3692

Are you sure about this is a proper way of tagging national parks?

Yes, according to the german wiki: https://wiki.openstreetmap.org/wiki/DE:Tag:boundary%3Dnational_park But you are right, boundary=national_park is also valid.

datendelphin commented 6 years ago

This seems country dependent. For Switzerland, there is only one park which is a national park. The other dozen or so parks would vanish, which would be rather inconvenient.