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

[David Marchal]

Well, I precendently answered why I thought boundary instead of landuse: the proposal relies on the boundary=* tag because the proposal notion of a forestry area is, as I understand it, inherently a boundary. Take a forest at its broader meaning: the biggest continuous tree-covered area you can find. Typically, such forest will be divided in many forestry areas (what we call in France and Germany a forest). This division is mainly management related: if you go through a forestry area limit, the thing which change are owner, operator, applied laws and customs… But the limit itself is related to ownership or jurisdiction, not to the forest land itself; even if the trees are different on one side compared to the other, it is virtually always the consequence of the human division of the forest, and not the contrary. Consequently, the forestry area divisions are more about boundary objects (human division of lands) than about landuse objects, whose division would then simply reflect management division.

It also keeps consistency between the mapping of forestry areas mapping and the mapping of their compartments: if compartments use the boundary tag, it seems consistent to also use the boundary tag for the parent entity, as for administrative boundaries. I would happily change my reasoning if you prove me wrong, but explaination would help me.

Regarding landcover=trees: should the proposal be accepted, natural=wood would essentialy have the same meaning than landcover=trees. It seemed consequently logical to deprecate one of the two, and landcover=trees, being far less used and rendered, seems a good candidate. Not mentioning it, or letting consciously this duplicate in the wild without deprecating it would decrease the consistency of the proposal, in my opinion.

As for compartments, they are also forestry related division of land, and the current problems with them are closely related to the ones of the current mapping of forestry areas (inconsistent tagging scheme, confusions between landcover and human management, no way to map different tree stands in a given compartment, no way to map ponds/screes/glades in them…). It seemed then logical to include them in the proposal. Again, if you can explain me why it would be better to let them appart, I would listen and improve the proposal if relevant.

Regards.

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

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Le samedi, 13. février 2021 13:30, Marc_marc marc_marc at mailo.com a écrit :

> Le 13.02.21 à 12:24, David Marchal via Tagging a écrit :
>
>> deprecates landcover=trees, which is a duplicate of natural=wood;
>
> but it's fully orthogonal with the landuse forest or forestry
> and landcover=* is itself partly caused by the fact that the key
> natural=* contains natural elements and others not.
> I advise you to avoid tackling 2 problems at the same time, hoping to
> solve landuse=forest will already be huge, especially as I don't find it
> very logical to describe a forestry landuse with a boundary.
> if it's a landuse, then landuse=forestry.
> I find it just as indigestible to include the forestry sub-division
> in such an important (number of objects affected) propisition.
> 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/20210213/e211da4f/attachment.htm>