Proposal talk:Park boundary

From OpenStreetMap Wiki
Jump to navigation Jump to search

Archived Discussion Threads

Unresolved Issues

This is a TO-DO list of sorts for issues that should be resolved in order to move forward:

Proposed Feature Discussion

Create new sections below in order to provide feedback on this proposed feature. The discussion page associated with earlier drafts of this proposal can be found here. Prior content associated with streamlining protect_class can be found here.

I see that a lot of work was put into that proposal! I commented about some things that seem weird/not described properly to me Mateusz Konieczny (talk) 07:50, 9 October 2020 (UTC)

urban parks tagged as boundary=protected_area?

urban parks (including city parks, linear parks etc) that are extensively modelled/shaped by humans such as https://pl.wikipedia.org/wiki/Plik:Krak%C3%B3w_-_park_jordana,,.jpg https://commons.wikimedia.org/wiki/File:Krak%C3%B3w_-_park_jordana,.jpg https://www.openstreetmap.org/way/25113939

should not be tagged as boundary=protected_area

It would be change that is not needed, not backward compatible and very likely to cause rejection of that proposal.

I understand that some US "parks" fit neither leisure=park (urban park) nor are really protected area but that is not a good reason to start tagging urban parks as protected Mateusz Konieczny (talk) 07:42, 9 October 2020 (UTC)

Mateusz, it is far, far more than "some US parks" which fall into this very large category around the world. And, because of the linguistic overlap, it actually IS a good reason to start tagging urban parks as protected: they ARE protected, after all (both FROM development and FOR human recreation). The change is needed to both to avoid ambiguity ("actively disambiguate") as well as to clean up a real mess of park tagging all around the world (especially overuse of leisure=park). Do you have a proposal to do this? (it IS a problem). Aspects of implementation of this proposal can happen in phases, with no immediate necessity to add the additional tag of boundary=protected_area to existing leisure=park polygons. But as I have said to the principal author of the proposal, it can take a long time for "paradigm shifts" (like this) to "seep into the fabric" of how mappers become accustomed to tagging. Stevea (talk) 08:44, 9 October 2020 (UTC)
The key issue that we're trying to address is that leisure=park is doing double-duty as both a boundary tag and an area tag. If not boundary=protected_area, would it be better to come up with different tagging, perhaps simply boundary=park? ZeLonewolf (talk) 13:16, 9 October 2020 (UTC)
I guess that it is a regional perspective, but area used as an urban park (=leisure=park) in my region (Poland) is not automatically protected from development (Kraków development waves hello), is legally distinct from actual protected areas (though other regulations or ownership may protect it), I would not consider it as a boundary and I see no benefit from double tagging anyway Mateusz Konieczny (talk) 13:57, 9 October 2020 (UTC)
There really is a blending and merging of semantics going on here. In the "Kraków waves hello" examples (excellent, all of them), I am tempted to say that "buildings in parks happen" (depending on how park is 'defined' as a park, and that 'park' is an elastic concept around the world). So what this mentally takes is some expansive thought of where the edges of your boxes are and what is inside of them. "It depends on how you think of it" is a slightly rough(er) way of saying something like this and I don't like to be rough. We have parks with (and Wikipedia includes these) buildings, sports complexes, significant architectural improvements and we simultaneously say these are "surrounded by parks" or are "inside of a park." We do! It may be appropriate to "not double tag" in some cases: if that's reality, that's reality. That might mean this proposal bends a bit, but I don't think it breaks it. Stevea (talk) 01:05, 10 October 2020 (UTC)
"buildings in parks happen" - it is true, but in this cases buildings destroyed/damaged/reduced parks. While say https://www.openstreetmap.org/way/832026006#map=19/50.08936/19.92140&layers=N would be a part of park. I wanted to dispute claim that boundary=protected_area is universally applicable to all parks, in many cases parks are not protected. And even for parks protected by say zoning rules, they are often not protected more or differently than surrounding buildings or roads. My point is that while for some parks this tagging may make sense, in many cases leisure=park area in larger boundary=protected_area is perfect tagging but many urban parks have no need for any boundary=protected_area Mateusz Konieczny (talk) 08:47, 10 October 2020 (UTC)
Zelonewolf, I don't think the "syntactic sugar" of boundary=park is necessary. Doing so might be a choice we could elect to make this explicitly known, however, we might be able to express this by choosing one tag or the other, but not both. Tagging does not necessarily exclude in what it means: it can include and exclude and together with another tag mean something quite different. This might be what Mateusz is getting at, that double-tagging is not correct in some circumstances. That might be OK if we clearly state where and how (and why). This could take a good deal of hand-waving and words, but I think we could state it. Stevea (talk) 01:05, 10 October 2020 (UTC)
In short, I think what I say here is if it is inappropriate to tag a leisure=park also with boundary=protected_area, then don't. This proposal doesn't say you have to. Stevea (talk) 00:53, 12 October 2020 (UTC)
I agree with Mateusz Konieczny, urban parks are mapped as leisure=park, and should not be mapped with boundary=protected_area, which is only really sensibly used for IUCN-level-type protected areas: wilderness areas, national parks, natural monuments, protected landscapes, national forests and nature reserves. If it's not like a nationl park or a nature reserve, it shouldn't be in boundary=protected_area. --Jeisenbe (talk) 05:19, 12 October 2020 (UTC)
It seems Jeisenbe doesn't fully comprehend what this proposal proposes. It does not require that urban parks be mapped with with boundary=protected_area, it agrees that urban parks are mapped as leisure=park. It agrees that IUCN-level-type protected areas are mapped with boundary=protected_area AND protect_class=* (which IS sensible, agreed). However, it allows the latter tag to be omitted on parks which are not IUCN-level-type conservation lands, by including a "naked" (no protect_class=* tag) boundary=protected_area tag which "stands alone." That's not a difficult shift to make, and it has enormous potential positive consequences in ease of tagging parks (especially in the Americas) by expanding the definition of "park" from beyond "simply urban parks tagged leisure=park" to include all kinds of the other sorts of parks that are in the world which are not IUCN-level-type conservation lands OR a leisure=park. There are millions of these: how should we tag them? This proposal says "with boundary=protected_area, and if protect_class=* is correctly applied, apply it and if not, leave it omitted." The proposal really is as simple as that. There are primarily "consequences" only in your mind. For the other ones (that might affect mapping or tagging), the remainder of this proposal addresses them. None of these require mandatory changes in tagging (besides this single one which allows a "naked" boundary=protected_area tag) and that isn't really a "change" in tagging, more like a semantic expansion for a single tag (boundary=protected_area, which omits protect_class=*, currently "undefined"). Not really that difficult, is it? Stevea (talk) 07:44, 12 October 2020 (UTC)

Better phrasing

"This proposal continues the established usage of this tag, and offers strategies and guidelines for using it in conjunction with boundary=protected_area for mixed-use parks."

reads like "adding boundary=protected_area to leisure=park is now recommended"

Maybe something like

"This proposal is not redefining this tag, and offers strategies and guidelines for using it in cases of features named "XYZ Park ABC" but not qualifying for leisure=park. For example State Parks in USA are better tagged as boundary=protected_area and may have leisure=park areas inside"

? Mateusz Konieczny (talk) 05:51, 12 October 2020 (UTC)

I added ", nor does it re-define it to also need this tag" (to "This proposal does not and is not intended to deprecate leisure=park) in the Proposal Summary. Stevea (talk) 19:43, 13 October 2020 (UTC)
Excellent recommendation. I just did a major re-write of the opening section to hopefully better reflect this. ZeLonewolf (talk) 22:07, 13 October 2020 (UTC)

natural=wood

Note forest documentation page. "natural=wood" is more problematic, it is not only "wild and natural wooded area". Both natural=wood and landuse=forest is often used for human-shaped tree-covered areas in parks, there is no contradiction unlike what is claimed in "The current park tagging scheme creates ambiguity". Mateusz Konieczny (talk) 07:45, 9 October 2020 (UTC)

Mateusz, talking about natural=wood by refering to landuse=forest page simply further confuses the isssues. So, if natural=wood is problematic, it may be beneficial to discuss it there, on its wiki page, rather than forest. (These two tags are horribly misunderstood and mis-tagged the world over. The landuse=forest page itself says there are no fewer than SIX interpretations of how that tag is both understood and used). There IS a contradiction as "creates ambiguity" states, this is easily proven: what IS the correct interpretation of the intersected polygon? Manicured parkland OR natural wild area? If you can't answer, it's ambiguous (it is) and needs fixing, like this proposal offers to do. If you can answer, you must know something more than the tags on the map are telling you. The basic problem is that the tagging that now exists does not clearly say what is there, when doing so is the entire purpose of the semiotics on a map. Stevea (talk) 08:51, 9 October 2020 (UTC)
"what IS the correct interpretation of the intersected polygon" - for me it is clearly "tree-covered manicured/sculpted area", otherwise I would consider it as mistagging. But six interpretations and even more interpretations how to interpret interpretations it is ugly.
In other words, I would consider that already using leisure=park for national park (protected wild area), landscape park (large area of mildly protected area) etc is mistagging. And I would argue that https://wiki.openstreetmap.org/wiki/File:Park_construction_from_three_polygons.png is already a standard tagging for cases where you have one protected area with part being a manicured park and part being a wild area (as I understand, it is typical in State Parks in USA) Mateusz Konieczny (talk) 14:02, 9 October 2020 (UTC)
Mateusz, in regard to "already using leisure=park for national park (protected wild area), landscape park (large area of mildly protected area) etc is mistagging," the proposal recognizes this. It does not say to tag like this. These should be tagged boundary=protected_area + protect_class=2 (not leisure=park). According to today's wiki, that is now-prescribed tagging. "Typical state parks in the USA" is a rough concept right now, generalities about this are hard to come by because there is a lot of confused tagging. This proposal very directly addresses this confused tagging with these sensible, essentially-true-today recommendations. We're really only stating here "this makes sense of what we both are and essentially should be doing, as all tagging as presented here is already true." (The one assumption, if it can be called that, is that parks are protected areas). Stevea (talk) 01:14, 10 October 2020 (UTC)

why boundary=national_park is deprecated?

  1. there is no explanation for deprecation of boundary=national_park
  2. I would encourage doing it as a separate proposal, at least some people will be opposed for this reason and it is not required/needed to do this together with other changes
  3. if there is no serious issue with boundary=national_park - I strongly prefer it over mysterious numeric codes

Mateusz Konieczny (talk) 07:47, 9 October 2020 (UTC)

Would you support the opposite, making boundary=protected_area + protect_class=2 an incorrect combination in favor of boundary=national_park + protect_class=2, or perhaps even deprecate protect_class=2 and solely use boundary=national_park? ZeLonewolf (talk) 13:23, 9 October 2020 (UTC)
Yes - assuming that boundary=national_park has no problems. I guess that likely trap would be if the meaning of what "national park" means greatly differs between countries. In Europe it is a large or very large protected area, basically always natural one, with quite strict protection rules. My main opposition to boundary=protected_area + protect_class=2 is that boundary=national_park appears to be more human readableMateusz Konieczny (talk) 13:49, 9 October 2020 (UTC)
"I would encourage doing it as a separate proposal" - to clarify. If proposal is deprecating A, B and C then people who want to keep A and deprecate B, C will vote against. If there would proposal to deprecate just B they would support it. By making multiple changes in one proposal, especially deprecation you merge different opposition groups. Mateusz Konieczny (talk) 13:49, 9 October 2020 (UTC)
This is a full-course buffet. Eat it all together for a full meal that is both nourishing and satisfying. You can leave-in-place the existing tagging practice of tagging boundary=national_park and you don't really break anything, you simply have a couple of methods to do the same thing. We have that today (aboriginal_lands, for example) and it isn't the end of OSM. Stevea (talk) 01:17, 10 October 2020 (UTC)
I've put the boundary=national_park stuff on the shelf. I agree that it muddies the water of park boundaries, and by taking it out of this proposal, it allows us to more cleanly focus on the specific issue at hand. ZeLonewolf (talk) 02:20, 11 October 2020 (UTC)

Clarify that leisure=park is not deprecated

As I understand "All parks (areas for conservation, human recreation, or a blend of both) are tagged boundary=protected_area." is not intended to deprecate leisure=park

Maybe mention it in the initial segment? My initial reaction to that part was "WTF, they want to deprecate leisure=park" while proposal is not changing that it applies to modeled/manicured/urban parks.

While I see no point of double tagging such areas with boundary=protected_area my reaction is no longer "absolutely no". It would be worth clarifying this Mateusz Konieczny (talk) 07:53, 9 October 2020 (UTC)

OK, this is now clearly stated. Thanks for the good idea, no ambiguity is meant, in fact this is about clearing up ambiguity! Stevea (talk) 18:57, 10 October 2020 (UTC)

There is no conflict in current tagging

In case of tagging described in https://wiki.openstreetmap.org/wiki/Proposed_features/Park_boundary#Current_versus_proposed_tagging_practices (intersection of leisure=park and tree covered area) there are two possibilities

I would consider "use leisure=park to mark manicured area that may be a subset of area named Foobar Park, especially in USA" as something that is already a proper tagging Mateusz Konieczny (talk) 07:56, 9 October 2020 (UTC)

In the first case (leisure=park tags a wild area), there isn't any way around this without something like this propsal! HOW do I tag a park correctly in these circumstances? If the wild area is "in" the park (a common occurrence around the world), please demonstrate how I should tag in similar fashion with graphics would be nice, but that's quite ambitious. Easier might be citing existing examples in the map. Stevea (talk) 08:59, 9 October 2020 (UTC)
"there isn't any way around this without something like this propsal!" - do not use leisure=park in such case? Mateusz Konieczny (talk) 13:50, 9 October 2020 (UTC)
"If the wild area is "in" the park" - can you give an example, preferably a photo? Mateusz Konieczny (talk) 13:50, 9 October 2020 (UTC)
Try Harvey West Park in Santa Cruz, California: https://www.mapillary.com/app/?lat=36.98486500000001&lng=-122.03968900000001&z=17&pKey=vq0Is67u9_vIz5eBh74BdQ This has typical urban park elements (ball fields, picnic tables, swimming pools, playgrounds, bbqs, etc.) but it also has substantial "wild, wooded" areas. See (in OSM, Carto is fine), Wagner Grove Trail, Steeple Trail, Old Stage Trail, Dos Puentes Trail, which are hiking trails in essentially "wild, wooded" areas, yet still "in" the park. In the photo part of the link, you'll see beyond the No Parking signs, mound of raked leaves and picnic tables a typical example of this essentially "wild, wooded area." Stevea (talk) 15:23, 9 October 2020 (UTC)
"mound of raked leaves" sounds like maintained/manicured park, not a wild forest. On photo I also see trees with trimmed branches, planted bushes... BTW, is it possible to get photo full screen not just as a miniature in a corner? Mateusz Konieczny (talk) 19:28, 9 October 2020 (UTC)
The "mound of raked leaves" is JUST on the OUTSIDE of the wooded edge. You can see the trees in the background, they extend maybe a hundred hectares. These are not the only visual data, here, you can try a satellite view in our many licensed imaging services. "It is a small essentially naturally-wooded area inside of a city park" is a correct way to express this. Try Bing or ESRI around here. Stevea (talk) 01:32, 10 October 2020 (UTC)
I visited a local park today, mapped it in detail, and took LOTS of pictures. This park is typical of parks in my area, because I live in a suburban area and we have very few examples of urban parks. I built a case study comparing that park to one other near me in order to compare and contrast boundary tagging for park. I hope this helps convey the sort of park that is very common in the USA outside of urban areas. ZeLonewolf (talk) 03:17, 10 October 2020 (UTC)

Does not recommend deprecations, allows present tagging in parallel

To be clear, this proposal does not recommend deprecating specific key or key:value pairs (tags), it is fully harmonious with present tagging in parallel. This means in some cases, there remain two methods to do the same thing (e.g. boundary=national_park remains equivalent to boundary=protected_area + protect_class=2). In more developed, later versions of this, some tags are better candidates to "go first" (and deprecate): these are "on a shelf" and can be taken down and proposed to deprecate at a later date. Stevea (talk) 02:30, 11 October 2020 (UTC)

Recreation areas, squares, urban parks, and similar should not be tagged as boundary=protected_area

As mentioned in a previous email, this proposal seems to be saying that "anything you call a "park" in American English can be mapped as a boundary=protected_area". This is a problem because it seems to be based on what is called a "park" in a particular dialect of one language, rather than on verifiable, real-world characteristics which are not limited to a particular language or cultural context.

I suggest that areas used primarily for recreation, which do not fit on protect_class=1 to protect_class=6, should get a different tag. If leisure=park, leisure=sports_centre and similar existing tags are incorrect, then perhaps we need a new tag for the features which are not currently properly tagged.

But lumping them into boundary=protected_area with national parks, wilderness areas, and nature reserves is not a good idea. --Jeisenbe (talk) 05:29, 12 October 2020 (UTC)

We DO need a "different" tag, it is proposed to be denoted boundary=protected_area. What you say of "lumping together" isn't actually true (except in your mind): the tag boundary=protected_area AND protect_class=* are national parks, wilderness areas and nature reserves, not the SINGLE tag of boundary=protected_area. The latter is a superset of the former, simple as that. Release in your mind, decouple, the tag dependencies (if one tag exists, another must) you seem to have. It is possible that one tag alone means what it means (alone) and that another tag in addition to that specializes THAT tag to be something yet-more-specific. That's all that's going on here. You keep saying "this isn't a good idea" but when I say "this isn't broken, here is how" over and over again, you repeat "this isn't a good idea." Please support your assertions: not only do I not know what you mean by that, I support what I say with simple logic and you reply "this isn't a good idea." Huh? Stevea (talk) 22:21, 13 October 2020 (UTC)
Also, this proposal is what it is, not what it seems. (Anybody can "stump the panel" by saying "it seems like something else" without saying what "something else" is — that won't fly). Nowhere does the proposal say "anything called a park in American English can be mapped as a boundary=protected area." Although it might be true that "if it IS called a park in English, consider whether boundary=protected_area is a correct tag." It may very well be. If that works for you (because it is), then tag it that way: that is what is meant by "Expand usage" (of this tag). It really isn't a problem, it is a solution to a problem. Nor do I understand "should not." Why not? It is not "based on" a "particular dialect of one language," more like squarely facing and doing something about "a huge swath of English-speaking people the world over call things parks, so let's tag the boundaries of these protected areas for what they are: boundary=protected_areas". More-specifically highly-specified protected areas that are IUCN areas, tag them or leave them tagged with protect_class=* to distinguish them (for now). We can (and should, imo) clean them up in another (Kevin's) proposal, next and different, but able to be bolted-on-nicely-with-this-one. 1, 2, buckle my shoe. This is a-walk-in-the-park, easy! Stevea (talk) 22:56, 13 October 2020 (UTC)

Using protection_title without a protect_class or similar tag is not clear

It's suggested that "parks" which are recreation areas or urban parks wouldn't have a protect_class=* tag so this would distinguish them. But a lack of a tag isn't helpful. While in the USA the protection_title could be "recreation area", recall that this tag will be in whatever language is used locally, so database users will not be able to interpret the value of the tag in countries where they do not speek the language. Could you interpret the tag protection_title=मनोरन्जन क्षेत्र?

Instead, there needs to be a clear way to tag each feature. --Jeisenbe (talk) 05:32, 12 October 2020 (UTC)

I wouldn't say "instead of" I would say "in addition to." protection_title=मनोरन्जन क्षेत्र is perfectly correct. If YOU want it tagged in English (or any other language), tag it that way. (And/or invent a way for whatever mechanism is needed to get it into English in some unspecified toolchain, with something like a language prefix). But please don't insist that a tag of protection_title=मनोरन्जन क्षेत्र isn't correct, as it is. The lack of a tag IS helpful. It takes a previously undefined syntactic utterance (boundary=protected_area withOUT an accompanying protect_class=*) and defines it as a park. Because the world needs to. And this is the correct place in OSM's syntax to do so. It's really quite a gentle, easy concept. This IS a "clear way to tag each feature." Nothing breaks by us doing this. It's clear as a bell ringing, to me. To some specialized understanding that expects dependencies (which seem to be unstated here) built into protection_title=*?, perhaps not. (Though, I insist: it can stand alone. It can.) What I say is: "don't be so specialized" (or have unstated dependencies). The protection_title key's wiki itself certainly doesn't say this is required. The wiki DOES say that boundary=protected_area is required, OK, it is in this proposal. For its accompaniment with protect_class=* the wiki only says "Useful combination." No lack of clarity here. Still some with you, Joseph? I can't read the map in China (unless I use an "English-tag-filter-renderer"). That's OK, it doesn't mean China-region data entered into OSM are wrong, perhaps simply (mildly?) incomplete for an English-rendered map reader like me. There are millions of places in the map where "database users will not be able to interpret the value of the tag in countries where they do not speak the language." I mean, we can work on that (making tag values more multilingual), but this is true all over the map by people who read many languages: so what? Stevea (talk) 22:00, 13 October 2020 (UTC)
There is nothing wrong with protection_title=मनोरन्जन क्षेत्र, it's quite useful if that's the local title of a protected area. But if you want to compare "recreation areas" in different countries, you need a tag like recreation_area=yes with a clear definition. A search for boundary=protected_area features without protected_class=* will mostly find protected areas which are incompletely tagged. Do not rely on the lack of a tag to define the meaning of a feature. --Jeisenbe (talk) 05:29, 15 October 2020 (UTC)
"If I want to compare 'recreation areas' in different countries, I need a tag (that well-specifies it), with a clear definition." Mmm, I'd have prefered you said "park" here instead of 'recreation area,' but I can let that slide, as I understand what you are saying, at least its aspect of "building a query about these objects can be problematic, here's why." But for every query (or queries, sometimes what you have to search for includes two, three or more regular expressions to match) you could offer that is problematic, I could offer a query (or queries, ditto) that work under this (park = boundary=protected_area) paradigm as well. This largely becomes moot as this proposal gets cleaned up to be more accurate (something in the neighborhood of removing military, toxic waste dump and economic zone / maybe others) so every single case of a protected_area tag (whether with or without a protect_class=* tag) WILL be something most people would regard as a "park," (in many English dialects) AND this proposal is combined with (really introduced simultaneously with) ke9tv's proposal on protect_class reform that you like. The two proposals together are a powerful reformation of "parks" and protect_class that have the potential of streamlining both understanding and tagging of "parks" (plus IUCN-designated areas and more) in a grand scheme that can really clarify these historically difficult-to-map entities. True, the harmonizations of both proposals is still underway, but that's the plan. Stevea (talk) 09:02, 15 October 2020 (UTC)

See also "Proposal:_Named_protection_class_for_protected_areas"

Check out this other proposal to clarify the use of boundary=protected_area and simplify the classes.

Proposal:_Named_protection_class_for_protected_areas would deprecate protect_class=* and replace it with protection_class=* using words for the values, and in some cases to make the protection more specific.

It includes: "protection_class=recreation: An area which is protected for outdoor recreation use, often with titles such as 'National Recreation Area', 'State Park,' 'State Recreation Area', 'County Park,' and so on" --Jeisenbe (talk) 05:36, 12 October 2020 (UTC)

I'll simply say that Kevin is super-busy and Brian and I have Kevin's slotted in as part of a comprehensive "gentle method" to doing this. Brian and I (I publicly say) like Kevin's proposal very much and it blends into ours as a #2 followed by others. We've been talking about this for days or weeks. Thank you for your contributions so far. Please consider the simple, low-bar "draw a green line" you might do in Carto for this proposal. It would be good to know if Carto will support this simple update. Really, there's a whole taxiway of little plan(e)s on this apron and this proposal is nearing cleared-for-takeoff with its gentle approach and we render parks as green lines. It shouldn't be hard. Whether a protection_class=* or still protect_class=* (gently forward, to retain compatibility while the community hammers out correctness) is wet ink right now, but it is "about there." As the proposal states, there are others like ownership=* which sort of naturally follow, maybe you've got a fair bit to say about what their right order of introduction as proposals might be. There is a "more sensible order" to rolling these out, your (Jeisenbe) input is appreciated on that topic. Stevea (talk) 19:31, 13 October 2020 (UTC)
I would prefer doing somthing like Proposal:_Named_protection_class_for_protected_areas first, since right now boundary=protected_area is not very clearly defined, and protect_class=* is messy and hard to use (I can never remember the numerical codes, especially the differences between 4, 5 and 6). But I would personally like to limit the tag boundary=protected_area to things similar to nature reserves, national parks, state parks, natural monuments and similar, rather than broading the definition. Recently boundary=aboriginal_lands was approved, so there is no reason that a new tag for other types of boundaries cannot be approved if it doesn't fit. --Jeisenbe (talk) 05:34, 15 October 2020 (UTC)
And you CAN have what you would "personally like" with the clean-up of this proposal to exclude three or so currently-not-parks in the domain of protected_area=* (whether a protect_class=* is included or not), like toxic waste dumps, military areas and special economic zones. That will tighten up the syntax to make this proposal effectively true, and together with ke9tv's proposal, we can / will have a new, comprehensive, sensible way to tag parks and protected areas. We are much closer to this goal. Stevea (talk) 09:08, 15 October 2020 (UTC)
If we follow the Wikipedia definition of protected area, this is a correct interpretation - protected area = conservation land. The named protection class proposal on the other hand includes things other than conservation in boundary=protected_area. In any case, getting rid of the numeric protect_class=* values and formally defining protected area are both something that need to happen. That still means we need to find a home for the "other things" currently in protected_area, such as superfund sites and recreation areas. ZeLonewolf (talk) 02:21, 16 October 2020 (UTC)
In light of this discussion, I put together Proposed_features/Special_economic_zone as a baby step towards elimination inappropriate values of protect_class=*. ZeLonewolf (talk) 23:06, 16 October 2020 (UTC)

Relationship to Follow-on Proposals

Text from stevea migrated here from the main proposal:

The proposal asks OSM to accept the agreeable proposition that "parks may be denoted with a simple tag of boundary=protected_area." All else in this proposal simply follows from that, as what is stated beyond that is already true and merely serve as guidelines to better achieve harmony with existing tagging. Including "good tagging ahead," nothing actually changes except for acceptance of the gentle concept that a park can be denoted with boundary=protected_area. Especially in English (and its dozens and dozens of dialects) this simply makes sense. Additional grammatical improvements to related tags such as protect_class=*, ownership=* and others already have rough sketches or proposals written and/or are in the process of multiple OSM proposal and wiki authors collaborating to build best-of-breed solutions of simple and understandable tagging schemes. This is a true OSM collaborative proposal, offering heart and vision to our community.

Re: rendering decisions are not determined by proposals on this wiki

In the current proposal text, it sounds like this proposal will immediately change how things render in certain map styles: "renderers will be recommended to render a boundary for all areas that are tagged boundary=protected_area. In Carto, this means that areas tagged without protect_class=*, or with protect_class=* values other than 1, 1a, 1b, 2, 3, 4, 5, and 6 will suddenly begin rendering on the map."

The proposal process is designed to get community consensus around how things should be tagged. It does not determine if any map styles will use the tags. In particular, the OpenStreetMap Carto map style (currently used on the Standard tile layer on openstreetmap.org) has a separate site on github where rendering decisions can be discussed. I suspect this map style is what was meant by "Carto" above. --Jeisenbe (talk) 04:41, 25 October 2020 (UTC)

Thanks for pointing this out, clearly I used a poor choice of words in that paragraph. I've revised the text to make it generic to different renderers/styles and not give the impression that a proposal directly affects renderers/styles. ZeLonewolf (talk) 04:57, 25 October 2020 (UTC)

World Heritage sites vs Protected Areas

See Zapovednik#List_of_Russian_Nature_Reserves. Areas can be BOTH an IUCN protected area AND a world heritage site (See heritage=*). Therefore, it is inappropriate for boundary=protected_area tagging to be used to indicate that an area is a WHC. Leaving this note as a reference for future work once we deal with the hard questions of protected areas. --ZeLonewolf (talk) 04:10, 24 November 2020 (UTC)

narrowing leisure=nature_reserve

Note that redefining/restricting leisure=nature_reserve is adding one more thing into proposal, while it would be better as a separate one (in my opinion).

Also, there are at least some access=no nature reserves, not only access=private (one is underground near my city), not checked is it sole case worldwide Mateusz Konieczny (talk) 17:21, 25 December 2020 (UTC)

OK, I added access=no nature reserves, that added 0.6% to the count. Severing the question of narrowing leisure=nature_reserve from this proposal is an interesting idea, but I'm not sure that's really viable. I tried to make a very simple proposal to set the definition for reservoirs, but I ended up finding that I couldn't define "reservoir" without also defining "lake" and "pond" -- and that's why we're currently discussing rivers and stream pools when all I was trying to do was come up with a definition of "reservoir"! I am all for breaking this problem down into a series of smaller proposals, but I don't see how we can reasonably propose updating "nature reserve" in the absence of defining "protected area" and describing what the differences and overlaps are. This is why I am currently chipping away at boundary=protected_area/protect_class=* with proposals such as special economic zone, hazard, and likely future ones TBD - they set the stage for boundary=protected_area actually matching the plain meaning of protected area. I am interested in hearing your thoughts as to how we might better go after all of this in the best way. --ZeLonewolf (talk) 17:51, 25 December 2020 (UTC)
If I would be making this proposal I would make it solely about inventing new tag such as protect_class=for_recreation for areas with natural or semi-natural state protected primarily for recreation purposes. I would not touch leisure=nature_reserve etc (obviously, feel free to make it in your own preferred way - just mentioning that packing many changes in one proposal has some risks). Mateusz Konieczny (talk) 17:58, 25 December 2020 (UTC)
Believe it or not, this is actually pared down from what was originally proposed! I'm of the opinion that adding new categories to protect_class makes park tagging worse, not better, because the aspects described by protect_class are presented as mutually-exclusive choices but are actually independent attributes. For example, there are parks that are created for watershed protection (protect_class=12) but also used for recreation. There are parks used for recreation that also fall under an IUCN protection category protect_class=1a-6. There are parks that fall under and IUCN protection category and also an international treaty protect_class=97-99. And so on down the line of protect_class=* values. Adding a new value makes it harder to pick the right one when there are multiple aspects theoretically expressed by protect_class=*. It is better to express something like, "this is a protected area that allows public access, camping, fishing, and hunting". For example, consider an area that might be tagged:
That neatly describes an area with no protect_class=* necessary (let's assume no IUCN category applies) - it describes a boundary, the fact I can go there to enjoy nature, the fact that it's protecting a water supply, that I can camp, I can't fish, but I can hunt with a permit. --ZeLonewolf (talk) 19:30, 25 December 2020 (UTC)

legal protection

The proposal, which is aiming to resolve country parks, says "Any property protected by law ... may be tagged with boundary=protected_area, with exceptions...". I don't think "Parks whose primary purpose is to provide public access to natural or semi-natural outdoor spaces for recreation and enjoyment" are necessarily offered any protection by law. Without this I suppose it doesn't make much sense to use boundary=protected_area. Should I need to know the legal status of a park to be able to map its boundary? (thanks, by the way, for trying to figure a way to map country parks!) TrekClimbing (talk) 07:47, 12 March 2021 (UTC)

You are over-thinking this. The fact that a piece of land is presently preserved as park land is protection enough. --ZeLonewolf (talk) 18:14, 12 March 2021 (UTC)

does leisure=park imply all is manicured?

The proposal summary distinguishes between manicured park land (like an urban city park) and undeveloped natural areas not properly tagged leisure=park. Is this the case? leisure=park describes parks as semi-natural areas and distinguishes them from national parks (fine) and one of the examples is Roundhay Park (apparently it used to be the only example photo). But Roundhay Park includes what might be described as 'undeveloped natural areas', certainly not 'manicured'. see https://www.roundhaypark.org.uk/roundhay-park-virtual-tour/The-Gorge--The-Ravine.html To me it feels like too much weight is being put on manicured here. To me, natural=wood inside leisure=park doesn't necessarily imply scultpted trees, tidied leaves, etc. TrekClimbing (talk) 08:19, 12 March 2021 (UTC)

Yes, leisure=park is intended for a human-sculpted area, hence the problem in using it for areas that are of a wild and unmaintained character. --ZeLonewolf (talk) 18:21, 12 March 2021 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Park_boundary&oldid=2516259"