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

Adam Franco adamfranco at gmail.com
Tue Feb 9 14:56:14 UTC 2021


>
> 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?!


Current tagging of landuse=forest is "hopelessly confused" with natural=wood
because some mappers use landuse=forest mean "this is a forestry area" and
others use it to mean "there are trees here" (land cover). Common rendering
of landuse=forest with tree-fill makes usage of landuse=forest problematic
for mapping "this is a forestry area" because forestry areas are not
necessarily all covered in trees -- those trees may be harvested, there
will be roads, lakes, scree, and other non-tree-covered land-areas within a
"forestry area".

This proposal to add boundary=forestry and boundary=forestry_compartment
does not directly disentangle landuse=forest from natural=wood, but it
*does* provide new, unambiguous tagging for "this is a forestry area where
operator, ownership, and associated rules apply" that does not also imply
anything about land cover. Without additions like those being proposed,
there is simply no good way to tag managed forestry areas in a way that
won't be broken by future mappers who don't want to see trees covering
lakes.

If this proposed tagging takes off and existing landuse=forest that is
trying to map managed forestry areas gets updated to this more precise
tagging, then landuse=forest can stop trying to do double duty as a
designation of managed forestry areas and just be what it is in practice --
some version of "there are trees here, maybe the hand of man is involved".

The proposal has been greatly revised over the past months and there are
still important discussions happening in Talk:Proposed
features/boundary=forestry( compartment) relations
<https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/boundary%3Dforestry(_compartment)_relations>
about how this tagging would be used in particular countries and
situations. For example, the most recent edit proposes that US National
Forests are not themselves boundary=foresty, but instead their *Activity
Silviculture Timber Stand Improvement* and *Timber Harvest* areas use this
new tagging while boundary=protected_area stays in place for the National
Forest as a whole. Feedback by folks knowledgeable about forestry practices
in the US and elsewhere would be helpful here.

On Mon, Feb 8, 2021 at 9:04 PM stevea <steveaOSM at softworkers.com> wrote:

> 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
> _______________________________________________
> 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/20210209/cafbfcc3/attachment-0001.htm>


More information about the Tagging mailing list