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

[stevea]

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