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

[stevea]

On Feb 8, 2021, at 2:14 AM, David Marchal via Tagging <tagging at openstreetmap.org> wrote:
> Forestry areas can, and often do, include non-wooded areas, such as screes or glades, which are still considered part and parcel of the forestry area, not as enclaves inside it. These are to be mapped with natural=* polygons, but, as long as they are considered part of the forestry area, mapping them as an enclave in it would be erroneus 

I frequently encounter this.  My county has "Zoning" (multi)polygons (largely tagged with "landuse"), some tagged landuse=forest:  actual timber production with permits (although ACTIVE logging might not be going on TODAY, it COULD be).  Many of these have "glades" which are now mapped with natural=grassland (was landuse=meadow, though this was changed to natural=grassland unless it was actively grazed by cattle, some are and so remain tagged landuse=meadow).  (Might also be natural=scrub, natural=scree, natural=bare_rock...).  As your proposal says, these glades should not be excluded from the "forest" (as members with role "inner" in a multipolygon) though I vacillate whether to do so in some cases locally, and frequently, as doing so is essentially tagging for the renderer.  You mention this in your "Current tagging limitations (Land cover)" wiki section, with a pretty example of this, but I'm not sure what your proposal does about this (or can, as it is a rendering issue).

Here is where I get into a chicken-and-egg problem (which came first?):  how to unsnarl this as a tagging issue (as you do, without specifically saying what to do about such "glades") or as a rendering issue, which you can't really do in a tagging proposal.

I honestly don't mean to be MORE confusing about an already-confused topic, but you say (in that wiki section) "simple" (as we now tag with landuse=forest) "does not allow to model this complexity."  What does?  Your proposal?  How?  It seems your answer is "boundary=forest" (and boundary=forest_compartment).  Yet, how do these differ (and somewhat less important:  how do these render differently, if at all) from the landuse=forest tag on (multi)polygons today?  The proposal leaves these crucial issues mightily under-addressed.  (Or maybe I missed something).

Also, your wiki section Rendering overlaps with a several-month-old proposal (I am co-author) for boundary=protected_area "simplifications" (derived from a process of "semantic flattening").  The implications (on colors of rendered boundaries, for example), have far-reaching implications that I have explored as long as a decade ago and continue to deeply ponder with other Contributors (e.g. park_level) yet remain unaddressed.  (They are a bit far out there, but they do overlap with what I and others continue to try to unravel as "here's how things might smartly render in the future with regard to parks, forests, wooded areas...and here are the tagging schemes we might propose to facilitate easy-to-understand methods to do that").

And you say "landuse=forest" and "natural=wood" both "would be edited to emphasize the difference between these polygons boundaries, describing actual, physical land state, and the administrative, management-related boundaries of forestry areas/compartments."  Yet, these two wiki (forest and wood) are almost hopelessly (I AM hopeful!) confused right now:  you propose re-writing these?!

While I fervently believe that "forest compartments" are a real thing and should be treated well in OSM (as I'm certain we can, though less certain how), I find this proposal leaves a great many unanswered questions in my mind going forward in areas where I frequently tag:  on large polygons of landuse=forest where such compartmentalization appears to be non-existent.  By giving a nod to this proposal, I don't know how or what, if any, changes to my existing tagging of forests (and to some degreee, natural=wood, and to some degree, ownership and other landuse=* tagging issues) I might or will need to change, going forward with my OSM editing.  And, I'm not sure how to solve that.  I would have tended to write this into the Discussion section of the proposal, but upon reflection, I believe that as it's a topic in the wider tagging list, these questions are relevant here AND there, so "here" it is.

Forests are hard.  I think we're up for the challenge, but we haven't solved the problems of forest yet, and there are many.

SteveA