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

[stevea]

On Feb 9, 2021, at 10:32 AM, David Marchal via Tagging <tagging at openstreetmap.org> wrote:
> The proposal rely on the boundary=* tag because the proposal notion of a forestry area is, as I understand it, inherently a boundary.

Not necessarily, and while that feels more like my opinion, I offer this fact:  Right now, a "polygon of trees" is how millions (certainly many, many thousands) of "forests" exist in OSM, without any border / boundary necessary or extant.  That has been a working definition for virtually OSM's entire existence, there is no "inherent" edge of "where the forest begins and ends," more like "trees are here," meaning they can be cut down, up to the extent of the (multi)polygon, no boundary necessary.  Though I freely concur:  in some places, this is a "hard boundary" in a legal sense.  There are also "trees are here, they CANNOT be cut down," I tag those with natural=wood (what our Forest wiki calls "Approach 1").

However, for areas which are distinctly forests with legal limits of "where timber is permitted to be felled," yes, that "hard boundary" does seem to need some sort of tagging scheme.  Maybe that's "the entirety of all of these trees," maybe that's "only these compartments within the greater context of these trees do designated as fellable, the others shouldn't be cut down," though I wouldn't include those in the polygon of the forest in the first place, "more correctly" considering what Approach 1 and I say to tag with natural=wood.  I see how David has quite thoughtfully crafted this proposal, with great listening skills to address the concerns of the community.  But I still have difficulty parsing what happens to existing landuse=forest and natural=wood (multi)polygons should this proposal become Approved.  Would we (and renderers) really re-write our understandings (and display rules) for landuse=forest and natural=wood?  How?  I can't imagine wholesale replacement of existing landuse=forest and natural=wood with this proposal:  it would be replacing confusion with confusion-squared (or cubed).  Yes, it's entirely possible I'm very slow-on-the-uptake here, not fully understanding either the proposal or how it might deprecate or even slightly affect existing landuse=forest and natural=wood tagging.  I'm doing my best.

> 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.

Um, you had me until near the end:  "human division of lands" and "management division" (of lands) seem identical to me, not distinct as you seem to be making them here.

> Besides, landuse and natural tags are essentialy understood by mappers and renderers as related to features that should never overlap.

You are mistaken, this is false.  There are many examples of this, I encounter them frequently, they can offer either challenges or headaches (depending on your perspective) to both mappers (OSM authors) and renderer-writers.  One frequent example is what we have a lot of around here (my county, despite having over a quarter of a million people, is over two-thirds covered by trees):  areas of residential landuse which are substantially covered by trees.  Because it is seldom if ever true that, say, a single-family home also has a timber permit, the two tags that make sense here are not landuse=residential + landuse=forestry (impossible, as the key can only have one value), but rather landuse=residential + natural=wood.  There are vast numbers of these surrounding me.  Sometimes, (if the polygons are certain magic sizes relative to one another, I have gleaned), Carto will render "gray (residential) with little trees superimposed" in a pleasing manner that visually conveys "wooded residential."  But sometimes, even with careful tagging, not:  these might render all-gray or all-dark-green-with-trees.  Again, from what I have learned from principal author of Carto user:jeisenbe, this depends on relative sizes of the polygons to determine how the renderer decides whether to "double-render" (and so is renderer-specific).

> There may be very good reasons for this to happen, but where it happens, renderers tend to merge their rendering, and mappers tend to re-draw the polygons to remove the overlapping.

Again, given what I have seen, mapped and experienced for at least a decade in OSM, this is not so.  I mean the part of "mappers tend to re-draw the polygons to remove the overlapping."  If anything, where overlapping landuse=residential and natural=wood DO overlap, I might offer some careful effort to actually achieve the "double rendering" of gray-plus-trees.  Perhaps that is just me, but I don't think so (my fellow mapper doug_sfba, with whom I share such landuse / landcover mapping in Santa Clara and Santa Cruz Counties in California) agree that the "double rendering" is a pleasing effect to achieve if we can.  We don't believe we are tagging for the renderer as we do this, we believe the renderer is correctly double-rendering a "double-landuse/natural" truth.  The reason is:  these really do exist, and it is nice to display them.

> People like simple things, and have trouble when a given land could have multiple uses, as it is the case with forestry areas (wood production, ecological protection, public enjoyment…).

If that is true, I want to see ALL of those things rendered (which means they are tagged well AND rendered well), not some arbitrary choice of only one of them.  This isn't perfectly true today (tagging challenges remain, rendering challenges remain...) but it has gotten better as renderers (especially Carto) have improved.

> Renderers, on the other hand, essentially understand these as "render a texture in it". Should the proposal suggest landuse=forestry or another one, chances are people would continue to tag glades, screes… as enclaves in the forestry area, and renderer would keep rendering correctly tagged glades or screes by mixing their texture with the forestry one. Such a change would deeply impact tagging and rendering customs, and I could not bear such a proposal; that would simply be too huge a change in OSM for me to manage. I want my proposal to be approved, yes, but, in these conditions, the proposal discussion would be intense and would very likely stall after a while, with no consensus, and that would make another burried proposal. I want to help OSM and have this forestry area notion accepted and have a tagging scheme, but I don't wan't to lose days in sterile debate.

While nobody wants to "lose days," I believe it important to take the time that the community needs to fully understand the impact of a proposal, INCLUDING its impact(s) on existing tagging.  I simply do not have that clarity right now, especially as I identify at least one incorrect assertion in your most recent post here (right above in the previous paragraphs).  I do not say this to offend, nor to be slow-on-the-uptake, and I DO want to see a more-worldwide treatment of forest(ry) be properly modeled in OSM, with your proposal being what appears to be a carefully crafted method to do that.  But again, I do not see how its approval changes (or does not change) existing "Methods 1 through 6" tagging of landuse=forest, which candidly, is a snarled mess of confusion right now.  That clarity seems a fundamental part of this proposal, yet it remains missing.  These mail list posts help, I appreciate our community's participation and patience.

> Why the proposal doesn't touch the landuse=forest/natural=wood dispute? The wiki pages of these tags would be changed, yes, but only because the proposal proposes to consider them as related to the physical state of the land, and the proposed boundary=forestry(_compartment) is about management issues. That being said, the question is legitimate; answer follows.

Because (in my mind, Method 1's explicit tagging and the tagging practices of millions of other mappers) "the physical state of the land" where it is tagged landuse=forest is MORE than that (it isn't simply "trees are here," as natural=wood denotes, it is "trees are here, AND they can be felled as timber"), the "wiki pages to be changed" couldn't be changed without a wholesale re-definition of the semantics they convey.  Well, that's true of landuse=forest, I'm not sure how true it might be of natural=wood:  you are asking me to imagine a re-write of these wikis without seeing them, but only imagining them.  I don't think that's an effective way to make a proposal (by asking us to imagine HOW other pages which are affected by the proposal WILL get re-written, without re-writing them, or even saying how).

> It is proposed to keep these tags because they are widely used and because I found no reason to choose one to favour and to deprecate the other. Yes, many mappers use them indifferently,  but I did not want to start again the eternal debate about their respective meaning. In fact, I hoped that the proposed tagging would, after a time, extinguish this flamewar: many mappers consider the difference lies in the question "Is the wooded area managed or not".

On this last point, we agree.  That's me and the portion of mappers who choose to interpret landuse=forest with Method 1.  Now, how do we address those who choose to interpret with Methods 2 through 6?

> Should the proposal pass, it would essentially obsolete this question, and it is likely that one of landuse=forest/natural=wood would disappear, but I could find no relevant argument to choose the one to disappear. I simply thought users would decide through their tagging customs. Including the deprecation of landuse=forest in the proposal makes sense, as its principal meaning greatly overlaps the proposed notion of forestry area, but would likely spark another hot debate between people who use landuse=forest only for managed wooded lands, and people who understand it differently. This has been done, again and again, with no consensus. Circumventing this debate would simply let the mappers, by their daily tagging customs, decide in the end which tag we should deprecate. Again, I don't want spark another sterile debate; proposing new notions which would, in the end, void this debate seemed a perfect way to prevent another sterile flamewar, while allowing this essential notion of forestry area to be mapped with an approved tagging scheme.

I admire (and salute!) your intentions and great patience (especially in the proposal's Discussion sections).  However, ADDING a new, totally different tagging scheme to a distinctly confused aspect of cartography in OSM is (in my opinion) not going to cause confusion to simply "fall away through disuse" in the future, being supplanted by the new scheme.  We've seen that this does not work well, and until proven or very strongly asserted otherwise, I can only characterize it as wishful thinking.  I do not want to sound harsh, discouraging or mean as I type those words, I am being realistic and offer my perspective as a longtime OSM mapper keen on "better syntax / tagging emerging to replace problematic syntax / tagging."  (And what I have seen happen in such circumstances, even as I and others craft what we believe are better syntax proposal to address real issues in OSM's current tagging).

> So, now the issue has been raised, let's ask: ladies and gentlemen, should the proposal deprecate landuse=forest, as Zelonewolf asks, and leave natural=wood for describing a physical wooded land, letting boundary=forestry tell the area being managed or not?

If I saw a step-by-step plan of how the proposal proposes we do this, I could answer this better.  If the answer is "by attrition, slowly, simply by the 'now older' tagging falling away somehow," then, no, that would simply be "confusion-squared" (or cubed).  If the answer is "a large-scale bot-oriented re-tagging is proposed..." that is not (currently) part of this proposal and has its own issues that the community would need to address.

> SteveA: is your question about compartments "Are compartments mandatory in a forestry area, even a huge one?"? If so, the answer is no: though compartments are more and more useful as the size of a forestry area increases, they are not mandatory at all; if there are none in the forestry area, just don't map any. As for the proposed rendering, I merely suggest one; as the proposal is about boundaries and not physical land state, drawing only the borders of the forestry area seems consistent, as is the green colour. Nevertheless, as the section title says, these are only rendering proposal; I have not the needed rendering experience to decide, and I think I don't have to, as it is out of tagging proposal scope. Finally, about the modelling of glades/screes/water…, the proposal allows to consider them part of the forestry area (i.e. inside the borders of the boundary=forestry relation), while keeping them as outer natural=* entities of the surrounding natural=wood. That would both fix the rendering issues I raised, and their inclusion in the forestry area, if the forestry manager considers them as part and parcel of the forestry area.

David, again, your patience and expertise are deeply appreciated.  I'm certain that "compartments are optional," as we (in the USA, in California...) don't seem to have these, though they certainly do exist elsewhere.  I agree that "just don't map any" is a perfectly workable solution, as "some forests are 'just' forests, some forests are managed with more high-granularity."  I DO have a problem with "the green color" (on boundaries) as it conflicts with the active proposal that Brian S. and I have co-authored for Park boundary [1]:  if both of these proposals were to become Approved, seeing a "green boundary" rendered couldn't be easily distinguished between "park boundary" and "forest boundary."  AND, as I alluded earlier, as there is a separate not-actually-now-posited proto-proposal for "park_level" [2] which would assign various colors to boundaries of parks from their management admin_level (not a novel idea, I've been shopping this around for at least eleven years).  As I now think of it, perhaps both color AND "dashing" (as admin_level does it) could be useful semiotics for park_level.  Still, we seem to conflict on "boundary, rendered green" between park and forest in two separate proposals, that's problematic.

I agree that boundaries are "independent" of "what is in the forest," as while forestry is largely about trees, sometimes what is inside of the boundaries of a forest are glades, clear-cut, grasslands, scrubland, bare rock, scree, water and potentially other "not trees" landcover.  I think by "physical land state" you mean what is given the wide moniker "landcover" in OSM.  That said, what you say about "keeping them as "outer natural=* entities of the surrounding natural=wood" confused me:  I don't believe OSM's multipolygon construction rules allow an inside-the-outer-polygon to be assigned a role of anything besides "inner" (thus excluding it from the semantics of the tag on the multipolygon) - certainly not role "outer" if it actually geometrically inside of the enclosing outer polygon.  So while I'm excited to consider your "fix the rendering issues I raised," I don't know how that would be achieved.  Perhaps specific examples in the proposal could address this.  Again, thank you for all the work you are doing on this proposal, for listening and responding to community concerns and questions and for the patience that this takes.  Proposals are NOT easy, especially when they "fix" (or propose to "fix") a messy, existing paradigm.

SteveA

[1] https://wiki.osm.org/wiki/Proposed_features/Park_boundary
[2] https://wiki.osm.org/wiki/Key:park:type#park_level.3D.2A