Talk:Tag:boundary=protected area

From OpenStreetMap Wiki
Jump to navigation Jump to search

Prior discussions related to protect_class=* were moved to Talk:Key:protect_class on 2020-10-11

Proposal from Landwirt

A propose from "Landwirt" is, to add a "description"-tag (or protection_name, status_name, *protection_status*?). Therewith its better to distinguish between different sites of one level (

Misleading tag names

For me the tag name "protect_id" is misleading because for me, an ID is an identifier (see wikipedia:identifier). It should be unique and can be used to identify an unique object (like a name). Here the meaning of "protect_id" is (if I got it right) to indicate the IUCN Category. It is a classification tag. Why not rename it protect_class, protect_category, or maybe protect_level? Damouns 09:52, 6 March 2011 (UTC)

hi Damouns,
may be - its itself no "unique expression" but together with the boundary=protected_area - system it is not misleading.
no, its not to "indicate the IUCN Category" only:
Concept: for the sake of independence, don´t think the IDs coupled with the IUCN categories.
class, category, level, ... - a "non-hierarchical" key was needed ... A hierachic might only be interesting for zones inside an area.
You might use protect_id without boundary=protected_area unique ...
thanks for your comment! Best regards, --Typoshrub 11:43, 6 March 2011 (UTC)

You didn't get it. For example in the pages of each area has an ID: Etangs Vaillant, Du Crêt Et Du Fort got the ID 345899 (it is the WDPA ID, as indicated in the right panel). The ID is a tool to find an unique area, as in an url such as Two distinct areas must have different IDs. The value you suggest to enter in protected_id isn't an ID. It is a class, a category, a type, a genre... as you want but not an ID. Damouns 12:26, 6 March 2011 (UTC)
Hi Damouns. Your right. I didn´t pay enough attention for that term. I check upgrade-technics for the given tags and report here next days ... best regards, --Typoshrub 14:08, 7 March 2011 (UTC)
Hi Damouns. their was been 3-4 answers on postings on and the tenor was, don´t rename given keys - at the end with the (one) closure: offer an avoid key. Therefor I set on my short-list "protect_class", "protect_type" and "protect_set". I vote for "protect_type", because its short and because "set" is too technical, "class" implies any orders or hierachies.
So the mainpage will be updated ... --Typoshrub 14:19, 14 March 2011 (UTC)
Its updated. Lastly I vote for "protect_class=*" (no other contributions) because some member-values implies more discrepancies, than "type" would suggest. And hierarchy fits too a littel: at least to keep the key open therefor. --Typoshrub 15:24, 21 March 2011 (UTC)

Object of protection

Instead of adding another "protection_*" tag, I would suggest to simply use "object".





--Landwirt 11:52, 24 November 2009 (UTC)

yes, may be ... I shrink there from a little
I chose this (one word more), cause on my experience, with a distinct expression, special in such a big context, its more probable to limit the options / - offer clear options for better handling.
So database-pelople have another opportunity to built a "set of objects" for protection. Shure, on the other hand they can just query objects fitting to protection ... (I imagine a big cloud of possible objects. See tagwatch, the single: type * (160757) (first 300 found entries) ...).
It would be a experiment with a single expression like object and I´ve no problem to become outvoted but too on the key "type" its commen to add another word.

> another "protection_*" tag ... there are not too much.

thank you, regards, T.

I cannot see......

First I will thank you for a good initiative, but unfortienately I cannot see how this level system can cover the various levels of protection used in Brazil (and probably many other countries) without the use of several additional tags. In Brazil there are three main levels of law protecting areas. Federal, state and municipal law. On top of that we have full scale protection (i.e. national parks), partly protection ( fauna protection, bird nesting protection etc.), ambiental protection areas, and climate protection areas. Each of these have different levels of protection. With this scheme we can have as much as 12 national/sub-national levels. I would rather continue to use the existing national_park and natural_reserve tags, but with additional tags describing level and type of protection. For example boundary=national_park name=Parque Estadual Paulo C Vinha protection=complete level=state and maybe even a reference to the law. An area on the border of this we have leisure=nature_reserve name=Area Ambiental do Setiba protection=ambiental level=municipal. For people interested in searching for keywords of the protection, how do I tag that this is Mata Atlantica or Rain Forest? --Skippern 22:13, 24 November 2009 (UTC)

hi Skippern,
thanks a lot about your infos from brazil!
I just read it - after my last table-update, so ... but I saw brazil (a little) :-) sorry, I know it seems to be a little cocky trying to establish a "protected-area-visualition-system" for the legend.
Its no equalize, its an examination. I think about visualition. Therefor you have to simplify. Still we have - I think - just these two levels, national park and nature reserve. I search for an opportunity to bring a littel more into the legend. I don´t want to equalize or planish even one of these well constructed protection systems - quite the contrary.
So I have to find, show and use the similarity of worlds levels of protection. In lots of countrys there might be actually about 10+x levels too ...

> ... Mata Atlantica or Rain Forest? these are biotop-items. I think, you have to lay down them anyway in tags, cause OSM has (still - thats an other "chapter") no such a legend. Otherwise it could be found by cutting boundarys out of "area-tags".
regards, --Typoshrub 15:48, 27 November 2009 (UTC)

  • If I have understood you correctly, the system works mainly with the "protection_level". I think that the tag "protection_status" should be a required field. This allows you to specify what type of protection, the area is. For example, in Brazil and Germany Naturschutzgebiet, Rain Forest, Mata Atlantica, Landschaftsschutzgebiet etc. I think your concept is good and I will support it. Thank you for your detailed description. Smarties 17:25, 27 November 2009 (UTC)

    • hi,
      > "protection_status" should be a required field
      yes. I renamed it to protection_type (´cause it seems to me more commen ...).--Typoshrub 22:23, 28 November 2009 (UTC)

  • Mata Atlantica is just one example of rain forest, and in Brazil, there are several national parks and nature reserves dedicated to protect Mata Atlantica, Amazonas, Pantanal or other special features. It could be interesting to generate maps about various types of protection, and maybe also have different symbols in rendering of various forms of parks. I know that this is maybe somewhat outside this proposal, but I am still airing these thoughts. My point is that a singleminded focus on protection_level is wrong, the tagging of a national park or nature reserve should reflect all aspects of the area, from what level of protection, what level of law/regulation governing this protection, and what is protected. Many nature reserves have different level of access depending on seasons, like islands where you are not allowed to go during nesting season of a particular bird, but is freely accessed the rest of the year. --Skippern 19:06, 27 November 2009 (UTC)
    • hi,
      > ... Mata Atlantica is just one example of rain forest
      ah! thanks ... :\
      > ... It could be interesting to ...
      Here we are talking about the administrativ act, not about landuse. On protection there is a difference in aims on one site and a fitting organisation and managment on the other. That should emerge out of the IUCN-leveling and thats, on my view, "types of protection"(?). You don´t want to visualise the care-actions. But - that should be possible too ...
      If you wish to see various forms of parks - that is a question about landuse and biotop. That is another chapter. And just for this point the present concept failure, because in some cases, you can´t see the landuse/biotop - just "NR".
      see the concept-chapter ... cheers, --Typoshrub 22:23, 28 November 2009 (UTC)

This tagging scheme does fit perfectly with the Brazilian nature reserve system (see the Portuguese wikipedia article for details. The ICMBio Import page describes the tagging scheme used in a recent import. --Augusto S (talk) 19:09, 12 January 2014 (UTC)


Until 2010 there was a lack of fitting tags for the plurality of types of nature-reserves (e.g. in europe there are about 90). Only two types are used in OSM: nature reserve (leisure=nature_reserve) and nationalpark (boundary=national_park), moreover those are technically not equal. So lots of protected areas became tagged incorrectly.

Pay attention to the discussion-content, see:

You can keep buffer-areas or zones apart with additional 'site_zone-tag plus relation' (see polygon example graphic).

a remake of the Tag

Hi, I think, this concept looks a little better. so far, --Typoshrub 20:54, 8 January 2010 (UTC)

Date of creation

In France it will be possible to import data from the INPN. In this data we have a "date of creation" tag. I thought to several ways to note it:

  • valid_from=YYYY-MM-DD
  • creation_date=YYYY-MM-DD

Which one (or an other) would be better? Damouns 05:54, 8 June 2010 (UTC)

hi Damouns,

"date of creation" shouldn´t mean the dataset but the foundation of a protected site. Its an interesting info.

I think, the last one - or a

site_creation=YYYY-MM-DD, cause with "site" its more special.

Your finally used new tag should be too insert into "Usefull additional keys" on the Tag:boundary=protected area site. (sorry for the late reaction, but I didn't get any notification ...)

cheers, --Typoshrub 16:40, 18 October 2010 (BST)

After a long reflexion here about the import of this data, we used valid_from. It is always possible to change this tag if a better one is decided (by who?). In fact "valid_from" is consistent with INSPIRE data specifications (in which the "attribute validFrom is the date and time an object was/will be created in the real world"). Damouns 16:06, 19 October 2010 (BST)

hi Damouns, very interesting, your reflexions! thank you.

yes, I think "valid_from" fits and it includes private initiatives better than legal. I always shrink back, if a key ist too common (lots is valid_from) (- and too special) ... but, with a view to additional- and parent tags, there might be no direct association with "protection" needed (like site_valid_from, ...). We should suggest for valid_from on the Tag:boundary=protected_area-site on additional tags. May be too for values like "1910-1930; 1960-12-09", if a protection is no continuum?

On WDPA's they seems to use

and "designation_type"=National on wdpa means
on the protected_area-wiki-site "site_ownership"
and on WikiProject France/Parcs-site "level"

a further addition tag could be the

doesn´t mean the ID_SPN on WikiProject France/Parcs-site
+protection_code_source= ?
you have the sources for the id_spn?

thank you, --Typoshrub 14:06, 13 November 2010 (UTC)

I don't understand the meaning and the goal of protection_code and protection_code_source. If you wonder what is id_spn, it is an identifier (ID). I don't know the exact meaning of "SPN", but as the given values begin with "FR", I assume it an international ID. If protection_code is designed to indicate an ID, I think it should have been "ref-something". The fact that id_spn isn't a "ref-something" come from the fact that we chose to keep it as provided. Damouns 16:53, 14 November 2010 (UTC)

meaning and the goal of protection_code and protection_code_source:
The protection_code_source means the publisher - as abbreviation - of the identifier (ID),
where the ID/indicator/code comes from.
that is may be, what you have done with id_spn? Than:

  1. id_spn=FR0000000 would be the same than
  2. protection_code_source=id_spn + protection_code=FR0000000

This tag should give any official order-system of an area a space.

But with your, the first choice, you keep the source and the code together and - you preserve the possibility, to apply further order-systems.

On the other hand, nobody really knows, what kind of key f.e. "id_spn" is.

Eu-Use of "protection_code"= NSG WE 237 (1), NSG WE 245 (1), DE:2909-401 (1), NSG LÜ 259 (1), EUAP0504 (1)
Eu-Use of "protection_code_source"= nlwkn (1)
4 german, 1 italian (EUAP0504) until now.

You see, the protection_code_source doesn't real match for the user. They (mostly) don´t know, what they have to diarize.
protection_code_source=nlwkn is an Abb. for a german government agency (Nds. Landesbetrieb für Wasserwirtschaft, Küsten- und Naturschutz).
For the italian site might be the protection_code_source=MATTM (Ministero dell'Ambiente e della Tutela del Territorio e del Mare)?
Best regards, --Typoshrub 16:09, 27 November 2010 (UTC)

Several ID from different sources are often attributed to a single protected area. For example, the Pitons, cirques and remparts of Reunion Island are in the World Heritage list of UNESCO and therefore have an ID from the World Heritage Comite (WHC) of UNESCO (1317). But the same area is also the heart of a French National Park and have an ID for the natural protected sites of France (INPN) (FR3300009). In this case we could simply have whc:ref=1317 (as proposed in Proposed_features/heritage) and inpn:ref=FR3300009 (in order to get rid of id_spn). This would be consistent with the other "ref" systems. For me, "protection_code" is not consistent, neither id_spn. Damouns 12:51, 29 November 2010 (UTC)

Hi Damouns,

thats nice.

somthing like for
+ ref:isil=DE-1111

ref:IBNR2 * (33)
ref:INSEE * (48085)
ref:ISIL * (12)
ref:KBS * (17)
to be sure, that the "ref-inpn"-combination will never be used with any other key, you can take instead "ref" "protection_code":
its a long string, but unique ....

so vote for:
best regards, --Typoshrub 13:00, 1 December 2010 (UTC)

I definitively prefer inpn:ref because it is consistent. But I am afraid that few people are following this debate here. Damouns 15:07, 1 December 2010 (UTC)

new tagging Info

a propose for a tagging Info upgrade:

For the simple minimal identification, three tags are enough (on a pinch two, if you don´t know the name e.g.).

so it goes like this (for a simple area):

  1. draw an enclosed line
  2. designate it with:
+ protect_class=1 to 99 |or| protect_id=1 to 99
+ protection_title=...

( protect_class illustrates protected_area! Don´t miss it out)

Use relations for complex areas. These are:
- areas or boundaries, for those a continuous line is not sufficient, but several are necessary
- areas or boundaries, seated with a interspace, in a distance
- areas, including "iles" res. an exclusion zone.
- areas or boundaries, witch are part of others (network)

so it goes like this (for a complex area):

  1. draw the boundary with some lines
  2. select one
  3. take a relation (new or existing) and assign the other lines to it

- im OSM-Editor JOSM ( down right, the button with a little plus and a gear
- im OSM-online-Editor Potlach: down right, button with the little layer-sign (above the plus-button)

With a relation, you just need to declare the tags into the relation, not anymore to the ways
- except for those ways, who are special, e.g. a boundary-line with barriere=fence.

types of relations

  • type=boundary for lines/ways; don´t have to be a closed ring.
  • type=network an "appendant-declaration"
  • type=multipolygon for all area-declarations, lines/ways have to be closed. In my opinion the default for areas ...

Help and hints for multipolygon-construction
- Relation:multipolygon
- Relation:multipolygon/Examples 1
- Relation:multipolygon/Examples 2 "2.1 Wiese mit Farmland ..."
(in german & netherland region, "multipolygon" ist common – but it seems to don´t work with e.g. the KOSMOS-renderer - compared to "boundary"...)
- Relation:boundary

Needing more than one protect class?
Duplicate the area and put them on top of each other. E.g. for class 97, 98 or 99, which often incorporate different smaler protected_areas, sometimes too with interstitials. The use of double-values with semicolon like 2;97 seems to be deprecate in OSM, because most software doesn´t come along with it.

designing zones (propose): see
Create zones like joining areas, with type=multipolygon-relations and tags site_zone=1, ... Than keep the areas together with another, upper relation.

using external IDs: syntax/technic with ref=*

Because "ref" its common in OSM for external IDs, its recommend, to use it for areas ("habitat", "hecl", whc, ...).

  • ref:ABBR=
  • ref:source:ABBR=
  • ref:category:ABBR=
  • ...
  • ref:ABBR:=
  • ref:ABBR:source=
  • ref:ABBR:category=
  • ...
  • ABBR:ref=
  • ABBR:ref:source=
  • ABBR:ref:category=
  • ...

On the tagwatch different schemes are used. It seems to be a "matter of taste", but I got better lists with the second ref:ABBR:source.
The used abbreviation (ABBR.) should be in any case an official one - or been pointed on :sources=
For key-seperation the colon : . The underline for keeping two strings together without space (its different from the actual ref-wiki).

some examples

Naturpark Mecklenburgisches Elbetal: A naturereserve as part of the network "Naturparks Deutschlands".
Way attached to a type=network - relation. Main-tag-decorations are on the way.

Naturschutzgebiet Wienbeek and Natura 2000:
An [old naturereserve], [upgraded 2006] with "ile"/"exception" and in addition being ["FFH"-part] of a ["Natura 2000"-network]. Way attached to a type=multipolygon - relation and these relation attached to a type=network - relation. Main-tag-decorations are on the relations.


The document says "Protected_area becomes not rendered until now." Does anyone know what is the progress in this regard? The proposed workaround using multipolygons and relations is not acceptable. Where do we start for making the protected areas being rendered?

--Normis 10:38, 6 September 2011 (BST)

I've remove that text because it was suggesting to tag for the renderer and I think we should only talk about the proposal here. It's then up to each renderer to show or not to show those new way of tagging protected area.

( As far as I know, only Hiking/openhikingmap renders boundary=protected_area ) sletuffe 14:59, 6 September 2011 (BST)


I removed some text that could have encouraged users to add data from the WDPA, which is not allowed for copyright or other legal reasons. Pnorman (talk) 07:54, 21 November 2016 (UTC)

Capitalization of protection_title values

Why are the values specified for protection_title capitalized & without underscores? OSM convention say it should be national_park not National Park, unless it's a proper noun. --DaveF63 (talk) 23:38, 18 January 2020 (UTC)

I believe the value is supposed to represent the actual text shown on signs, in the same way that a name=* tag would use capitalization and spaces. --Jeisenbe (talk) 05:24, 19 January 2020 (UTC)
Indeed this is also what I would expect. Therefore this is not comparable to formalized values which are in English and replace whitespace by underscores, rather it follows the orthographic rules of the language of the sign.--Dieterdreist (talk) 12:29, 20 January 2020 (UTC)
OK, so what's the difference between its 'name' & its 'protection_title'? (note the first sentence in bold). What tag defines its classification title (in words). Protect_class is ambiguous covering multiple titles. Only the UK appears to be using 'designation' (see list above). I've done some basic checks - Europe & US appear to be fudging the tagging in some cases. (is it just to get it to render?) An Example: It includes leisure=nature_reserve, which is a duplication of the boundary=protected_area schema. --DaveF63 (talk) 15:01, 20 January 2020 (UTC)
Name is about the whole name (individual name plus usually the local/national protection title), while protection title is only about the local/national (etc.) class of protection (how this kind of protection is legally called in the area where the feature is).--Dieterdreist (talk) 15:06, 20 January 2020 (UTC)

Identification of architectural conservation areas

In the UK, Conservation Areas exist to protect the special architectural and historic interest of a place - in other words the features that make it unique and distinctive. The local planning authority (LPA) establishes how far they extend, the reason for their creation and the level of legal protection they have in place. Most villages and towns have one or more designated areas.

In the Social-protected-area table, the protect_class for these Conservation Areas in the UK is shown as 23 (protection in favour of economics). Protect_class=22 (cultural assets - sites with special architecture or historic interest, designed and created intentionally by people) is more appropriate.

Could you sign your posts so we all know who we're conversing with. It gets very confusing otherwise. --DaveF63 (talk) 12:32, 21 January 2020 (UTC)

Hi unknown poster,
thank you very much, it's true. I think this entry "Conservation Areas" on "23" is a formatting error and should be set to "22", since apparently not used yet (protect_class=23), I changed it.
"23" is to make "legal-fiscal" zones identifiable (<>), i.e. zones in which a state modulates widespread economic activity.
best Typoshrub (talk)

Rendering samples

It's fine to add a sample rendering, but it seems misleading to use the same "national park" image for all the different classes. There should be a simpler image which just shows the boundary line without including anything like "National Park". Or there could be different samples for each type of area, so that the names match. --Jeisenbe (talk) 18:44, 10 September 2020 (UTC)

That's a great idea. Also, I'm pretty sure the stock image isn't even the correct rendering based on what I've learned so far generating the samples at United_States/Public_lands#Rendering_Guide. I spent a lot of time scratching my head as to why my protect_class=12 area refused to render anything and having this information upfront would have saved me a lot of headache and I think will be useful to users.
Also, I spent way too much time trying and failing to compile Mapnik in order to generate generic square samples (which would have been my preference), so I ended up resorting to screenshots from the map. If you have a better way than that I'd love to hear it! ZeLonewolf (talk) 18:52, 10 September 2020 (UTC)
I ultimately changed this to slippymap templates, with actual examples tagged with each protect_class=*. That way if the rendering ever changes, this will update automatically. ZeLonewolf (talk) 03:30, 12 October 2020 (UTC)

Move classfication content to key:protect_class

Main article: Key:protect_class

This is the page for the protected_area class. However, most of the content is describing the protect_class key. All of the protect_class content should be moved over to that page. A user should be able to visit protect_class and see the listing of protect_class categories.

Would anyone object to migrating the protect_class portions of this content over to that page? I would suggest leaving the basic description of protect_class with a "main article" template (see above) as the pointer. ZeLonewolf (talk) 02:39, 13 September 2020 (UTC)

It's also possible to create a new template like {Template:protect_class} and then include that on both pages so that the content is identical. --Jeisenbe (talk) 07:50, 13 September 2020 (UTC)
I have started a skeletal beginning to this at Talk:Key:protect_class. Stevea (talk) 18:25, 14 September 2020 (UTC)
I've made the template and populated it with the top table data. Not sure if this is really 'better' than it was before, but at least it's easier to get to the information now. ZeLonewolf (talk) 03:37, 15 September 2020 (UTC)
I have now completed the move of protect_class=* content and discussion to that page's talk page. Thanks to the template, the main protect_class value description remains in this article, also. ZeLonewolf (talk) 03:33, 12 October 2020 (UTC)

I think it is still confusing to have the templated protect_class values on this page, and the country-specific content on the protect_class=* page. I still think it makes more sense that ALL of the protect_class definitions go over there to centrally-locate content in one place, and have this page be only about boundary=protected_area. --ZeLonewolf (talk) 05:28, 22 November 2020 (UTC)

It's hard to make sense of the meaning of boundary=protected_area without knowing the protect_class=*, so I believe this information should be on the page. --Jeisenbe (talk) 17:58, 22 November 2020 (UTC)
If the two pages have essentially the same information, would it make more sense to make one of them a redirect to the other? Or perhaps create Protected area for this purpose? As it stands now, the country-specific table is only in one of the two pages, which makes it easy to miss if you're in the wrong page. If I pulled the country-specific table into the template, that would make the pages almost duplicates. --ZeLonewolf (talk) 23:07, 22 November 2020 (UTC)

Copyright status of

This article links to, which appears to be a copyrighted source. As far as I can tell, the data at is simply an aggregation of national government sources (which may have more favorable copyright terms e.g. US data which is public domain). I am thinking the link to protectedplanet should be scrubbed. ZeLonewolf (talk) 15:10, 27 September 2020 (UTC)