Proposal talk:Park boundary/Archive 1

From OpenStreetMap Wiki
Jump to navigation Jump to search

Viper444 proposal comparisons, potential alignments

Hi ZeLonewolf, your proposal looks great. I would be interested in merging it with the project I am working on. I am currently working with the idea of using protected area relationships to describe areas and a protected key to describe the protections. Please take a look at the latest revision and let me know what you think. I believe a lot of what you've come up with could be integrated into the protected=* tags section of my project and thought we might be able make more progress if we both work together towards the same goal. I'm in no particular hurry so it would be no pressure. Thanks Viper444 (talk) 11:12, 14 September 2020 (UTC)

Hello, Viper444. I would be happy to work together, though this too is a work in progress under active revision and well short of ready for an RFC. My impression is that your proposal in current form feels incomplete. So, at first blush it is hard to understand where we are the same and where we are different, so that we might hash out those differences. In particular, I get the impression that you are proposing to deprecate a number keys/values. It is not enough to simply state which tags need to be added, you must also indicate which tags are being replaced! We can't talk about these kinds of lands without somehow grappling with the various existing ways of tagging them and adjudicating what to do with them. Also, the bigger the proposed change, the harder it will be to gain community consensus. That is why I think it is important to limit the proposal scope to the narrowest possible thing and then go from there -- hence my focus specifically on the problems with boundary=protected_area. Standing by to talk further, and I can also be reached on the OSM Slack. ZeLonewolf (talk) 14:47, 14 September 2020 (UTC)
Thanks for looking into this. I agree that deprecating and changing a lot of things would probably not be a good idea. As far as I can tell, there should be minimal conflicts using the new scheme. It is true it is incomplete and a work in progress however I think the core logic is sound and will work to expand from.
As far as deprecation of tags; Leisure=park could remain with the addition of the park values as needed to add detail.
The areas tagged boundary=national_park and boundary=protected_area could keep their tags too(these could be included in the park_network and protected_area relationships with role of boundary)
Recreation areas would be tagged the same with the addition of the recreation tag to add detail on the recreational activities available
Nature reserves tags could remain for now with the addition of the nature area and protected tags (ideally this would be phased out of use)
I'm sure there are bound to be some conflicting tags however I believe that the new method could be rolled out and then a verification query done to remove the tags once the appropriate combination of new tags are in place.
Regarding keeping the scope narrow, I agree on this point as well. However, I think it is important to have the overall plan and core structure in place before refining the details. It essentially breaks down into Parks, Nature Areas, Protections, and Relations. It is difficult to separate them without creating ambiguity about the thing being described. With that said, I've begun creating the individual proposed feature pages in an attempt to provide clear concise detail about the use of each new tag.
As far as the relations between the two. Your use of protected_area is similar to my use of protected=* I am still up in the air as to the best values to use for the protected=* key. I'm leaning towards the different types described in the protect classifications. Combined protections or one's without a an appropriate value would then be specified using the protect_class and/or protected_object tags. Using "protected" to describe the kind protection also allows specifying protection without being limited to land (protected=water_supply, history, culture, wildlife, resource, etc.)
So yeah it would be great to collaborate. I could use some assistance with adding values for any additional kinds of park there might be for the park tag proposal. Same for the nature areas, need to go through the different types of nature areas. Viper444 (talk) 00:23, 15 September 2020 (UTC)
I'm not really sure where to start because you are steamrolling over so many other existing tagging schemes. For examples, there is natural=*, landuse=*, tourism=*, and leisure=*, all of which are in wide use. Your proposed nature=* is already covered by the IUCN categories and should be dropped. There is an extensive wiki page set on Hiking. Fishing is already defined. Etc etc.
I am not intentionally trying to be dismissive here, but your proposal is fundamentally too broad. What problem is solved by park=*? Most of the things you describe can already be tagged today. Need to define trailer park? That's a good proposal. Define hazardous and restricted areas? That's a good proposal. Find the nuggets and drill down hard. Proposals do not often get adopted and it's a very tough community to satisfy because it's increasingly rare that something exists in the world that isn't definable with current tagging. Scope, scope, scope.
Ask these questions:
  1. How is it tagged now?
  2. What is wrong with that scheme?
  3. How do you propose to tag it?
As the original author it is on you to come with something that is far enough along that it can even be collaborated on. If your proposal is to upend the way half a dozen tags are used with millions of usages, then we are not on the same page. I again say: you need a narrowly crafted scope that defines a very specific problem and proposes a solution. Right now you have something like "here is a list of types of park". Again, happy to collaborate, but the heavy lifting is on you to clearly define what you're going after. This proposal is attempting to address a single key, and I suggest you think similarly narrow in scope. ZeLonewolf (talk) 01:10, 15 September 2020 (UTC)
100% agreement, ZeLonewolf. Very well stated. "Too broad" is it in a nutshell. Stevea (talk) 01:13, 15 September 2020 (UTC)

Discussion at Talk:Key:protect_class referring here may overlap

As this proposal has a cogent exposition of extant tagging and rendering behavior of specific protect_class=* values, it was referred to at Talk:Key:protect_class as a "seed" to that Discussion. There may be some overlap in these two Discussion pages. Stevea (talk) 18:34, 14 September 2020 (UTC)

IUCN value harmony is a major thrust

It does seem that harmonizing IUCN values so they are identical in OSM is a major thrust of this proposal. That certainly has merits, but does it have downsides? Potential downsides I see are the obvious loss in the apparently "OSM-coined" values ≥7. Yet the proposal goes some distance in addressing these issues. A major question is: are potentially all of these addressed? Are we missing any? Should we discover new ones, how might we determine how they categorize and enter this proposal (or working draft, or "in use" tagging scheme)? Stevea (talk) 19:06, 14 September 2020 (UTC)

First off, the objects described in the ≥7 values probably should be describable in OSM in some way. When I went through and "assigned a home" to each of those protection levels (ignoring the "other" categories), water protection was the only one that had any meaningful amount of usage, and no other home, so that's why you see it in the table. I realize that water protection as a peer to the other categories is weak when compared to broad categories like conservation and leisure. Would it be better to have a broader category that covers resource protection? We could do something protected_area=resources. That might quell the slippery slope concern. Of course then we will probably want tags like resource=water and so forth.
Also, I deliberately intend for this proposal to cover protected areas and not restricted areas. So, I am explicitly ignoring military areas (already defined elsewhere anyhow), contaminated areas, security areas, demilitarized zones, and any other sorts of areas that are defined for the primary purpose of keeping the public out.
In any case, it is a deliberate goal that anything that was describable with the 7-99 scheme should be describable if this proposal is adopted. ZeLonewolf (talk) 23:43, 14 September 2020 (UTC)

Protection link to admin_level

There is a need to "link" a protected area to the specific government (city, state, province, national, etc). Here is a comparison of possible ways to do this:

Scheme Pros Cons
Use admin_level=* directly on the object.
  • Inconsistent with usage in heritage=*
  • admin_level=* is closely associated with boundary=administrative and some may feel that overloading this tag should be avoided.
  • I'm not sure of all the subtle topological aspects of this, but it may be possible that some renderers associate an "inner" admin_level=* polygon with "punching a hole in" an enclosing polygon with the same value. If true, this would be a "show-stopper," preventing use of this tag in this context. Stevea (talk) 23:26, 14 September 2020 (UTC)
Define a new semantic on protected=* tag in order to hold a corresponding numeric value from the admin_level=* numbering scheme (of the enclosing administrative boundary).
  • Has overloaded meaning in the English language
  • More heavily-loading (overloading?) this key is not necessarily a Pro.
  • Inconsistent with the naming convention for protected_area=*, protection_title=* and protect_class=*.
  • Already an existing tag, but with text values, not numeric (only) as in this proposal. This tag is mostly used in Massachusetts, USA. We'd have to be quite careful here between alpha and numeric values. Stevea says "Yes, has more Con than Pro features. Double-edged sword, be careful."
Create a new protection=* tag in order to hold a corresponding numeric value from the admin_level=* numbering scheme (of the enclosing administrative boundary).
Create a new protection_level=* tag in order to hold a corresponding numeric value from the admin_level=* numbering scheme (of the enclosing administrative boundary).
  • Inconsistent with the naming convention for heritage=* and capital=*.
  • Requires a new tag to be defined.

Any choice requires breaking SOME naming convention, so it comes down to "a coin-toss among these vs. some better arguments." As admin_level=* either could or does have additional consequences to meaning or rendering AND we wish to strictly limit this to "protected areas," using the first possible tag is "put on the shelf" (for now, perhaps some "punch holes" evidence / cautions arrive). The second, protection=*, IS consistent (by being more morpho-syntactical) with heritage and capital, though I think "too single-morpheme" (conveying protection without any concept of level, yet it DOES include the concept of level). This makes the choice of protection_level=* easier, so I now lean towards that. Other input regarding this choice remains welcome. Stevea (talk) 22:47, 16 September 2020 (UTC)

Does admin_level "punch holes"?

Is there evidence that overloading admin_level on protected areas would "punch a hole" in administrative boundary relations?

Some test examples to guide us:

ZeLonewolf (talk) 00:03, 15 September 2020 (UTC)

This was once explained to me (satisfactorily, but it didn't "stick" in my long-term understanding) by Frederick Ramm (of Germany). I'm sure many others besides him understand how this works, but even with what I consider fairly advanced mathematical / topological knowledge on my part, the aspects of OSM as a database plus how renderers do MANY things to those data makes me unable to fully expound on this. I'll dig through some old emails and look, maybe others can point to good pages on either multipolygons (and inner and outer membership consequences) or maybe admin_level itself (these sub-topics aren't readily apparent to me). Stevea (talk) 00:08, 15 September 2020 (UTC)

water_supply Protection Category

The tag protected_area=water_supply is proposed in order to cover all of the described usages of protect_class=*.

Alternative Pros Cons

Use protected_area=water_supply to describe water supply protection areas. If other natural resource protection categories are defined in the future, additional values can be added through the proposal process or via de facto usage.

  • Requires only a single tag to describe a water supply protection area
  • This was the only natural resource protection category defined in boundary=protected_area that had a non-trivial level of use
  • Water supply protection is not covered in the IUCN categories, however, most of the other protect_class=* 11-19 defined categories is likely already satisfied under the IUCN 1a, 1b, and 2-6 categories.
  • Opens a "slippery slope" to the need to define other types of natural resource protection areas under protected_area=* and may muddy the waters on this proposal moving forward.
  • Water supply is a narrower scope than "leisure" or "conservation".

Use protected_area=natural_resources to describe general natural resource protection areas.

  • This value is clearly at a peer scope to the other proposed protected_area=* values.
  • Likely leads to an additional tag to be defined, such as protected_resource=water
  • It is not clear that there are actual examples of land that does not fit into the proposed four categories.

Update: The IUCN Category VI reads, in part: 

Primary objective: To [...] use natural resources sustainably [...]
 Secondary objectives:
 - To promote sustainable use of natural resources
 - To promote social and economic benefits to local communities where relevant

Therefore, water supply protection areas are properly categorized under IUCN Category VI.

Former protected_area proposal

Two values of protected_area=* were proposed here: conservation and leisure. It was determined that as protect_class=* with values 1a, 1b, 2, 3, 4, 5 and 6 "means" value conservation, and an absence of these tags "means" value leisure, these two values can simply vanish.

Summary of Tagging Changes
Tag Action Description
protected_area=* Existing Key, expand semantics to include parks This key defines the type of protected area defined by this boundary. For conservation land, protected_area=conservation is used in conjunction with protect_class=* for values 1a, 1b, 2, 3, 4, 5 and 6. For leisure see protected_area=leisure.

The table below lists the two possible values for the new protected_area=* key, should this key be adopted. While many protected areas have multiple uses, mappers should choose protected_area=conservation if the area meets the IUCN definition of conservation land. Note that IUCN Category VI covers a wide variety of protected areas including protection of natural resources. For all other types of protected open space areas, mappers should choose protected_area=leisure, indicating a protected area set aside specifically for the purpose of human recreation and enjoyment rather than for conservation reasons.

Values for protected_area=*
Value Action Usage
protected_area=conservation New Value Indicates land protected for conservation reasons. When used, this tag is combined with protect_class=* values 1a, 1b, 2, 3, 4, 5 and 6, which correspond to internationally-established IUCN Protected Area Category values with the same values (as Roman numerals).
protected_area=leisure New Value Indicates land protected for public recreation or enjoyment. This tag may be combined with an appropriate leisure=* tag to further indicate the type of leisure activity for which this land is protected. If the land is used for multiple types of leisure, mappers should separately tag each leisure area (polygon) within the protected area with the appropriate leisure=* tag (See: tagging guidelines).

Former protection_level proposal

A new key protection_level=* was proposed here. This key's name isn't permanent, at least one other key with a different name (but having the same usage and meaning) was discussed in early drafts of this proposal.

Summary of Tagging Changes
Tag Action Description
protection_level=* New Key This key defines the level of government that has designated the land as protected. The value is a number between 2 and 11 which matches the admin_level=* value of the protecting government entity. When the protection status of the land is not government designated (e.g. land owned by a private conservation organization), this key is omitted. This could facilitate rendering of protected areas (or perhaps their boundaries/edges) to match their admin_level=* value with different colors or dashing/hatching.

It was decided that the key protection_level=* falls more under the realm of "ownership" than a discussion about parks and protected areas per se, though not exactly the syntactic purview of ownership=*. It may very well be that protection_level=* makes its way into a discussion of ownership and eventually becomes part of a proposal to re-work that key to be more comprehensive regarding ownership of parks and protected areas.

protect_object

protect_object

Original text for classes 11-14:

I moved this out of the proposal because protection_object=* has very little usage (2K total, many of which are spurious, e.g. 400 usages of protect_object=recreation!) ZeLonewolf (talk) 21:53, 4 October 2020 (UTC)

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Park_boundary/Archive_1&oldid=2516267"