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

[David Marchal]

0_o SteveA, that's a pretty long text! I'll try to answer your questions, but I may have missed somes, so don't hesitate to hit harder if it didn't enter my brain the first time. ;-)

Given the last exchanges, it seems that the proposal should deprecate landuse=forest, state that natural=wood now says "this area, managed or wild, is totally covered by trees", and boundary=forestry says "this area, currently wooded or not, is managed as a single entity through forestry". What I told about water/screes/glades… is that, this way, such non-wooded areas would have no reason to keep overlapping with natural=wood entities: natural=* entities would give the physical state of the land, and only that.

I'll try to explain through ASCII art (to be quick; should what I explain be merged in the proposal, I would take time to draw nice schemas). Let's say there is a pond (│ symbol) in the forestry area, modelled with landuse=forest (─ symbol), and the pond is considered part and parcel of the forestry area. Currently, the landuse=forest and water=pond polygons would overlap:
─────────────────────
─────────────────────
───────┼┼┼┼┼┼────────
─────┼┼┼┼┼┼┼┼┼───────
───────┼┼┼┼┼┼┼┼┼─────
───────┼┼┼┼┼┼┼┼──────
─────────────────────

This mapping allows to model the fact that the pond is considered part and parcel of the forestry area. Unfortunately, this often leads to a somewhat buggy rendering, with trees symbols rendered in the water. That may be perfectly OK for wooded residential areas, but, in that case, this rendering doesn't allow to easily understand what is exactly this area: a mapper could think "It may be a mangrove or a marsh, but why does it have the wrong symbol?" or even "Hey, I'll retag that as a mangrove, that sounds better". Both cases don't seem OK. Besides, as landuse=forest is not always interpreted as "this wooded area is managed", you don't have information about management either. The proposal could be about "landuse=forest is managed, natural=wood is unmanaged. Period.", but, as I understand the situation, such proposal would likely stall or being uneffective, because most mappers who use another approach of the landuse=forest/natural=wood distinction would likely keep their approach, voiding the proposal, even approved. That wouldn't resolve the pointed rendering issues either.

Now, let's say the proposal
* deprecates landuse=forest,
* states that natural=wood says "this area, managed or wild, is totally covered by trees",
* states that boundary=forestry says "this area is managed through forestry".
Let's take the above schema, with ║ symbolising the boundary=forestry relation, and ─ symbolising natural=wood, the only remaining tag for wooded areas:
╔═════════════════════╗
║─────────────────────║
║─────────────────────║
║───────││││││────────║
║─────│││││││││───────║
║───────│││││││││─────║
║───────││││││││──────║
║─────────────────────║
╚═════════════════════╝
Now, the pond being part and parcel of the forestry area is unambiguous, and there will not be buggy rendering of trees inside it, as the natural=* entities no longer overlap.

Is the pond not part and parcel of the forestry area? Then model it this way, with the external member of the boundary=forestry relation as an outer member, and the internal one as an inner member :
╔═════════════════════╗
║─────────────────────║
║──────╔══════╗───────║
║────╔═╝││││││╚╗──────║
║────║│││││││││╚═╗────║
║────╚═╗│││││││││║────║
║──────║││││││││╔╝────║
║──────╚════════╝─────║
╚═════════════════════╝

Now the pond is unambiguously out of the surrounding forestry area, and the rendering of the trees texture of natural=wood will never be rendered over the pond.

By the way, this is one of the reasons for the proposal being about a boundary relation: AFAIK, these are always rendered as coloured lines along their members, describing their limits, contrary to natural/landuse entities, typically rendered with a texture. As I understand it (and the current rendering enforces my understanding), boundaries are about where a feature stops, not what it includes, and natural/landuse entities are basically more about the physical land state. As forestry areas may, and often do, include non-wooded features, it seemed consistent to me to use a boundary relation instead of a natural/landuse entity. I'm not saying your approach about it is wrong, SteveA, but that mine seems to give an easier way to remove possible ambiguities about whether non-wooded areas are included in the forestry area or not, while keeping the rendering of the non wooded area consistent with it being included or not in the forestry area. Besides, even if the proposal was "use landuse=forest for managed wooded lands, and landuse=wood for unmanaged wooded lands", once approved, how would you understand a plain landuse=forest entity? As "this is a managed wooded land", or as "nobody have clarified yet, if the area is managed or not"? Providing a new tagging scheme allows to remove this ambiguity: if the new tagging scheme is used, the management question has been addressed and I can retag landuse=forest to natural=wood; if the new tagging scheme is not used, the management question has not been addressed and I should address if possible.

Should the proposal include the deprecation of landuse=forest and enforce natural=wood as simply describing a wooded land, managed or not, applying the new scheme to existing landuse=forest polygons would take years. During this time, editors should warn about the deprecation, but renderers, IMO, should not, at least immediately, remove the rendering of landuse=forest. It should not happen before the overall OSM  community is aware of the deprecation and the new tagging scheme replaces enough preexisting landuse=forest entities; a quicker rendering change would most likely confuse the community, and could even doom the tagging scheme, even approved. I don't think such a brutal approach is relevant, and the proposal should favor the smooth, long term way.

As for the rendering of the borders, I proposed green because it seemed consistent with current customs, but you are right it could conflict with park/protected areas/whatever, either currently rendered or proposed. That being said, I don't see (yet) a replacement colour or dashes pattern that would still be easily understod as related to forests, while being distinct enough of parks/protected areas. Do you have suggestions?

I hope I addressed all, or at least most, of your concerns. If not, as I said: please hit harder. ;-)

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Le mercredi 10 février 2021 03:40, stevea <steveaOSM at softworkers.com> a écrit :

> On Feb 9, 2021, at 5:59 PM, Brian M. Sperlongano zelonewolf at gmail.com wrote:
>
> > If I may clarify what I'm suggesting. Right now, because of "6 ways to tag a forest", there is no way to tell whether a particular landuse=forest represents a forestry area or merely woods - with the possible exception of landuse=forest + managed=yes, but this combination is tiny. Therefore, there is no way to do a global mechanical update to replace landuse=forest with other tagging - the information simply isn't present in the tagging along. On small scales, if local mappers know which interpretation of forest was employed within a particular area, or if local mappers are aware of which areas are specifically forestry areas, or if specific naming conventions or other tagging were used on forestry areas, one could imagine local mappers performing a surgical, mechanical re-tagging within targeted areas where they have local knowledge.
> > Beyond this shortcut, mappers would simply have to make determinations as to whether areas tagged landuse=forest represent actual forestry areas or merely wooded ones. However, they could be assisted by:
> >
> > 1.  A firm, clear indication emblazoned on the landuse=forest wiki page that the tag is deprecated
> > 2.  Validator errors/warnings that indicate that landuse=foreset is deprecated
> >
> > Rather than "confused" I would say that landuse=forest is "ambiguous". By deprecating landuse=forest, we clear the confusion over which tags mean what and provide a mechanism to resolve the ambiguity over time. Each resolved landuse=forest area (either by replacing it with natural=wood or new forestry tagging) increases information in the database, steadily improving the present "confused" situation with unambiguous meaning.
>
> I agree that ambiguous is more accurate than confused, though confusion remains extant (due to ambiguity). Hence, disambiguation is a sensible strategy forward, as I have stated and do again here and now. "Increasing information in the database, steadily improving (over time)," yes. Renderers "keeping up" with these changes? We make tagging proposals here (in this list and in wiki proposals) not "design renderers" here. (I'm lost where one actually does or doesn't chase the other, anyway).
>
> Often, (I speak personally about our local data), what is known on what is now tagged landuse=forest is "local zoning plus a timber permit allow trees to be felled on this land." What "new forestry tagging" goes on that? Simply replace the tag landuse=forest with boundary=forest? And maybe someday I get a rendered green outline around that, with other rendering going away (no more darker green on forests)? Hm, OK, I consider that. Along with landuse=forest going away as an existing tag, many thousands of them. Landuse of an "area" (there is no area=yes tag required or present) being replaced by the outline of a boundary seems like "too much is being subtracted from the map," though I suppose it's possible that's merely a fiction in my mind that simply needs to fully go "poof" and disappear. Still, seeing "dark green, with trees, even leaf types being rendered in certain ways..." disappear, I'd like to see some full pipelines of tagging and rendering, though I suppose I can imagine some. I'm running the proposal through its gears in my mind and there are still some sticky shifts. At least from a Carto perspective, until my brain gets retrained to look at a lot less dark green and little-trees symbols of this kind or that kind of leaves, a great deal of green being subtracted from Carto (which now represent forests and/or trees) is ahead. I don't know how permanent that is or how much catching up there would be to do (in renderers, in brains...) during.
>
> Changing tagging standards from landuse=forestry to boundary=forest (and its newly-proposed ilk) isn't easy, as it takes this or a similar proposal (I doubt this could be done "in the wild" without wiki documentation). However, actually "making rendering follow" (landuse=forest is deprecated to the point where Carto / other renderers no longer render landuse=forest) is a tall order. Personally, I haven't seen such things happen very often where a well-established tag (especially one that dumps large, green buckets of paint with huge rendering fills) being deprecated suddenly "un-renders" but I suppose we can imagine that happening. Lots being imagined here.
>
> Lots of moving parts, too. I (kind of, sort of) perhaps shouldn't mention rendering, but as accurate rendering is actually a desirable outcome, it cannot be ignored, either. Rendering is separate from tagging proposals but sometimes (often?) does get imagined into a proposal with "suggested renderings" for the feature proposed. We have to run through the gears, especially between people who both know forests (around the world) fairly well and we who map forests in OSM (in no small measure, understanding the myriad complexities, though solvable ones, among them).
>
> There are also people who craft syntax / tagging, wiki'd proposals about these and experience "a certain amount of success at doing so," because there are better ways of doing this which pave a good road to Approval. There are also, perhaps "less ready" proposals which do not receive Approval. Getting those kinds of eyes on this takes time and their / our consideration.
>
> Let's flesh out a matrix of present tagging, future tagging and perhaps future proposed rendering, as sometimes (this time it's true) how things might render differently (being an unstated goal of this proposal might be true) make a difference in what a transition plan could be expected going forward. This could be easy (or easier than I think), this isn't so hard it can't be done. That's what I continue to see as standing in my way ahead, though it does get less murky (thank you Brian and others for clarifications): please keep hammering, it is taking better shape (for me, in my mind).
>
> SteveA
>
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging