Proposal talk:Named protection class for protected areas

From OpenStreetMap Wiki
Jump to navigation Jump to search

Great work!

I'm impressed by the amount of work that has gone into this proposal so far. It looks like this will be a change for the better. I'd certainly support using protection_class for each of the IUCN 1 to 6 classes, and I think I'll start using them right away. Hope to see this move forward. --Jeisenbe (talk) 15:09, 14 August 2019 (UTC)

Clarify which tags are new, which tags will be deprecated

When you've finished editing, please make a clear list off all the new, proposed tags, in one place. Also please clarify what pages are being edited and if protect_class=* is being deprecated by this proposal.

It might make sense to deprecate all values of protect_class other than 1 to 6, since those numbers at least correspond to the IUCN numbers and most are fairly commonly used, while the higher numbers are rare and confusing. Over time, if protection_class becomes much more popular, the protect_class:1 to 6 might also become obsolete, but for the short term it might be difficult to change them all right away. --Jeisenbe (talk) 13:44, 18 August 2019 (UTC)

I've edited the "Proposal" section to make it clear that this proposal would replace protect_class, and to list all of the new tags. Please edit it back if that was not your intention, and please add more complete descriptions for each of the new values. --Jeisenbe (talk) 05:53, 5 April 2020 (UTC)

Protection_class=condition?

It is written in one place that protection_class=condition should maybe just be protection_class=hazard, to replace the current protect_class=15 and 16, "Location Condition" and "Longtime Hazard Area". I think this makes sense. --Jeisenbe (talk) 13:44, 18 August 2019 (UTC)

boundary=aboriginal_lands vs protect_class=24

Re: protect_class=24, "Political protection", you might need to talk to the folks in Brazil who are using this tag. Not all of them were happy with using boundary=aborignal_lands instead, if I recall correctly, but perhaps this could change. --Jeisenbe (talk) 13:44, 18 August 2019 (UTC)

Since this proposal was drafted, boundary=aboriginal_lands had become much more common, while protect_class=24 has not increased, so I now think this will not be a problem. --Jeisenbe (talk) 04:51, 5 April 2020 (UTC)

Tag for US forest service and Bureau of Land Management

What tag would you propose for US Forest Svc and BLM? They are protected in the sense that someone has to jump thru many hoops in the approval process, and are unavailable for housing development. They are both used for recreation, forestry, oil and mineral extraction, and grazing. I would guess that the most common use (in Colo, Utah anyway) for NF is recreation, and for BLM might be grazing (but plenty of recreation and oil/natgas drilling too). -- 01:44, 26 August 2019‎ Bradrh

National Forests are usually tagged as protect_class=5 currently. So the equivalent would be protection_class=landscape? I don't think there is any one tag that will work for BLM land; certain areas are protected from development, as you mentioned, and others allow industrial activities like oil/gas drilling and mining. Some might be IUCN class 6 "Protected area with sustainable use of natural resources", which is protection_class=sustainable_resource?
Most US National Forests are protect_class=6 currently, since they were originally developed for forestry (sustainable extraction of timber), they would be protection_class=sustainable_resource. See US_Forest_Service_Data and http://overpass-turbo.eu/s/So8 - there are 1247 ways and relations with protect_class=6, protection_title="National Forest" or "State Forest", in the USA, versus only 18 with protect_class=6: http://overpass-turbo.eu/s/So9 --Jeisenbe (talk) 05:00, 5 April 2020 (UTC)

Potential conflict with IEC 60529 degrees of protection

First of all, thank you to bring this subject up and writing this proposal. This is really a need to define classes of protection regarding all different possibilites we find on ground.
Nevertheless, adopted terminology of protection class may mislead to several concepts like ones defined in international norm IEC 60529 about degrees of protection of internal enclosures for electronic devices. See the official document.

As OSM may support both environment protection and degrees of protection on sometimes similar objects, would you consider using keys like environment_protection=*, iucn_protection=* or something which directly links to environment and landuse/areas please? The two topics are unconsistent: IUCN define what is actually protected in an area while IEC 60529 define which substance the content of a box is protected from. I have no problem with defined values and chosen paradygm to define which are target of protection of a given area. This issue is raised for consistency sake only. All the best Fanfouer (talk) 15:45, 28 August 2019 (UTC)

I don't really think that will be a problem. It would be a bad idea to use the key "protection_class" for internal enclosures for electronic devices. Since the existing tag which will be replaced is "protect_class=", this new key "protection_class=" is close enough to remember, but is better English language syntax.
However, if the author wants to consider changing the key, another option would be "protected_area=*" - this makes sense as a sub-class for "boundary=protected_area" and it works in English too, e.g. "protected_area=strict_nature_reserve", "protected_area=landscape". But I am happy with the current key too. --Jeisenbe (talk) 05:05, 5 April 2020 (UTC)

Don't recommend double-tagging features

I oppose this new text about protection_class=recreation:

"It is permissible to dual-tag parks, recreation grounds, sports centers, nature reserves, etc. with this tag"

We should not tag a park or sports center as boundary=protected area. See the Good Practice page about "One feature, One OSM Element": https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element

Each real-world feature should be represented by a single object in the OpenStreetMap Database. Either it's a leisure=park or it's a =sports_centre or it's a boundary=protected_area, not both on the same area.

(Now it's certainly possible to find a smaller sports_centre or park inside of a larger boundary=protected_area, but it would not be the same area, so both tags would not be added to the same OSM database element) --Jeisenbe (talk) 02:10, 6 April 2020 (UTC)

How can I know what a feature in the real world is? It all depends on your interpretation (and maybe OSM tag definitions) whether a park that is also somehow protected by legislation, is seen as one feature (protected park) or as 2 (protected area and park). This would not make sense if the spatial extension is different, agreed, but if the spatial extension is the same then it is up to you to decide. In the real world, there is no such thing as "features", they are only created through our definitions and (often culturally formed) expectations. --Dieterdreist (talk) 12:22, 6 April 2020 (UTC)

Seascape must be included, local protection

Hello.

Something which falls into my professional remit! Iceland has over 100 nationally designated areas and then numerous "local protection" which municipalities handle. I don't see anything in this proposal about that aspect.

Here we have the fairly large fjord of Breiðafjörður in Iceland, majority of which enjoys a IUCN category 5 protection as you can ascertain using the WFS service we run for Nationally Protected Areas in Iceland. Tagging this as landscape is... not the correct way to put it politely.

--Stalfur (talk) 16:27, 9 May 2020 (UTC)

The proposal makes it clear that protection_class=landscape would be used for protected seascapes (IUCN 5): "A Protected Landscape or Seascape: an area where the interaction of people and nature over time has produced an area of distinct character with significant, ecological, biological, cultural and scenic value. Less strict protection." --Jeisenbe (talk) 18:48, 9 May 2020 (UTC)
I know but that is not very transparent to the user - this change is to make usage of the protection categories easier and so using a designation that it honestly the opposite (seascape vs landscape) is not in the spirit of making things more transparent. It is sort of like using building=hospital for both a hospital and a health clinic, because they serve similarish functions yet are very different. --Stalfur (talk) 18:55, 9 May 2020 (UTC)
Even though we're deriving the plain-English names of the various conservation protection types, we shouldn't be strictly beholden to a 1:1 match with IUCN protection categories. We've already carved out an exception for protect_class=2 (by allowing boundary=national_park to remain), and since IUCN Category 5 is "landscape or seascape" there is no reason why we shouldn't match the plain language and have separate protection_class=landscape and protection_class=seascape. The goal of this proposal is "plain language values" and "a seascape is a landscape" is a fiction we've created to shoehorn all former Class V areas into a single key without doing something silly like protection_class=landscape_or_seascape. ZeLonewolf (talk) 06:26, 12 October 2020 (UTC)

Getting to the finish line

Hey there - really great work, and this proposal is something that needs to happen. I've been working with User:stevea on similar ideas to better tag these types of areas, but I think what you're proposing is really the right "bigger fix" to get rid of the gnarly protect_class=* once and for all.

I would like to point out a number of pages from our recent spree of draft proposal-writing (in various stages of completion) that may have content that can be borrowed:

If there is anything I can do to contribute in order to get this to the finish line, please reach out. ZeLonewolf (talk) 06:20, 12 October 2020 (UTC)

strange

Your "Named protection class for protected areas" exist as protection_title since years, see dokumentation in Germany:

https://wiki.openstreetmap.org/wiki/DE:Key:protection_title

Jo Cassel (talk) 12:16, 5 November 2020 (UTC)

Yes, protection_title=* is widely in use and is standard for boundary=protected_area, however, that is merely a local-language descriptive title (usually a portion of name=*). That does not allow for data consumer usage across the wider database, and that is not what this proposal is describing. The purpose here is to replace the cryptic numeric values in protect_class=* with tags based on meaningful English words. It is not a replacement or substitute for the existing tag protection_title=*. ZeLonewolf (talk) 15:22, 5 November 2020 (UTC)
No, protection_title ist not a "local-language descriptive" or a "name" - it is the local legal status, and "the cryptic numeric values in protect_class" is based on an international Standard of
https://en.wikipedia.org/wiki/International_Union_for_Conservation_of_Nature
you should define + use protection_title for your country (as i did in Germany) instead to confuse the whole world and all data consumers. ... Jo Cassel (talk) 16:17, 5 November 2020 (UTC)
You are again confusing protection_title=* with protect_class=*. They are separate and distinct things. This proposal is specifically about protect_class=*, not protection_title=*. Replacing numbers with words. Yes, protect_class=* values 1-6 were inspired by IUCN conservation area categories (and we have improved the documentation to strengthen that linkage). The fact that they are only inspired by the IUCN system and not directly tagging them is the reason that iucn_level=* was invented. Indeed, the original author of protect_class=* invented protect_class=1 which has no linkage to IUCN at all (as "I" is not an IUCN category, only Ia and Ib), and is unclear how it should be used. How protection_title=* is used in Germany, in the USA, or anywhere else, is irrelevant to any discussion of protect_class=*. The purpose of protect_class=* is to further classify protected areas into categories. The fact that the free-form protection_title=* might potentially be used in this way if exact matching strings are used across different protected areas is completely irrelevant to this proposal. This proposal attempts to address the problem of numeric lookup-table values being confusing to mappers and causing widespread mis-tagging.
where can i find the protection_title for protected areas in your country? ... Jo Cassel (talk) 16:53, 5 November 2020 (UTC)
You can find that information in the article United_States/Public_lands! The way we typically use it in the USA, it is often (but not always) embedded in the name. I.e. a name might be "Such and Such Management Area" and we would tag protection_title=Management Area or "Such and Such Preserve" would get tagged protection_title=Preserve. We have defined rather comprehensively in that page a detailed description of which protection titles should be used for protected areas at the national level and how they should be tagged, including which value of protect_class=* to use. State, county, and local usage vary wildly and local mappers would typically use more locally-defined nomenclature. However, those protection titles are not a substitute for protect_class=*, as those tags describe different things. We have started to build out those definitions for our states, but that work has only just begun. --ZeLonewolf (talk) 17:08, 5 November 2020 (UTC)
keep in mind that protect_class is for international comparability, and protection_title ist the local (national) legal status - then everything works fine with the sceme. ... Jo Cassel (talk) 17:52, 5 November 2020 (UTC)
Yes, that is what they are for but they don't "work fine". Users have widely adopted the practice of tagging areas with protect_class=* values between 1 and 6, regardless of whether they are actually conservation areas, purely because those values render in the standard renderer. The standard renderer rejects adding support for values 7+ because these values are not consistently applied or clearly defined, and they have not been approved. Thus, the true state of protect_class=* is that the values are widely used in incorrect ways, compounded by the fact that the values are cryptic and not well-understood. This proposal seeks to achieve clear definitions that everyone can agree on. --ZeLonewolf (talk) 18:16, 5 November 2020 (UTC)
yes there are many problems, but changing anything won`t solve them. Better way is to create a precise documentation, this is for Germany
https://wiki.openstreetmap.org/wiki/DE:Key:protect_class
... Jo Cassel (talk) 18:52, 5 November 2020 (UTC)

Please cancel the proposal

Sorry for the work but the proposal must be canceled. The existing boundary=protected_area scheme is exquisite and nicely structured. It is applicable to anything if you use all the necessary and existing keys. This proposal only brings chaos. In my opinion, the proposal is not applicable to European conditions. Even the proposal boundary=aboriginal_lands was completely unnecessary. streckenkundler (talk) 14:41, 5 November 2020 (UTC)

Would you kindly clarify which "European conditions" are not satisfied by the use of plain-English names (an OSM standard) rather than numbers? --ZeLonewolf (talk) 15:04, 5 November 2020 (UTC)
The existing protect_class values based on IUCN are excellent and clearly defined in a comprehensible way. You just have to apply them. This applies to the whole boundary=protected_area scheme. Using english-names here will, in my view, lead to many mistakes and misinterpretations, as ambiguities now appear. The IUCN category IV (protect_class=4) is now lumped together with other protect_class=values that have nothing to do with each other.
We have covered a great deal here according to the existing scheme. I see no reason to change that.
streckenkundler (talk) 15:56, 5 November 2020 (UTC)
Yes, you have made it clear that you prefer numbers. However, this de facto numbering scheme is causing considerable problems and confusion today and has resulted in many mistakes and misinterpretations precisely because because they are cryptic despite our best efforts to improve the documentation surrounding them. In many, many cases mappers simply choose a value of protect_class=* seemingly at random between 1 and 6 simply to cause Carto to render a protected area boundary. As a result, areas tagged in that range are not reliable to data consumers seeking objects of this class. protect_class=1a coupled with a working knowledge of IUCN protected area categories is far less understandable than simple words like strict_nature_preserve which convey plain-language understanding. I ask again - is there truly a "European condition" not satisfied by named protection classes, or are you simply stating a personal preference for numbers as opposed to English words? Or is it simply a matter of inertia in that you feel protect_class=* ought to continue in its current state because "that's the way we've been doing it"? I am truly seeking to understand what objects may exist in the real world that are not adequately described by words. --ZeLonewolf (talk) 16:12, 5 November 2020 (UTC)
Areas with protect_class=4 are completely different from areas with protect_class=7|14|97|98. It is a different reason why the area is protected. One area can have protect_class=98, one subarea within this protect_class=97, another protect_class=4, others within it only protect_class=7 or at the same time protect_class=4|7]97. ... and this on the whole surface or very often on a subsurface! With protection_class=habitat and so on, an international comparability of protected areas is abandoned, precisely that implementation of the IUCN criteria, extended by regional, national and continental criteria (=protect_class values). But that doesn't work!::streckenkundler (talk) 17:38, 5 November 2020 (UTC)
Thank you, I appreciate your explanation, it is very helpful in understanding the various international concerns. It sounds like the main issue is that there is a need to be able to tag the "regional, national and continental criteria" and agreements associated with protected areas that are not properly categorized under the existing (1a,1b,2-6) IUCN categories. If I'm understanding correctly, it sounds this proposal as currently written does not adequately preserve a method to distinctly tag those areas, with particular emphasis on areas currently tagged 7,14,97 and 98. --ZeLonewolf (talk) 16:58, 5 November 2020 (UTC)

I also take a very critical view of the removal of protect_class=11|13. This should be reverted. That this has not been tagged so far, does not mean that it does not exist. Here in Germany, for example, there is a so-called "forest function mapping" for forest. So reasons why forest is important in certain places. There is, for example, "Soil Protection Forest" and "Climate and Immision Protection Forest". The first would be protect_class=11, the other protect_class=13. That doesn't fit in somewhere else. For example, information in German: https://forst.brandenburg.de/lfb/de/themen/waldfunktionen/ streckenkundler (talk) 18:28, 5 November 2020 (UTC)

I agree that such areas do exist and I strongly support there being a way to tag them. Thank you for offering examples! However, I object to the cryptic numbering system/lookup table, which is likely why these tags have not been well adopted by taggers or renderers. This is partly a reflection of the fact that the numbered protect_class=* scheme has never gone through a proposal/voting process and thus has never been adequately vetted by the community. I would even be willing to develop and/or collaborate on such a proposal to establish tagging for these areas, potentially with your collaboration if so inclined. Since the 11 and 13 tags are not in use, I believe we have an opportunity here to establish tags with a plain-language values, consistent with OSM conventions.
With regard to soil and emission zones: The phrase "protected area" has very specific meaning (See:  Protected area or in German  Schutzgebiete in Natur- und Landschaftsschutz). So the first question is -- do these zones "fit" within these definitions? If yes, then such tagging could live within boundary=protected_area, but if no, perhaps new tagging is needed, either as a new value of boundary=* or else in some other key space.
These are just initial thoughts, but in short I don't feel that we should be compelled to hang onto protect_class=11 and protect_class=13 merely because someone tossed a few words of description into the wiki many years ago. Short of a proposal, the wiki is supposed to describe "how we tag", and therefore it would be inappropriate to document unused tagging without clear consensus on what they mean and how they should be used. --ZeLonewolf (talk) 18:07, 5 November 2020 (UTC)
In my opinion, the key protect_class=xy is not replaceable by anything else. Like the key admin_level=xy, the key protect_class=xy is only applicable in an existing way. The proposal would cause a massive and significant deterioration in the data. By the way... I feel that the proposal does not look at the international differences on the subject. With protect_class=xy, on the other hand, this is solved as best it can.streckenkundler (talk) 20:34, 5 November 2020 (UTC)
The admin_level=* is not comparable to protect_class=*. In the case of admin_level=*, the numeric values have numeric meaning along a scale of values, as smaller numbers indicate higher-level boundaries. In the case of protect_class=*, the numbers do not represent anything other than a substitution value for other concepts. I would urge you to state specifically what "massive and significant deterioration in the data" would occur by replacing protect_class=* numeric values with language-based tags. Further, I ask that you specifically spell out what those "international differences" are so that we can appropriately service international differences. Such claims must be backed up with specifics. If this proposal does not meet the needs of mappers across the world, then we wish to understand what those unmet needs are so that they can be properly addressed. There are many that believe that protect_class=* can and should be properly replaced, but without a clear description of where, specifically, this proposal misses the mark, it is difficult to respond to your objections and/or make the necessary changes in order to satisfy the needs of an international audience. --ZeLonewolf (talk) 20:56, 5 November 2020 (UTC)
Wrong! Both keys: protect_class and admin_level are absolutely comparable! It is largely the same system behind it. With protection_class, an international comparability of protected areas is abandoned. That is unacceptable! streckenkundler (talk) 21:23, 5 November 2020 (UTC)
This proposal perfectly preserves international comparability. It doesn't matter whether you call it protect_class=1a or protection_class=strict_nature_reserve. They are simply words instead of numbers. By switching to a naming system, it enables us to improve international comparability, by (a) bridging international differences with common terminology/language and (b) allows us to define additional terminology when needed to define types of protected areas that are comparable between different countries. If we say, instead, that protect_class=7 means this in Germany, and that in Poland and this other thing in the USA, which is what you appear to be advocating for, that is specifically not international comparability! However, if we define a term that is something like soil_protection_area, then it is perfectly comparable on an international basis -- all areas tagged in that way are for the protection of the soil. Easy!
Additionally, protect_class=* is quite different from your admin_level=* example. It is not possible to come up with a common language for different types of administrative boundaries as different countries use terms like "region", "state", "province", "district", "arrondissement", and so forth. However, all countries have in common the concept of administrative sub-divisions, and a numbering systems is an appropriate way to indicate the ordered relationship of sub-divisions inside of further sub-divisions. There is no such relationship in the protect_class=* key. protect_class=3 is not more or less protected than protect_class=2 or protect_class=4; they are simply substitutions for "natural monument, "national park", and "habitat/species management area". Those numbers could be converted to names with absolutely no loss of precision, while it would be impossible to come up with an internationally-standard name for, say, admin_level=4.
I truly wish to understand the concerns that you have here in the proposal, and I again ask you to cite what international differences you feel this proposal does not address and what "deterioration in the data" you feel would occur. It is not helpful to simply say that you don't like it. If this proposal were adopted, what specific loss of information do you feel would occur under this scheme, that is currently satisfied by protect_class=* numbers? I am listening. --ZeLonewolf (talk) 23:07, 5 November 2020 (UTC)
At the moment I actually wrote everything necessary... But please read the definitions of the current protect_class values carefully. There are significant differences between protect_class=4|7|14|97|98. n the event of a change, it is imperative to maintain the distinction that now exists at the second level of evaluation. With this proposal, however, this is abandoned. At least a third evaluation level is then required, if not a fourth level. I could not estimate the consequences. The proposal makes it very difficult to evaluate. It complicates the further coverage of the fine-grained protected area system that we have here. I agree with user Jo Cassel: the definitions need to be clarified! For the time being, I will continue to discuss this in the German Forum. We have some active mappers here that also deal with boundary=protected_area.streckenkundler (talk) 16:55, 6 November 2020 (UTC)
Thank you for the feedback, this is very helpful. If there is additional input from German-language discussions that we should be aware of, I would encourage you to share/link it. We wish to only propose changes that improve mapping for all countries. --ZeLonewolf (talk) 17:19, 6 November 2020 (UTC)
See: https://forum.openstreetmap.org/viewtopic.php?pid=808430#p808430 . There is only one solution: stop this proposal and improve the definition of existing tagging. It is only possible if you then document a specific tagging. The proposal https://wiki.openstreetmap.org/wiki/Proposed_features/Special_economic_zone is also completely unnecessary. It must be rejected. Everything can be implemented with established tagging if you were to deal with the existing scheme and the possibilities.streckenkundler (talk) 16:11, 15 November 2020 (UTC)

Need for transboundary protected area tagging

There is a need to include a way to tag  transboundary protected areas in a sensible way within this space. related_law=* is not sufficient. I would suggest something like protection_treaty=* is needed to capture this information. There are mappers that desire to have a way to separately group lands that are protected by international treaty separately from domestic lands. With the elimination of protect_class=97 through protect_class=99, that international treaty distinction is lost. It would go a long way towards addressing the international concerns by including plain-language tagging alternatives for areas currently in those categories. I have done significant cleanup on protect_class=* that hopefully lays out more clearly how some of these categories are currently being used. --ZeLonewolf (talk) 04:45, 17 November 2020 (UTC)

Are you planning to move forward?

I run into Tag:protect_class=21 mess and as result I am tempted to make proposal for protect_class=21. I see that you proposed something similar here. Are you maybe planning to continue with that proposal (I am not sure is it useful to review other parts)? Mateusz Konieczny (talk) 20:32, 12 January 2021 (UTC)

Hazard zones

The protection_class=hazard tag is not required because the boundary=hazard tag has been introduced. Something B (talk) 22:57, 23 September 2022 (UTC)

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Named_protection_class_for_protected_areas&oldid=2398708"