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

[David Marchal]

Deprecating natural=wood or landuse=forest seems necessary in order to avoid the proposed tagging simply becoming a seventh approach to forests: if I don't deprecate some or all of the current 6, how to avoid this proposal merely becoming a seventh? It sounds that it would simply increase confusion about this already confused. If a boundary=forestry encloses landuse=forest polygons, how should the data user understand the situation? What about landuse=forest+managed=no?

There may be a way for the proposal to not deprecate landuse=forest AND state that boundary=forestry should be used, and I would likely happily use it if I knew it, but months of edition and reflexion did not tell me how to achieve that without increasing the confusion around this already confused issue. The deprecation seems a good way to avoid that: all old approches are voided, use the new, period. Besides, most no votes were about other features; most people did not see a problem with this specific issue.

Finally, I'm aware that some people will not be happy about the proposal and could oppose it; that may be for many reasons they can argue about, or simply because they resist change. It's human, most of us resist change at various degrees; I include myself in that, as I at times heavily resist to changes I can't cope with. That being said, there is nothing I can do about it. All I can do is addressing arguments as best as I can, and then launch the vote and hope that the matter is serious enough for people to think twice about their resistance to change before rejecting it.

Regards.

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Le mercredi, 17. mars 2021 18:56, Peter Elderson <pelderson at gmail.com> a écrit :

> I still don't see why this proposal requires deprecating landuse=forest. I think that is asking for no-votes.
> "This tag has been used for forestry areas as well as unmanaged wooded areas. As a result, data consumers have interpreted this tag to mean a wooded area with no specific forestry meaning implied. As a result, this tag is effectively a synonym for [natural](https://wiki.openstreetmap.org/wiki/Key:natural)=[wood](https://wiki.openstreetmap.org/wiki/Tag:natural%3Dwood). "
> is true enough I think, and will remain true for a while, independent of the outcome of this proposal. I think the proposal should stick to the boundary portion and not portion. As far as landuse=forest is concerned, state a preference if you must (and for the record, I share that preference) but don't jeopardise the proposal by unnecessarily including the deprecation of a tag with so many millions of uses.
>
> Peter Elderson
>
> Op wo 17 mrt. 2021 om 14:50 schreef David Marchal via Tagging <tagging at openstreetmap.org>:
>
>> Hello, there.
>>
>> After an initial failed vote, this proposal was heavily reviewed and rewrited. Contested parts were removed or improved to better explain the proposal reasoning and its connections with current tagging practices (particularly the "Why not a landuse?" explaination). Comments have been addressed as much as possible without denaturing the proposal, which is now ready to return to RFC: https://wiki.openstreetmap.org/wiki/Proposed_features/boundary%3Dforestry(_compartment)_relations
>>
>> The talk page has been expurged of comments related to the first proposal, apart from the first vote comments, which are relevant to check the current proposal: https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/boundary%3Dforestry(_compartment)_relations
>>
>> Awaiting your reviews,
>>
>> Regards.
>> --
>> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>>
>> _______________________________________________
>> 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/20210317/cb468a25/attachment-0001.htm>