[Tagging] Feature Proposal - RFC - boundary=forestry(_compartment) relations (Was "Feature Proposal - RFC - boundary=forest(_compartment) relations")

Bert -Araali- Van Opstal bert.araali.afritastic at gmail.com
Sun Feb 14 18:46:22 UTC 2021


Good point, I can support that, introduce a new boundary value.  Leaves
us with a discussion if the value "forestry" and the examples given are
discriminating + from a practical and standardization point of view is
it feasible to find a boundary value that can be used for similar
natural areas with management policies or resource utilisation like
wetlands ?

On 14/02/2021 21:30, Brian M. Sperlongano wrote:
> On Sun, Feb 14, 2021 at 12:50 PM Bert -Araali- Van Opstal
> <bert.araali.afritastic at gmail.com> wrote:
>> As far as forestry, as a process, is concerned it's general characteristics can be defined with an (already) defined protection class: f.i. 15 - as a resources-protected-area or some of the nature-protected-area classes. I am perfectly happy with the definitions of the protection classes as they are not specific, neither discriminating, which, to my opinion is not the case if you specifically are going to use the term "forestry".
>> This leads me to my positive support of this proposal as it attempts to deprecate landuse=forest and all its commotion that has grown around it in competition with natural=wood. That I fully support but replace it with a non-discriminating, already existing but hardly used value like protect_class=15. I propose to make a specific wiki page for protect_class = 15 and add attribution for a specific sector or use case.
> I would push back in the strongest possible terms against increasing
> the use of "invented" values of protect_class (anything outside of 1a,
> 1b, 2-6).  The 1a,1b,2-6 values are based on IUCN (International Union
> for the Conservation of Nature) protected area categories, which
> categorize the management practices of land used for nature
> conservation.
>
> However, the other values (1, 7-99) were pure inventions by early wiki
> authors and have absolutely no basis in any classification system, are
> poorly defined, and use numbers rather than plain-English words.  In
> addition, the standard renderer has rejected the rendering of bespoke
> values of this tag.  The number of usages of protect_class=15 is so
> small (<100) that we should not consider this a meaningful adoption of
> this tag by the community.
>
> I should also note that in the last several months, a series of
> approved proposals have formally deprecated protect_class values 16,
> 23, and 25, replacing them with plain-English tagging for hazards,
> special economic zones, and military bases respectively.  In those
> votes, there was very strong support for abandoning this invented
> numbering system.
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20210214/d76b4c5e/attachment.htm>


More information about the Tagging mailing list