It wasn’t my goal to put words in your mouth, as you said I did.
What I want to understand is the real impasse for the community regarding this type of proposal?
Is it because of the way OSM currently works, that you think such changes will do more harm than good?
Although it is said several times that the process will have to be gradual.
I know it wasn’t your goal, I said “it seems” (or feels) that way to me. Again, I mean no disrespect, we are having a misunderstanding.
“Such changes” have been stated here by many august contributors that “they” (this proposal we assume) are a solution in search of a problem. What I see this as a symptom of is that OSM seems to be doing a poor job presently of “explaining” (describing, denoting, showing in wiki pages, OT query maps if appropriate, taginfo quantity heft, fancy futuristic syntax diagrams with pop-out clickable branches and leaves…) these complexities to ourselves.
If we start out simple, explaining “we have multiple methods of tagging landcover now…” in a way where people can see how, and choose what is best for them (as we already have multiple methods), this explanation, visualization, denotation… can only help better tagging to evolve. By better tagging I mean perhaps something is seen in an “a-ha” moment, the lightbulbs go off in many minds, OSM heads begin to nod…this is the organic method we do a lot of things already. But for tag improvement, development, let’s start with simple stripped-down diagrams (we did this for train_station recently, and it was fruitful, with things like good use of color in a simple block diagram really turning out to be helpful and visually communicative).
I do not want this to get too specific (by me or anybody), it must “rise up from the grass roots.” What we seem to have here is some astroturf (it seems like it is grass roots but is it?) that not an enthusiastic crowd around here wants on our front lawn. I’m being kind and offering a way to “make a silk purse out of a sow’s ear,” here [1]. We need to do this work sooner or later, really, and we are mature enough (as a project) to get the ball rolling.
[1] Making a silk purse from a sow’s ear
Edit: Added footnote
Well, and I agree with you, the approach has to be a smooth transition, showing that having multiple ways of doing it, the most recent proposal, which would be this, will benefit in terms of simplicity, logic and intuition. I believe that the authors of this proposal have precisely this objective.
As you will certainly have seen over the years, the proposal always had the objective of changing a lot of tags, no one denies that.
But in order to achieve a smooth transition, I ask for the creation of a system that classifies all types of cases, based on systems created by respective entities. At this stage it doesn’t matter if you just want to create, replace values that are in other keys, delete values…
Having a system that, if put into practice, would work, we would think of a plan for a smooth transition. Certainly starting with values that do not generate conflicts only add information, then we would end up in a scenario with duplicated information, with the current OSM system there is no way to escape this. And gradually both the community and data consumers would see its usefulness.
This of course, also in a perfect scenario where everything goes perfectly obviously won’t be like that.
Even “after almost a year,” this feels to me in its most earliest of stages. I’m talking about sketching some new ways for us to “better reveal our own data to ourselves more smartly” and you are way ahead of that (nothing wrong with that, but it is much further along that what I’m saying are smart ways to build some highway towards this being much more clear and better-working in OSM’s future).
It is 0136 here and I need sleep. Thanks for dialog and please, I encourage all others reading to contribute to this, even if it is to simply mull it over as a series of steps-along-a-number-of-ways. There seem to be a lot of moving parts, many have sketched in some chalk and watercolor of good ideas.
In German language, the use of natural=wood for rainforests is in no way special, it is all Wald/wood, where there are trees in large amounts
not really, it depends on context and species, e.g. there is the word “Hain” like in Olivenhain, or there is Plantage as in Kokosplantage (although palm trees aren’t considered trees I believe, so this could be questioned)
Yes, it does more harm than good.
Data consumers today have a way to process “there are trees here”.
If you change this, it will cause problems with data consumers of all stripes. We don’t have a mechanism for change management and we don’t even have any way to contact data consumers and inform them of the change. We make changes, we wait for software to break, and expect data consumers to “deal with it”. Therefore, the path that makes OSM work the best for data consumers is not to change tagging systems that have millions of objects tagged.
There are also no real benefits to changing things. “Better tag organization” is not a real benefit, it’s just something that makes mappers that like things better organized happier. It makes data consumers sad.
When I wrote, that the proponents had to sort that out, I thought, the proposal was meant to make things easier, for mappers, for consumers; but maybe I mistook something.
Mappers and consumers working together. Yeah. That happens. At least in OSM it does.
In light of @ZeLonewolf writings, who liked @dieterdreist 's post, I was wondering if perhaps dd was really meaning what I grasped from first reading: Consumers will have to face the music, but what the heck should we mappers care?
I think Asa it’s important to think about why we map. Is it to put objects into a database only? To admire our work in a map editor? Not for me.
I map (and write map-related software) because free and open geospatial data is a good thing for humanity. Because, once we have that data, it allows people to make applications and services that make people’s lives better. So I think we we follow this to its logical conclusion, the question we should all be grappling with is how to best facilitate making that happen.
We agonize over designing tagging schemes because they directly impact the ability of data consumers to use OSM data to make those applications and services useful. We agonize over deprecation decisions because it directly impacts data consumers who are already using OSM data. Changing tagging of data that applications and services are using makes working software stop working.
The users of those applications and services don’t have any awareness of a tagging decision made on an obscure web forum that made something slightly easier to organize in the mind of a volunteer mapper. They just know that their app stopped working, perhaps even worse, because of that open map data.
Mappers are the producers, and software developers and end users are the consumer. So you have to enable both the mappers to produce data and the software people to use it.
Right now, mappers can indicate (via several schemes) a place where there are trees. If we break that understanding, we break working software, with the end result being that mappers are still able to map trees.
Hello everybody, maybe you will allow me to join the discussion. 
I tried for a long time to understand what I don’t like about this proposal and what exactly to criticize, because I have been thinking about introducing landuse=* tags for quite a long time myself.
The main drawback of this proposal is that unfortunately it is self-contradictory, and does not solve the declared problems. Also it neither makes the key=tag system clearer, nor makes life of OSM data user any easier.
The “proposal” section says that the goal is
to create a orthogonal tagging scheme that separates the tagging of functional and physical objects
Ok, it would be very nice if only it were possible. Unfortunately, this is not possible, because often the use determines the physical properties of an area, and vice versa, physical properties define possible land uses (that is the reason why natural, landuse (and surface) system sometimes seems chaotic)
So in “landcover implications” section we see:
Some current tags imply a landcover and therefore, landcover does not need to be added to these tags.
It’s indeed so, some tags imply landcover and OK, why bother to add additional tags to explicitly specify what is implied? However, it kills the idea of ‘‘orthogonality’’ completely.
For example, I would like to create a map of earth landcovers/vegetation. Can I do it now? Mostly yes. (There are a lot of white areas around the world, but Europe is mapped quite good).
How many keys do I need to process for that now? Mostly two keys are need: natural and landuse. OK, lets imagine that the proposal is approved, transitional period is over and every object is retagged. Will it be be possible to obtain landcover data from just single key? No! It will be necessary to process tags from three keys, natural, landuse, and, additionally, from the newly introduced landcover! So it’s complication, not simplification (and classical +1 standard situation) .
Maybe a landcover proposal must be much more radical to bring value to the users. In my opinion, the landcover system should cover 90% of land surface, ideally all the land. Not just objects that do not imply landcover from other tags. And it’s obviously not possible just with 7 new landcover values.
I do not (yet?) have a readymade solution either. Currently I can just share the list of landcovers which I use in my humble project. They are based on existing natural/landuse tags and their statistics. Maybe it could bring up some thoughts.
Thank You, at first I really thought with your like you’d support what I grasped from first reading, as stated above. It was only your latter contribution that allowed me a second reading: That consumers will have to face the burden, not drafters. And with not a lot to gain for mappers, BTW, IMO too. Maybe @dieterdreist can clarify on this?
Deprecating existing tags is difficult, even painful for existing OSM stack (software) developers and consumers (as Brian correctly characterizes): it breaks existing toolchains, let’s agree that’s undesirable. For producers / mappers (of data in our stack), yes, some idealized fantasy perfection structure of tagging (or subsets of these one Proposal at a time) chugs along (slowly) but is presently mired in “multiple ways we do / say things.” Developing a “perfect” or “idealized” syntax (as a mature project) is both long-term (we could…) and quite difficult, technically and socially. This sort of improvement is some of the hardest work OSM might cut out for ourselves, we shouldn’t kid ourselves. Deprecation is an uphill climb.
So long as existing software and consumers “consume” our software, changes to tagging, especially deprecations and wholesale moderate / significant changes to wide swaths of our planet’s surface in OSM are being discussed will be socially and technically (linguistically, structurally, in the sense of data science…) difficult. It does, they do, they are.
Concomitantly, OSM copes with multiple ways to do things. That is OSM.
I don’t think it’s to be written in stone. Data consumers get data for free, they also have to adapt and use data responsibly. What about a major map provider rendering a map with erroneous interpretation of the tags? That would give OSM a bad look.
Also, breaking old and unmaintained software is not necessarily and always a bad thing.
Would it be worth thinking about the question, what’s a specific thing someone wants to do with OSM data that they can’t do right now?
If you want to find “areas of land covered with trees” you could treat all areas tagged natural=wood, landuse=forest and landcover=trees interchangeably. You could also exclude areas below a minimum size to catch small groups of trees that have been “painted” using these tags.
If you want to find all the land commercially managed for timber production and landuse=forest doesn’t work because of how often it has been used to just mean covered with trees, then may I suggest produce=timber? Though many commercial tree plantations do not have the tag, at least you’ll know that those areas that have been tagged with it are used for producing timber. More areas deserve the tag, so we should probably go and map some more.
Do we have a tag that is similarly precise (if underused) and means old-growth forest?
The advantage of introducing and promoting new, more precise tags would be that it doesn’t require any tag deprecations.
Not found in TI, but certainly could live with a boreal=yes or *=boreal qualifier for old wood, not man planted. The alignment of trees in ‘reforestation’ does give it away.
There is a distinction between “virgin forest” (never disturbed by timbering activity) and “old growth forest” (trees were cut, though long, long ago). Wikipedia says “Virgin or first-growth forests are old-growth forests that have never been logged.” There are subtle aspects to this where the words chosen are important (though, many and sometimes blurry). As this (primary forest) is one-third (34 percent) of the world’s forests, let’s be careful to get this (and similar concepts, related tagging…) as correct and agreed upon (clearly) as possible. Yes, this can be difficult, especially the agreement part.
I encounter “old-growth forests”, they are around me, I hike in them, I map them natural=wood. There are additional tags on the “forest” (wooded areas) around here (like leaftype=*), too. Some land around here are timberland (landuse=forest), some are “treed farmland” (there is such a thing, farmland doesn’t necessarily mean “row crops”), some areas are simply “covered by trees” and might get natural=wood without that being primeval (but…second-growth and a substantially-treed landscape of “big trees”? Yes). Mixed in are natural=scrub, scree, bare_rock and much else.
Earth has billions (OK, 1.1-something billion is still billions) of hectares of old growth forest, that’s pretty huge. Let’s develop further tagging changes to this critical planetary resource both carefully and widely.
@stevea,@ZeLonewolf and others members, I believe we agree and have already reached the same consensus. The current proposal or similar ones that involve not only additions, but changes to keys with massive use and deprecation of many others, is currently unfeasible due to the way OSM works.
We would then have 2 ways to make the most of our time committed to this (I hope I’m not being too simplistic but rather realistic).
We continue with the content of this proposal with regard to covering information that is currently not possible, meaning the addition of values and keys.
This way we cover more information, there are no conflicts with the current way of mapping, and at most it satisfies the request to organize the content.
The other approach, I quote
Based on what I said, do you agree, disagree, or propose something else?
Keeping this at a high, almost abstract level of discussion, Proposals which deprecate tags must acknowledge that wholesale replacing existing tagging is difficult, if not impossible. In such an instance of replacement (such as this one), such a Proposal would need to include methods to deprecate in a sane, versioned, phased approach. The real world of software and databases do this, but OSM has both legacy to support and a future to grow into, and we do this in a crowdsourced way with a foundation of consensus, making this difficult at times.
As I have never (or seldom?) seen such deprecations “go easily” in OSM, it seems a more comprehensive system for deprecation, where how we do this is “regularized” in such a way that continuing, ongoing Proposals “fit into” this scheme, may be long overdue. My earlier suggestion along these lines suggests this, I was surprised it found such popularity in this forum.
On the other hand, many of us feel that any Proposal which include key:value pair (tag) deprecations are simply non-starters, doomed to failure. I do not know how to best resolve this. This seems an intractable problem in OSM, though I am optimistic that on a case-by-case basis (how we always have done things), we can continue to address the issues, despite what appears to be wider acknowledgement that we repeat much of the same difficulties again and again as we develop new taggings.
My apologies if this doesn’t seem to address the problems / issues directly. I feel a lack in my (single-handed) abilities to do that and so I continue to appeal to others to help us better shape our direction.
maybe ultimately people do not want to make tags disappear 
I have been looking at landuse=farm, and although this tag was already considered ambiguous in 2008 when I started mapping (see e.g. https://wiki.openstreetmap.org/w/index.php?title=Tag:landuse%3Dfarm&oldid=122797 ), it still had a steep growing curve until it was significantly reduced in 2017:
https://taginfo.openstreetmap.org/tags/landuse=farm#chronology
at the moment there are still 4463 of these around (1906 on nodes) and the number doesn’t change a lot any more.