Proposal talk:Landcover proposal V2

landcover=water

Resolved: We removed the water value from the proposed values

I see no benefit at all of landcover=water and starting deprecation attempt of natural=water Mateusz Konieczny (talk) 17:10, 10 February 2023 (UTC)

@Mateusz Konieczny: The main problem with natural=water is the natural key. This gives the impression that something needs to be natural, but what is natural is very subjective, does it need to live? does it need to be naturally formed? does it need to be unmoved from its original position? All these questions are unanswered. And through the years have lost there meaning.

When does natural water become unnatural? maybe desalination, or water reclaimed from sewage? Water is not living, and it inertly moves. All these questions and confusion would be resolved if we just started mapping water objectively. And that’s what we propose.

Adding landcover=* gives room to reassess what natural means.

So, to recap: the benefit of landcover=water over natural=water is reduced confusion and increased objectivity.--Tjuro (talk) 18:22, 10 February 2023 (UTC)

"This gives the impression that something needs to be natural" - well, that is false impression. For fans of key definition purism, doomed to failure in OSM: focus on fact that water itself is natural. And "landcover" still gives false impression that it is only for water covering land - it maybe also for canal bridges and water covering concrete and so on Mateusz Konieczny (talk) 19:16, 10 February 2023 (UTC)

"All these questions and confusion would be resolved" - it is already resolved and documented at natural=water Mateusz Konieczny (talk) 19:17, 10 February 2023 (UTC)

I think in case of bodies of water we can just use water=*, without natural=water, landcover=water and the like. Just treat water=* as a top-level tag, and that's it. -- Something B (talk) 10:10, 11 February 2023 (UTC)

I think only a few bodies of water can be seen as landcover. E.g. I know some squares with decorative water bodies, no more than 20 cm deep. You could say that's water as a landcover. Mostly, there is either land or water. Water flows by nature; therefore it belongs in the natural=* key. I seriously think landcover=water should be left out of this proposal, to increase its chances.--Peter Elderson (talk) 16:07, 11 February 2023 (UTC)

@Pelderson: We also came to this conclusion. We therefore removed it --Cartographer10 (talk) 17:41, 11 February 2023 (UTC)

wiki is descriptive

Resolved: We removed updated landuse definition as for the reasoning given by Peter below

Redefining landuse=* is proposed here. Either it is more accurate than what is there now and can be edited now, or is it attempt to declare actual usage of landuse=* invalid and in such case not changeable by proposal Mateusz Konieczny (talk)

@Mateusz Konieczny: We don't declare the current usage invalid. Compared to the current 1 sentence definition on wiki, we want to sharpen it. By doing it in the proposal, we just make sure that everybody agrees. We also use it to empathize the difference with landcover. We can indeed also just update that one sentence landuse definition. We thought this was just a more formal way --Cartographer10 (talk) 18:08, 10 February 2023 (UTC)

If you update the definition in the landuse key wiki it will make it clear that some values are outside the logical definition - which is true. But de facto the key is massively used for non-functional values (landcover). Which means you also should objectively describe the actual use outside the definition. I do think that is better than the current intentionally vague sentence --Peter Elderson (talk) 22:02, 10 February 2023 (UTC)

@Pelderson: Thanks for this suggestion, you are right. We will adjust the proposal and remove the landuse definition refinement.

landcover=bare_rock

Unresolved: We deprecated natural=bare_rock in favor of landcover=bare_rock

What is benefit of duplicating natural=bare_rock? Mateusz Konieczny (talk) 17:15, 10 February 2023 (UTC)

@Mateusz Konieczny: We didn't want to deprecate to much but I am fine with deprecating natural=bare_rock because bare_rock is a perfect example of a landcover. --Cartographer10 (talk) 18:36, 11 February 2023 (UTC)

It is also even more perfect example of natural feature, and natural=bare_rock not always are actually covering land. And duplicating tag without a good reason and what worse risking that some people will start claiming that natural=bare_rock is to be avoided or should be double tagged is not helpful at all Mateusz Konieczny (talk) 11:55, 12 February 2023 (UTC)

Rocks on the ground might be literally the most natural things that exist. --ZeLonewolf (talk) 20:08, 15 February 2023 (UTC)

I agree, natural=bare_rock is very good fit where it is. The proposalshould definitely not go willy-nilly deprecating other stuff which is currently working perfectly fine in order to produce arguments "well it fits well in our new category too so let's steal it so we have a fodder for new top-level tag to show". Such thinking alone should be a reason to reject proposal indeed! Instead, the proposal should always attempt to do minimal changes needed to better clarify the situation, and thus should only deprecate things that are completely wrong, incorrect, ambiguous and misleading in their old place, and are much clearer and better defined and non-ambiguous in a new hierarchy. And even that only in cases if the benefit gained by such improved clarity significantly outweighs the transition efforts and problems introduced by such deprecation! In other words, if for example only landcover=grass is really needed to define special use case to distinguish it from existing landuse=grass, landuse=meadow, natural=grassland which would not suit some purpose, than the proposal should only define that one new tag instead of trying to be a model for solution in search of a problem. --mnalis (talk) 19:53, 28 March 2023 (UTC)

Tag natural=meadow is quite rare, You meant landuse=meadow? I'd say, the usage speaks tons --Hungerburg (talk) 23:45, 28 March 2023 (UTC)

@Hungerburg: Yes, I've meant landuse=meadow, sorry for the lapsus calamy, it is corrected now. --mnalis (talk) 15:18, 5 May 2023 (UTC)

Note, I do not consider it as resolved in way that makes sense and this by itself is enough to reject the entire proposal for me Mateusz Konieczny (talk) 13:06, 19 March 2023 (UTC)

landuse=* MUST contain landcover=*

Resolved: We removed the recommendation to map "must contain" landcovers on respective landuses.

I find sentences like "This means that the landuse must have a specific landcover." too strict. I can imagine wanting to tag a forest area (i.e. landuse), but not wanting to go through the trouble of micromapping all little details of where exactly the trees (landcover) are and where not. Now it reads that that isn't allowed and one should add landcover=trees to the whole area, which can be incorrect. Wouldn't it be better to leave out the tagging of the exact landcovers? To me no data (i.e. it is a forest area but unknown where the trees exactly are) is better than incorrect data (i.e. this forest is full of trees, which actually is not the case). Same applies to other examples of landuse and landcover of course. --Herrieman (talk) 18:42, 10 February 2023 (UTC)

@Herrieman: The point of "must contain" is to have something below implication. so, for a landuse=forest you would need to have trees. For a landuse=residential some houses are needed. But it was not intended to come over as a mapping requirement for mapping landuses/landcover. So, I will edit that to make it about the functional requirement and make it clear there is no mapping requirement. --Tjuro (talk) 18:50, 10 February 2023 (UTC)

@Tjuro: That makes sense, thanks for clearing it up! --Herrieman (talk) 18:55, 10 February 2023 (UTC)

Lack of a clearly defined problem

The proposal lacks a problem statement. Specifically, what is not possible now with the current tagging, and what will become possible with the new tagging? Since we are asking all data consumers of these tags to change, I think you need a really strong case as to why the status quo is unacceptable. --ZeLonewolf (talk) 20:11, 10 February 2023 (UTC)

@ZeLonewolf: Can you please elaborate why the current rationale is not a good problem statement? This proposal better separates landuse and landcover. It is mixed up now which is confusing for new and even experienced landuse mappers. So with this proposal, we try to set the basis for a logical and clear tagging scheme that will benefit OSM in the future. So the biggest problem is that the current tagging scheme is confusing and not consistent. In the short term, this indeed might result in some changes for data users. In the long term, mapping becomes easier for mappers and data consumers get a more consistent and logical tagging scheme --Cartographer10 (talk) 21:51, 10 February 2023 (UTC)

The point is that landuse is increasingly abused for micromapping e.g. every 2m² of Flowerbed are beeing tagged as landuse although the whole of the area is used for residential. landuse is one of the largest sources for "tagging for the renderer". As its getting abused people try to add even more contradicting values for landuse like flowerbed etc., grass has been mostly disputed since day 1 as its NOT a use. I am very much in favour of fixing this with landcover, and its more of a long term goal as a revolutionary change on day 1. Flohoff (talk) 23:03, 10 February 2023 (UTC)

"grass has been mostly disputed since day 1 as its NOT a use." I don't disagree with that myself. At least in theory. But really it's a use if people say it is and use the tag that way. It's not like the various landuse tags are suppose to be based on official, real world landuse standards either. Like no one uses landuse=residential in an accurate way that represents how landuse is in real life. So why does it really matter if grass isn't "technically" a use or not? --Adamant1 (talk) 11:32, 12 February 2023 (UTC)

"Simplify tagging for beginning mappers and data consumers." is untrue as it will make job worse for data consumers. Or in the best case it will be as it is nowadays - only for new data consumers arriving few decades in future after this tags disappeared or replaced current tagging.

@Mateusz Konieczny: (I think this is your comment, right?). Can you please give arguments why you think this proposal will make it less clear for data consumers? Please read the rationale paragraph Separating Functional and Physical Objects where we describe the main benefit. Also see my reactions below --Cartographer10 (talk) 13:23, 12 February 2023 (UTC)

"why you think this proposal will make it less clear for data consumers" - that will not get worse. I am thinking about entirely separate issue: of need to reconfigure running software because now feature XYZ is tagged differently. I bet that if you would ask data consumers whether they like renaming tags to achieve greater purity in key definitions overwhelming majority will prefer to not deal with this Mateusz Konieczny (talk) 13:32, 12 February 2023 (UTC)

@Mateusz Konieczny: They indeed have to update their systems. There is no need to rush and we give them time. This proposal is not just for purity. It is to create a consistent and logical tagging scheme for OSM. This is a long term improvement. Over the coming years, a clearer tagging scheme also benefits data consumers (both new and current users). Their systems can also become easier if there is less overlap over values (e.g. forest and grass tagging) --Cartographer10 (talk) 13:48, 12 February 2023 (UTC)

"Their systems can also become easier if there is less overlap over values (e.g. forest and grass tagging)" - none of changes proposed here would result in such effect. For forest we would be getting one more value without deprecation of any, for grass value count is the same with a new key. Mateusz Konieczny (talk) 22:56, 12 February 2023 (UTC)

"They indeed have to update their systems. There is no need to rush and we give them time." - this is not changing that every single data consumer showing grass, flowerbeds, tree areas, sands, bare rock etc would be hit with busywork Mateusz Konieczny (talk) 22:56, 12 February 2023 (UTC)

"Reduce overlap of the same key." - unclear to me what is the problem being solved. Can you give specific examples? Mateusz Konieczny (talk) 11:58, 12 February 2023 (UTC)

@Mateusz Konieczny: With this we mean for example the overlap of landuse=residential and landuse=grass. To map a grassfield in a residential area, you now have to draw another landuse over it. --Cartographer10 (talk) 13:18, 12 February 2023 (UTC)

Then I am on position that overlapping multiple landuses (say, landuse=flowerbed in landuse=residential in landuse=military or landuse=military with landuse=forest) is 100% fine Mateusz Konieczny (talk) 13:32, 12 February 2023 (UTC)

@Mateusz Konieczny: During the proposal "multiple landuse" we already discussed overlapping function areas like residential and retail. However, now we are talking overlapping functional and physical objects in the same key. That is another discussion. Landuse=grass is a landcover, not a landuse. That is why the overlap is problematic and unclear. --Cartographer10 (talk) 13:48, 12 February 2023 (UTC)

"Make the OSM tagging schema ready for expansion in a logical way." - unclear how it makes it easier. Can you give specific examples? Mateusz Konieczny (talk) 11:58, 12 February 2023 (UTC)

@Mateusz Konieczny: Thanks for asking. Over the past years, the landuse/landcover tagging scheme has become inconsistent with values not beeing place in a logical key. Take for example landuse=grass, landuse=flowerbed, natural=sand en potential new tags in the future. These have been added to these tags due to the lack of something better. With landcover, values can now be placed under a key in which the key name properly describes the feature you are mapping. This means that the tagging scheme becomes more consistent and logical. Also, it is easier for new (and experienced) mappers to find/add tags thus making it easier for them instead of constantly discussing how to tag something.--Cartographer10 (talk) 13:18, 12 February 2023 (UTC)

If the discussion above doesn't convince you of the problem here, I ask you to consider the answer to this very direct question: if your proposal is adopted, what will become possible that is not currently possible? If the answer is "the tagging will become more organized but every data consuer has to change", then the gains are cosmetic while the impact on data consumers is extensive. --ZeLonewolf (talk) 02:17, 15 February 2023 (UTC)

@ZeLonewolf: As explained to others, it is not only about the data consumers. It is also about creating an easier and more logical and extendable tagging scheme for landcover and landuse. With landcover, you get a scheme that stimulates the separation of physical tags and functional tags.Now you often also have to assess the function of an area which can be hard while the physical landcover is clear. It is better to map that then an incorect function functional tag to describe a landcover --Cartographer10 (talk) 19:06, 15 February 2023 (UTC)

I'm sorry, but this still didn't answer my question. Today we are able to use a specific tag to tag grass and flowerbeds (for example). After your proposal, we will have two competing ways to tag grass and flowerbeds. The only reason we would come up with a new way to tag these features is if the old way is unable to capture the information we wish to capture. Merely renaming tags to satisfy the urge to organize tags differently is disruptive for no benefit that you're able to articulate. I don't see why the vague statement "stimulating the separation of physical tags and functional tags" justifies disrupting every consumer if this data. If you don't care about data consumers, be prepared for every author of a data consumer to vote no.

Further, you seem to overestimate what a proposal is able to do. Even if somehow approved, it does not change what data consumers and editors do with the data. It will not compel software authors to use the new tag, and it will not give you approval to mass-edit to double-tag features. A proposal exists to document consensus, not to change people's minds. Additionally, you will have to contend with a very real segment of the community that feels that landuse=* use used for any man-made area feature and as such flowerbed and grass are correctly organized. This viewpoint is particularly prevalent in the German mapping community which is less-active on English-language forums but will come out en masses when this is pointed out. I don't really agree with that view on the landuse tag but trust me that there's a very real bloc that holds this view and they'll be quite vocal at voting time. See the most recent attempt to deal with the landuse=forest vs natural=wood for an example of this.

Again I say: this proposal lacks a clearly-stated problem which you are trying to address. You have to do better than "I feel this concept is better categorized here than there." --ZeLonewolf (talk) 20:06, 15 February 2023 (UTC)

Overlap with natural=*

Natural in OSM de facto means: able to develop, grow or flow by itself. So natural=wood does *not* mean it's a natural wood, it means the trees grow by themselves. And natural=water means that the water flows, not that it's natural water. This means that most of the proposed landcover values are already covered by natural=* values, and there is no reason to alter or deprecate that. --Peter Elderson (talk) 21:46, 10 February 2023 (UTC)

I oppose the statement. For me landuse was a actively USED area, whereas natural is mostly something which is not economically used. This proposal (which i like) just offers the possibility for micromapping within larger swaths of landuse which is good. Flohoff (talk) 23:05, 10 February 2023 (UTC)

Still, it's a fact that natural=* as used in OSM, can not be interpreted as "a natural *". Not economically used? Think of water, is that not economically used? Sand, beaches? Woods? Trees? You can use natural=* with that in mind, but so many others have other interpretations in mind, and the result is that a tag natural=* only means, as I said, that it develops, grows or flows by itself. THat is precisely why natural=wood and landuse=forest are in effect the same thing: the only thing you can be sure of is that there are trees. Mappers can think of a million differences and preferences, but in the end these differences can not be deducted from the tagging. --Peter Elderson (talk) 09:25, 11 February 2023 (UTC)

@Pelderson: We also struggle a bit with this. We didn't want to deprecate to much values in this proposal like natural=sand or natural=bare_rock but values like sand and bare_rock are perfect examples of landcover and were therefore included. For landcover=trees, deprecating natural=wood is also controversial because it is part of a larger discussion about how to map forests. We didn't want to interfer with that discussion to much by deprecating natural=wood --Cartographer10 (talk) 17:45, 11 February 2023 (UTC)

I fully agree with the idea to sharpen the definiton of landuse (although removed from the proposal) and support to remove those values which are barely "landcover" instead of "landuse". This applies definitely to the values "grass" and "flowerbed". These values are perfect examples of landcover as per the common definition of this term.

Nevertheless I also have to agree to the argument that "landcover" is widely overlapping with "natural", as pointed out here. There are several "natural" values which would qualify for landcover without doubt, i.e.

scrub - shrubbery - glacier - mud - shingle - water (partially) - bare_rock - sand - scree

besides others being arguably if they would be useful values for landcover like heath, fell or wood, describing a complete ecosystem more than a simple landcover. The problem with the above listed values is that they are not only qualifying for "landcover", but also well fitting into the "natural" scheme, not always perfect, but well established. Using these values parallel as "natural" and "landcover" would not make sense to me, just cause confusion. Deprecating all these well established "natural" tags would surely not find approval, as there is nothing wrong with these values attached to "natural" imho.

Probably an acceptable compromise would be to deprecate "grass" and "flowerbed" from landuse and establish these values as additional "natural" instead of "landcover" - which they are, at least when following the defnition given by @Peter Elderson "able to develop, grow or flow by itself". Map HeRo (talk) 18:01, 12 February 2023 (UTC)

Wild flowers

Resolved: We removed the flowers value from the proposed values

"landuse=flowerbed replace with landcover=flowers."

That is losing ability to distinguish flowerbeds and areas with wild flowers and will end with tags ending de facto-redefined Mateusz Konieczny (talk) 12:00, 12 February 2023 (UTC)

@Mateusz Konieczny: If you have a wild field of flowers than that is normally part of for example natural=grassland or natural=meadow. The definition of grassland for example says "...and other herbaceous (non-woody) plants". landcover=flowers is for decorative flower areas--Cartographer10 (talk) 13:05, 12 February 2023 (UTC)

"landcover=flowers is for decorative flower areas" this is unclear in tag name, while current landuse=flowerbed is actually clear Mateusz Konieczny (talk) 13:33, 12 February 2023 (UTC)

@Mateusz Konieczny: The whole point of land cover is to begin mapping with the actual object regardless of how it got there or what the accompanying function is. This function has already been mapped in a larger functional area, like a park, garden etc. From this functional area can be deducted if an area of flowers is wild of cultivated. But if you have a suggestion, we are happy to consider it. --Tjuro (talk) 13:50, 12 February 2023 (UTC)

Note that you can have flowers in city without it being flowerbed and flowerbeds in generally natural places Mateusz Konieczny (talk) 22:51, 12 February 2023 (UTC)

scree, shingle, surface=gravel

Resolved: We removed the gravel value from the proposed values and thus resolved this one

Tag:natural=shingle Tag:natural=scree - so it would be become double tagged also with landcover=gravel, right? The same for surface=gravel areas? Mateusz Konieczny (talk) 12:03, 12 February 2023 (UTC)

Commitment of major data users / renderers

Double tagging is a form of tagging for the renderer / data user. E.g. you want a particular tag to be rendered, but you are unsure if it will be rendered, so you keep the old tag or you would lose the rendering. However, data users / renderers will not implement tagging before there is (at least) approval, and without hope of rendering, I think the proposal will end dead in the water. It's a Mexican standoff.

I think temporary double tagging is not a problem, but in this case, there is no end point. I think we are looking at almost permanent double tagging here, adding redundancy instead of simplification. I think it is crucial to this proposal to get a commitment from major data users / renderers to implement handling of the most important new tags in the foreseeable future, after approval. That is, landcover=trees and landcover=grass. A commitment would break the Mexican standoff, and provide an end point for double tagging. If the commitment is hard enough, e.g. with a planned date, maybe double tagging is not necessary at all.

"Double tagging is a form of tagging for the renderer / data user" - technically true, but this is not something wrong. Deliberately incorrect tagging for renderer is a wrong thing (mapping area with purple flowers as industrial landuse as some specific map style will show this area in purple). Double tagging is a bit annoying in the worst case Mateusz Konieczny (talk) 06:27, 14 February 2023 (UTC)

Wouldn't you agree that it should be a temporary thing, with a path to an end point?--Peter Elderson (talk) 08:47, 16 February 2023 (UTC)

Though in such case authors of proposal should not pretend that it is not a large scale deprecation attempt Mateusz Konieczny (talk) 10:09, 16 February 2023 (UTC)

I don't think they do pretend that. They clearly state deprecation of one tag is intended, but not a mass replacement; instead they promote double tagging with no foreseeable end point or path to single tagging. I would have liked a path, such as: for now approve the more logical and de facto in use tag and possibly state preference for the new tag; monitor the usage; after a fair amount of time evaluate; if usage still increases over time, then become more firm and "officially" deprecate, at which time data users, validators and editors are asked to adapt their tools and applications, if they haven't done so already. Stating preference doesn't seem like much, but it is an opportunity to state what the new tag means for the mappers. For me, just a simple "Enables mapping grassy areas without worrying what it is used for" or "Is more logical because grass is not a landuse" would be enough. Landuse=grass keeps hitting me in the face as wrong, and I'm not exactly alone in that.

My other point was seeking commitment from data users that, should the tag be approved, they can and probably will support it. If it cannot be done, the tag is not right. I say "probably will", because there may be other considerations, such as availability and skill of coders. And, if there are data usability issues with this tagging, it's best to know them before voting.

--Peter Elderson (talk) 11:32, 16 February 2023 (UTC)

Seasons and Verifiability ?

Resolved: We removed the flowers value from the proposed values

For landcover=flowers or landcover=grass and similar - unless in very specific and unlikely climate, most of the planet will experience [https.://en.wikipedia.org/wiki/Season seasons]. So, for example in good part of the year it will be impossible to say if something will be covered in flowers in summer, thus failing Verifiability criteria, likely resulting in such areas to be removed or its tags replaced (with e.g. surface=ground` or landuse=meadow or landcover=ground or something else). I did not see how it is planned to handle that? --mnalis (talk) 03:20, 14 February 2023 (UTC)

@Mnalis: Thanks providing feedback. Based on others their feedback we removed the landcover=flowers and thus the deprecation of landuse=flowerbed from the proposal. We decided to limit the scope to focus on introducing the tag with less values and only values that are in use--Cartographer10 (talk) 18:09, 16 February 2023 (UTC)

Rationale for not using surface tag instead for the purpose of land surface is misleading/incorrect

It seems to claim (or at least heavily imply) that surface=* is only being used for highways and pitches. While those are certainly most popular uses (because, that's where the information is most useful) it is far from only uses of surface=*. According to taginfo, surface=* is used in combination with more than 20k other tags! And even in quoted part of its wiki, it clearly mentions "other features" besides highways --mnalis (talk) 03:33, 14 February 2023 (UTC)

@Mnalis:I think we didn't write this clear enough in the proposal hence the confusion. The point we tried to make is that surface=* is often (but not limited to) used in combination with highway and pitches. Of course, as you correctly stated, it can be used for far more things. I will change it in the proposal. The point we tried to make is that surface=* is a property assigned to a feature like a highway. We don't see it as a top level key equal to landuse, natural and landcover. Does that clearify it? --Cartographer10 (talk) 18:16, 16 February 2023 (UTC)

@Cartographer10: thanks for the answer. It still is not not clear, nor does it sit right. As it looks to me from that explanation, the landcover=* tag would mean basically the same thing as surface=* tag, but would be considered "top-level tag" instead of "attribute/property tag". And I reading that right? That does not make sense to me. It would be much better to document in surface=* wiki that in certain cases, if there is no additional information to be conveyed and thus no top-level tag existing, combination of area=yes and surface=* is enough, and call it a day. The rest of that sections says "This means that the two features collide, that has unwanted consequences like needing to sort feature keys on what feature is more important when used in a combination. And not knowing what part of the attributes belongs to what feature tag." which does not make it any clearer to me -- what exactly do you think would break, can you give examples? Link to documentation explaining the problem? As that is seemingly the main reason for that proposal, it should be explained copiously, and not only mentioned in passing in confusing non-explaining way without any examples.

Also, even if such hard separation of toplevel/attribute tags would be a real issue (which I doubt, especially as no evidence has been provided to support that fear), it would make much more sense to invent something like toplevel=dummy tag which would be dummy tag used as top-level tag which doesn't imply anything, and then attach to it any property/attribute tags as one wants (like surface=* or area=* or any of the other "property" tags) in cases where there is really nothing more that can be said about that OSM object - as it would be extremely simple tag, and would cover all current and future use cases, instead of inventing new top-level tag which does the same thing as some property tag each time that we see a need for that. But as I said, without examples and/or links to documentation which describe what exactly breaks, I really do not see the reason for such things. After all, people use tags which can be both property and toplevel (like shop=yes), as well as multiple top-level tags on the same object (like shop=*/amenity=*+building=*), as well only property tags without any top-level tags (like area=*+name=*) and still things seems to work just fine without the world crashing. --mnalis (talk) 19:01, 28 March 2023 (UTC)

are you reccomending to retag farmland multiple times, every year?

Resolved: We removed the bare soil value from the proposed values and thus resolved this one

"However, in its current state without a crop it is a good example of bare soil." - and you propose it to retag it once crop has grown? And again when it is harvested? And again when field is tilled? Mateusz Konieczny (talk) 06:30, 14 February 2023 (UTC)

@Mateusz Konieczny: No, ofcourse not. I think that example is not so clear after all. We will reconsinder it--Cartographer10 (talk) 18:43, 15 February 2023 (UTC)

Landcover overlap - ok in certain situations?

It is stated in the proposal that "Different landcover areas cannot and should not overlap".

Being fond of tagging landcover, I've come across situations where this might not be true. The best example is caves or simple overhangs of cliffs. If both the landcover visible in aerial photos, as well as the landcover hidden beneath it is to be mapped, some form of overlap is required.

It would probably be smart to mention a mechanism for doing this in the proposal. That is, some way of mapping such intended overlaps that would differentiate them from the base assumption - that overlaps are a mistake and should be corrected.

--Harahu (talk) 11:58, 16 February 2023 (UTC)

I am trying to imagine this. Currently we are talking about only trees and grass. Caves do not usually have grass and trees, I think? Overhanging cliffs, would that be trees on the cliff and grass beneath? I would probably just map what you see on aerial. You might miss some grass on the bottom, but is that a big problem? Second thought: this same situation occurs now, two layers overlapping. I guess data users have ways to handle this. I see lots of swimming trees, where the renderer simply renders both the water and the forest. In the case of tree and grass I think the darker green with the tree icons wins, and I don't really know how else you could render two layers and see them separately when one is on top of the other.

--Peter Elderson (talk) 13:48, 16 February 2023 (UTC)

Overhang with https://en.wikipedia.org/wiki/Green_roof is the easy way to produce such case though exotic one and maybe not worth mapping. Though "landcover areas cannot and should not overlap" is general and claimed in general, not restricted to just these two Mateusz Konieczny (talk) 14:08, 16 February 2023 (UTC)

I can't imagine it would be that hard to support this. What do you do when buildings overlap? You use the layer tag. One could do the same for landcover/landuse/natural.

--Harahu (talk) 16:05, 16 February 2023 (UTC)

@Harahu: Good point, thanks for bringing this up. This is indeed an edge case which we will update in the proposal. This statement: "Different landcover areas cannot and should not overlap" was more meant that for example landcover=grass and landcover=sand on the same level cannot overlap. There can only be 1 landcover at a given location. In your example, the landcovers are not on the same level. Some kind of layer tag should be added to indicate one is above another. --Cartographer10 (talk) 18:20, 16 February 2023 (UTC)

The time is over...

Resolved: Is outside of something we can change.

Giving up a first-level tag with over 5.4 million uses does not make sense. See https://taginfo.openstreetmap.org/tags/landuse=grass --streckenkundler (talk) 13:20, 19 February 2023 (UTC)

Thanks for your concern @Streckenkundler: we are aware of the fact that landuse=grass, is used quite a bit. However, both time and usage are relative. With the exponential curve that landuse=grass is growing, we might have many times more landuse grass in ten years. Almost everyone I’ve spoken to has said that landuse=grass is not a landuse. And we would like to fix this issue before landuse=grass doubles in size again. I also would like to point out that we cannot do anything about the relatively high usage numbers. The only thing we can do is write the best proposal we can.

Missing definition of "used area"

When is an area being "used" as described at the beginning of the "Not a replacement for Landuse=*" section? A landuse=meadow is used for grazing and landuse=grass is not. Okay. But landuse=grass often has a function as well, even though it's more implicit and not always obvious: Provide green spaces for residents (often dogs are allowed) increasing attractivity and psychological well being, avoid sealing the ground for better water management, reduce heat radiation during summer, making smaller peaces of ground (e.g. between roads or parking spaces) more beautiful with minimum costs and probably many more.

Here's my opinion on the different grassy tags, which leaves no need for a landcover tag:

• If a grassy area is not maintained, it probably doesn't serve any purpose for humans, which means no one cares about this and the grass grows naturally (maybe this is even the whole point). The natural=grassland tag is probably correct.
• If the grassy area acts as grazing area, landuse=meadow is correct.
• If the grassy area is somehow maintained, it means humans care about this piece of land, so it fulfills some sort of function (as mentioned above) and using landuse=grass is therefore just fine.

IMHO the landcover tag serves no purpose and should be abandoned. Other users here already mentioned the very low usage, which supports my opinion. --Hauke-stieler (talk) 13:52, 19 February 2023 (UTC)

You might want to look at the increase in usage, despite not being rendered: https://taginfo.openstreetmap.org/keys/landcover#chronology

--Peter Elderson (talk) 12:07, 21 February 2023 (UTC)

Just want to note that the whole usage statistic thing wasn't my main argument here.

Anyway, I know about the statistics, but:

1. For every instance of landcover=grass come about 150 instances of landuse=grass and the usage of the landuse=* key is increasing as well. For flowerbeds, it's even a ratio of about 230 to 1.

2. The steepness of the landcover-curve gives the impression that it'll eventually reach the amount of the landuse-tags. That's wrong: Both show a linear increase. During the last year the landcover=* usage increased by about 70k usages while the landuse=* usage increased by about 7 million. Therefore the gap between them is growing rapidly. If you would show the curves on the same plot (therefore scaling the landcover-graph to match the y-axis), the landover graph would be just a few pixels high (I just did that in GIMP).

3. The usage of landcover=* is not common in most parts of the world as the comparison shows: https://taginfo.openstreetmap.org/compare/landcover=grass/landuse=grass Except for Europe, the key is nearly never used.

In addition to my main point (= landcover=grass always has a function/fulfills a "use", which means landuse=grass is totally fine), at least landcover=grass should be abandoned.

--Hauke-stieler (talk) 12:48, 21 February 2023 (UTC)

Why do you think landcover usage is growing despite not being rendered or supported by editing tools? --Peter Elderson (talk) 13:20, 21 February 2023 (UTC)

Is this a serious question? JOSM and iD "support" it in a way that you can tag both. OSM allows arbitrary tags and the wiki documents both. --Hauke-stieler (talk) 13:54, 21 February 2023 (UTC)

Landuse=grass and landuse=flowerbed do not have intrinsic functions tied to it. You are right however that you can use these physical objects in a bigger function space. To provide a function. For example, to admire a flowerbed you need space to get to the flowerbed. The over compassing function of a garden or a park. But the flowerbed itself cannot do this themselves.--Tjuro (talk) 13:19, 21 February 2023 (UTC)

"do not have intrinsic functions tied to it" - Why not? I argued in the opposite direction (s. above), what are your counter arguments? --Hauke-stieler (talk) 13:54, 21 February 2023 (UTC)

Thanks for your feedback @Hauke-stieler:, we have completely rewritten to proposal to make this more clear. But to answer you’re question here: The distinction between use and functional use is crucial when it comes to understanding the rationale. Use would be described as people have occupied a peace of land with an object. For example, grass, paving stones etc. There are no intrinsic functions to these objects, I might be used for all kinds of functions maybe for transport or for decorative functions. However, whatever this function is you need more landcovers/landuses to carry out this function. As one Landover is not enough to carry out this function. The land is used in the sense that you can only cover a piece of land once. but we argue that use should be more than just occupying. On the other hand, there are functional uses. These are aeras that have an abstract human function, aka a goal. They have a verb accompanying them like living, working, grazing. The function however does not say what objects are contained in that function, this might be very different depending on the area, some residential areas might have grass and others do not. The function of living might require other functions like leisure=park. And to carry out a park function you probably need some landcover=grass. So, to answer your question the function of a piece of land should be different of the cover of that land as its not always known what landcovers company are in a functional area.

Does this answer your question? --Tjuro (talk) 09:48, 19 March 2023 (UTC)

Thanks for clearing this up, I think I get your point. However, this is extremely complicated to explain to a newbie. Also I don't think that distinguishing the use and functional use is of any use for end users and mappers. At least I never heard of anyone complaining about the lack of this distinction. --Hauke-stieler (talk) 10:12, 19 March 2023 (UTC)

No clear difference to natural=*

The latest change in the proposal introduced tags like landcover=mud or landcover=bare_rock. Why is the separation from the natural=* key necessary? I don't understand it. Why did you pick these five natural features? What about natural=water, I mean the land is literally covered by water there. What about heath?

The proposal says it should be easier to pick the correct tag, but to be honest: I'm an experienced mapper and are completely confused when reading this proposal. I get the motivation behind it, but it reminds me of the famous "There are 14 competing standards"-XKCD (s. here). (user: Hauke-stieler)

@Hauke-stieler: Thanks that you took the time to read the changes. The tags like landcover=mud or landcover=bare_rock are clear landcover values. They describe the physical coverage of the earth. natural=water are named natural entities like lakes, rivers etc ( as rule of thump, these features can have a name and thus are natural=*). As written in the proposal, some natural values require a separate discussion. The proposed landcover values like mud and bare_rock are not part of a broader discussion like for example forests --Cartographer10 (talk) 10:03, 19 March 2023 (UTC)

I consider this a dangerous proposal

Why do I consider this dangerous?

1. The existing tags, that you want to deprecate, have something like 7-8 million usages. It'll take decades until most of them are migrated to the new scheme, because most natural- and landuse-features aren't touched very often. Migration all of the old natural- and landuse-features is completely unrealistic.
2. We will definitely end up with mixed tagging and definitely with even more confused users. More tags → more things to know/consider/read/compare → higher risk of confusion. I mean the wiki will say "use landcover" but the OSM data nearly only contains landuse.
3. The next "phone vs contact:phone". This will definitely come, since people (like me) are probably not willing to adjust to the new scheme.
4. Double tagging for compatibility? Please no!! This will just increase the amount of confusion mentioned above, makes the maintenance of data harder than necessary and renderers will never adjust (s. below).
5. Introduction of new tags not clear.
   1. Example of bark mulch: Is it a landuse tag? Well, it's similar to landuse=grass as it maybe fulfills a use. Or maybe none at all and it was just the cheapest material to cover the ground. So better use the landcover tag? → I'm literally have no idea where to put this.
   2. Example of moss: In Iceland large regions are covered my moss (not grass, not heath, only moss). There to put this? Landcover or natural? Or does a natural tag imply the landcover tag? Is this always the case? Again, I have no idea.
6. Rendering will never be adjusted. The default renderer is known to not adjust to tags that are not common. Double tagging things will cause most renderers to never adjust.

@Hauke-stieler: Thanks for raising your concerns:

1. The amount of times used should not be a reason to not deprecate something. If deprecation leads to a better tagging scheme, then it should be allowed.
2. I don't quite understand how this will lead to more confusion. You will get a more strict separation between the tags which should increase clarity.
3. It is indeed a significant change and I hope that over time, with all the answers to you question you will see the benefit of the changes.
4. Okay, let me remove that section, your are right. However, for forest it is still recommended because of the ungoing and unresolved discussion about how to tag it.
5. New tags
   1. It is clearly a landcover. The bark mulch might be part of a bigger functional area like a park or recreational ground.
   2. Same as above. It is a landcover.
6. There are more renderers than OSM carto. I will indeed work on the double tagging thing. If the proposal is accepted, the community can also help to get render support on Carto. As written in the rendering section, the changes can be relly pragmetic. --Cartographer10 (talk) 10:17, 19 March 2023 (UTC)

@Cartographer10: My thoughts on that:

1. I get the point but in practice it does: Someone has to migrate the stuff, someone has to deal with people adding deprecated tags because they're widely used and known. All this costs time and for millions of usages this probably takes decades. Adjusting editors, renderers, apps, presets, etc. etc. will already take years. All of this is not beneficial for the data quality, OSM as project and all software developer will definitely be not amused about such broad changes.
2. Regarding "more strict separation between the tags which should increase clarity". As my other comments point out: There might be strict and clear separation in your head but it's not clear at all and there are numerous edge- and special cases. Or lets take the perspective of a newbie: He's in Norway and sees a lake, some shingle from a river, some bare rock and some heath. It would take a long time to explain to him, why the lake and heath are mapped using natural=* even though all of these things are natural and not man made.
3. "I hope" ... you ... hope?! That's the worst argumentative basis you can have. Sorry, but I don't see the benefit in that.
4. -
5. New tags
   1. Okay, got it.
   2. This, however, seems completely arbitrary to me. Is it because mossy area usually do not have a name? These areas definitely can have a name and locals will probably have names. Or what distinguishes it from a natural=* tag?
6. "the community can also help to get render support on Carto" This is exactly not how it works for Carto. Some other renderers might adjust but that's not guaranteed. Carto has a certain mindset, which for example prevents rendering of the approved healthcare tags ... which were approved in 2010. This is a good example how badly migrations works: The old amenity=doctors tag for a doctor is still more even though the according healthcare tag is used more and more since 2018, which is already five years ago. So it'll take about another 2-3 years to have equally many healthcare=doctor and amenity=doctors tags. And this is only for ~150k usages. A lot of your changes will affect millions of tags and again: This will probably take decades to migrate with a lot of confusion, wrong tagging, deprecated tags, double tagging, annoyed developers and so on. All that for IMHO not many advantages.

Next to renderers, editors, Apps and other software must pick this up as well. Especially iD is famous for ratical decisions and might just stick with the current, well established, known and often used tags. Even though a discussion might change that, it'll take several years.

--Hauke-stieler (talk) 11:09, 19 March 2023 (UTC)

@Hauke-stieler:

1. We are not in a hurry. It is not that this has to be migrated next year. We are aware it takes time and that is fine. It is a long term improvement for OSM. Communities can pick this up together. For example, for the highway=busway, the Dutch community agreed to migrate to the new scheme and we did it. Of course, landuse=grass is a bit bigger but as a community you can also decide to automate it. And as for "it is not beneficial to the data quality", it is. The entire scheme will be more clear and thus easier to use.
2. As a community, including me, we will have to write it all down on wiki to clarify it. With good documentation, I don't see why that does not work.
3. Okay, I indeed worded that completly wrong. It was more meant as that by having conversions like these, we need to clarify the benefits to people who don't support it yet.
4. -
5. New tags
   1. -
   2. If it has a name, isn't it then part of a larger ecosystem and thus a natural? I am not an expert on mossy areas. Maybe there is a natural value missing that would cover this? To me it feels a bit like plains where the plain is an ecosystem that consists out of multiple landcovers like grass, water, maybe some small group of trees or bushes.
6. I am aware of the rusted attitude of Carto but it should not hold back. Take highway=bus as example: https://taginfo.openstreetmap.org/tags/highway=busway#chronology . It is not rendering and still people are using it. Other renders already picked it up. And as mentioned in the rendering section, renders can take a pragmatic approach that includes backward compatibility AND support the new tags.

Thanks for responding, but I'm not convinced. The differentiation between the natural, landuse, landcover, leisure and surface keys is not as clear as you might think. Basically introduction the landcover key will not make things clearer but instead adds another key that people have to look at and thus will just introduce another source of confusion. It doesn't solve a real problem in my eyes. Which means I never heard anyone complaining about any of the Problems this proposal wants to solve. It might solve some problem for some people (maybe even a minority) and with absolute certainty, it'll introduce significant effort and problem for literally millions of people for the next several years or even decades. I see the point and motivation of this proposal but I don't think this will be e beneficial change - rather the opposite. --Hauke-stieler (talk) 13:01, 19 March 2023 (UTC)

@Hauke-stieler: We have updated the definition of natural in the proposal. Additionally, in the section below "natural=scree" I added an example for natural=tundra. That is a very clear example of the benefits the separation has. Does that example make it clearer? The proposal should make it easier for mappers and data consumers to find tags, introduce new tags.

Counter-Proposal

In above sections, I already argued against this proposal ("Missing definition of used area", "No clear difference to natural=*" and "I consider this a dangerous proposal". So here's my outline of a counter-proposal with the same goal: Reduce confusion and make tagging clearer.

1. Clear up the difference to the natural=* tag (basically landuse = man made; natural = well ... natural stuff). Especially things like wood/forest, scrub/shrubbery, grassland/grass, ... This may lead to separate and smaller proposals (also s. following points) to make this difference more clear.
2. Accept the imperfection of the landuse=* tag. Yes, grass doesn't always fulfill an (obvious) use but is still tagged as landuse=grass. Yes, a pond is man made and probably fulfills a certain use of the land, but is tagged as natural=water.
3. Handle such exceptions from the rule in separate and much smaller proposals. (user:Hauke-stieler )

@Hauke-stieler:

1. Then you will miss a layer of detailing. A forest is an ecosystem consisting out of more smaller landcovers. Placing them all in the natural key will not make it clearer
2. How will accepting the imperfections of landuse=* help to clarify tagging? As already mentioned by Tjuro under 'Missing definition of "used area"', A disctinction between physical coverage and functional use is possible
3. Exceptions make things not more clear. The proposed changes reduce the need for these exceptions because of a clearer defined definition of all the included tags.--Cartographer10 (talk) 12:56, 19 March 2023 (UTC)

1. I think these details can be added in a different way. Either with multi-polygons or with a scheme like for building-parts. I don't think this proposal gives us new possibilities for tagging details.
2. Having less keys makes things simpler. The landuse scheme is well established, people obviously accept it and there are fewer keys to know. The more keys we have, the more complex the tagging scheme becomes, the more error-prone it gets and in the worst case the more frustrating mapping is. This also is the case for users of the data. OSM is already a mess with numerous duplicate, deprecated, mixed, abandoned, .... keys, let's not make it worse. And not only would this proposal introduce a similar tag to landuse, it also introduces a differentiation of the keys, which is IMHO quite complicated, sometimes hard to determine/verify, in my eyes sometimes arbitrary and is costs time and effort of mappers and users to read and understand this.
3. As mentioned above several times: The proposal doesn't make things clearer, especially not the distinction between the natural and landcover tags.

--Hauke-stieler (talk) 13:18, 19 March 2023 (UTC)

@Hauke-stieler: 1. We disagree, for landuse and natural it is important to keep it in one peace for multiple reasons, take for example landuse=cemetery, usually this landuse acts as an amenity and has a name and a website, it is undesirable to split up this landuse. Landcover would allow the freedom to specify each square meter of the cemetery without cutting up the underlying landuse.

2. In theory yes, however the current keys of landuse and natural are mixed in a way where it’s not clear how thing should be mapped. You could also make the argument to just completely remove keys altogether. But that would not make it simpler. In my opinion the best way to structure things is to have distinct groups that have clear separation, and that is what we did here.

3. I’m sorry you’re not understanding the distinction, is there anything in particular that you think is not clear cut? --Tjuro (talk) 07:45, 21 March 2023 (UTC)

natural=tree

"Natural: The natural tag should solely be used for (named) natural entities (see them a bit as natural Point of Interests)"

So you are proposing to delete all not named natural=tree? Mateusz Konieczny (talk) 13:05, 19 March 2023 (UTC)

@Mateusz Konieczny: No, we will clarify that in the proposal. It was meant more as a rule of thump that if a natural entity CAN (optional) have a name, it should be tagged with natural=*. It is ofcourse not that every natural entity should have a name --Cartographer10 (talk) 13:13, 19 March 2023 (UTC)

There are named shingle, bare rock and scree areas. There are also named grass and tree areas. I bet that there are also named mud areas Mateusz Konieczny (talk) 13:16, 19 March 2023 (UTC)

@Mateusz Konieczny: Fair point. Name might not be a good indication, we will see how we can rephrase that. Maybe a clearer example are beaches. A beach is clearly a natural entity. The entity it self does not say anything about the landcover. A beach can have different landcovers like sand, gravel, shells etc. An natural entity is in that sense more of a natural POI that consists out of multiple landcovers. The same with mountains. The mountain is the POI that can consist out of multiple landcovers like bare_rock, snow/ice, short grass etc. Does that clarify it? --Cartographer10 (talk) 13:33, 19 March 2023 (UTC)

It is not a convincing reason to retag natural features like bare rock areas to another key if difference between two groups is not clear cut and blatant Mateusz Konieczny (talk) 13:41, 19 March 2023 (UTC)

@Mateusz Konieczny: Thanks for your critical view on our natural definition. We were finally able to find better wording. We updated the definition to: "The natural tag should solely be used for natural entities like landscapes, landforms and other physical features. Think of volcano's, plains, beaches, caves, wetlands, forest (continued to be tagged with natural=wood), tree_rows, valleys and water bodies like lake and rivers (continue to be tagged with natural=water).". These natural entities like plains, valleys and forest subsequently consist out of smaller landcovers like grass, trees (area), water, bushes etc. And back to your first comment, you can then also place a name on a landcover. --Cartographer10 (talk) 15:49, 19 March 2023 (UTC)

natural=scree

There are many named screes in my area. Also woods often have names. Just like bare_rocks. --Hungerburg (talk) 23:06, 19 March 2023 (UTC)

@Hungerburg: Thanks for your feedback, we recognise that this was confusing, so we updated the definition, what we meant is that natural features like breaches, trees and caves are more likely to have a name then landcovers like an area of scree. But we recognise now that anything can be nameless or have a name. Does this solve your question? --Tjuro (talk) 08:54, 20 March 2023 (UTC)

I read the revisions done to the Natural section. I must say, I liked the comparison with POIs that has been there - That is why we map stuff, because there is a feature on the ground, that we have an interest in. These screes appear prominently in the landscape, they were put names on to serve in navigation and talking about routes. Probably, a place=locality on top of anonymous landcover might serve as well, yet mapping an area is fine: It is easy to delineate on the aerial, it adds more detail, extent, orientation; Cartographers get a bit of leeway where to put a label and at which zoom level. All the while though, what we call "Kare" or "Reisen" are as natural as can be, no less than glaciers e.g. That said, I will oppose any proposal, that sets out to deprecate natural=scree. --Hungerburg (talk) 10:42, 20 March 2023 (UTC)

@Hungerburg: I won't argue that scree isn't a natural product due to for example erosion. That doesn't change however that scree is a landcover. It describes the physical coverage of an area (named or not). That area, together with other areas of landcover form a larger landform or landscape like for example mountains and valleys. And indeed, an area of scree can be used as a POI during walking, just as that a grass field, a road, a building, an antenna etc can be used as POI. It makes sense to separate landforms/landscapes from landcover. Take tundra for example: https://wiki.openstreetmap.org/wiki/Tag:natural%3Dtundra . A tundra is a landscape that consists out of multiple landcovers. The wiki also advices to map these individual areas. You can then use the landform/landscape object to indicate the total extend of the tundra. You might not always know the full extend of the tundra but you can objectively map the landcover. This should make it easier for new mappers to map landcover but also to introduce new tags. The advantage is then also that for example renders can easily render the landcover above the area of the tundra because it is a separate tag. --Cartographer10 (talk) 18:58, 20 March 2023 (UTC)

I'd never have thought, that I would quote Wikipedia in an OSM talk, but his seems wanted here: Scree is a landform. --Hungerburg (talk) 20:37, 20 March 2023 (UTC)

@Hungerburg: Could you elaborate a bit more on why you think scree is a landform? I’m not quite understanding you. If I go to https://en.wikipedia.org/wiki/Scree then I find “Landforms associated with these materials are often called talus deposits.” So natural=talus, natural=talus_ deposit or natural=slope for the landform and landcover=scree/shingle/grass for the landcover makes more sense in my opinion. But if you can come up with some arguments why scree is not a landcover than where willing to consider that. --Tjuro (talk) 21:02, 20 March 2023 (UTC)

Another similar example would be volcanoes, near active volcano there might be solidified lava also called basalt, so you can map that as landcover=basalt, but the natural entity that created the lava in the first place is the volcano and you tag that as natural=volcano. Only basalt does not make something a volcano. Same with scree, scree is the result of another natural entity/landform, but not a natural entity/landform itself. --Tjuro (talk) 21:15, 20 March 2023 (UTC)

I see, you know more about subject matter than those, that mapped the screes in my local area from local knowledge in a way that is immediately obvious to me as a local myself. I also learned, that quoting wikipedia is hot helpful at all. I at least made it to the "description" section, but this cannot be taken for granted. What shalls? Waiting for discussion, what makes landcover=scree different from surface=gravel ;) --Hungerburg (talk) 23:20, 20 March 2023 (UTC)

The way I understand the difference is that scree is generally composed of larger rocks and boulders, while gravel is made up of smaller pieces of rock that range in size. Also, scree is typically angular and irregular in shape. Whereas, gravel is usually rounded or smoothed by erosion. Further, scree is usually made up of a single type of rock or mineral, while gravel can be composed of a variety of materials. Lastly, scree is usually found on steep slopes or cliffs, while gravel can be found in a variety of environments, such as riverbeds, beaches, and construction sites. Although scree can also be found at least on the sides of river beds sometimes. Especially ones that are adjacent to slopes or cliffs. I think those differences are clear by looking at images of both. --Adamant1 (talk) 11:50, 21 March 2023 (UTC)

Reading above, I further see, why someone in the community forum wants to do away with pebblestone surface for highways, because too many people that map for OSM cannot be bothered to read up on documentation. It would tell them, the rounded stuff is not gravel, it is pebbles or shingle instead.

Regarding scree: If Oxford dictionary and wikidata agree, I do not see a reason to make up my own definition: Scree is a landform, otherwise also known as talus, and the surface of it as well; Scree is the combination of steep slopes and gravel. The base was formed in the last ice-ages. In my local area, this is mapped quite concisely and provides valuable information to map users. For your entertainment, a not so clear case - https://www.openstreetmap.org/relation/6674704 - for a casual observer, it is a scree - on OSM-Carto, on the aerial and on the ground -- but take a look at the tags - they give away, what geology has to say about that! --Hungerburg (talk) 01:43, 22 March 2023 (UTC)

PS: Here a photo of the fake scree from the opposing hill of the scene of the fake scree - https://oekastatic.orf.at/mims/2023/12/37/crops/w=1280,q=60,r=1.5/1722228_bigpicture_636937_blockgletscher_c_3dgeo-heidelberg.jpg - I see plenty of natural=peak|ridge|arete|glacier|perennial_snow|scree|bare_rock|shingle|grassland|&c|* there, but it would never have occurred to me to observe any tundra there. --Hungerburg (talk) 22:46, 22 March 2023 (UTC)

natural=beach example, why?

@Cartographer10: You said in some explanation above "Maybe a clearer example are beaches. A beach is clearly a natural entity. The entity it self does not say anything about the landcover. A beach can have different landcovers like sand, gravel, shells etc. An natural entity is in that sense more of a natural POI that consists out of multiple landcovers" -- I don't get it why is landcover=* supposedly needed here? The are almost 45k natural=beach with surface=* defined. What would be advantage of using newly invented landcover=sand instead of already popular surface=sand etc. on them? What problem exactly would it solve (we can see all kind of problems it would produce, but not what landcover=* proposal would solve) which is unsolvable currently?

I do not think to point should be to put as much stuff as possible into proposal - quite the opposite, only the bare minimum needed to accomplish the most clearest benefits should be put in the proposal, if the goal is to have it accepted. To quote De Saint-Exupéry as it explains the main problem with this proposal very well: "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away" --mnalis (talk) 20:12, 28 March 2023 (UTC)

@Mnalis: Thank you for talking the time to provide feedback. A beach can consist out of multiple landcovers. It can for example partly exists out of sand and rocks/pebbles. In such cases, you can use natural=beach to map the total extend of the beach (as a natural entity) and use landcover to map the smaller areas of different landcover. And true, there are also beaches that have only 1 landcover like sand of pebbles. The same with for example a tundra. The wiki also says that it is better to map the individual landcovers. natural=tundra Can then be used to map the extend of the tundra. --Cartographer10 (talk) 17:36, 30 March 2023 (UTC)

@Cartographer10: is there a reason why that could not be accomplished with existing mapping using relations (e.g. 20k+ usages of natural=beach) instead of causing all that turmoil with deprecating one set of tags and creating another set of tags with the same meaning? --mnalis (talk) 15:10, 5 May 2023 (UTC)

landcover implications vs declared goal

I tried for a long time to understand what I don’t like about this proposal and what exactly to criticize, because I myself have been thinking about introducing landuse=* tags for quite a long time. It seems that I finally understood. Unfortunately this proposal is self-contradictory, and does not solve the declared problems, and it neither makes the key=tag system clearer, nor makes life of OSM data user any easier.

In the "proposal" section it 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 the use often determines the physical properties of an area, and vice versa, physical properties define possible uses.

So in "landcover implications" we see:

Some current tags imply a landcover and therefore, landcover does not need to be added to these tags.

Ok, good, why bother to add additional tags to explicitly specify what is implied, but it completely kills the idea of orthogonality.

For example, I would like to create a map of earth landcovers/vegetation. Can I do it now? Mostly yes(for example like this). How many keys do I need to process for that now? Mostly two keys are need: natural=* and landuse=*. Will it be possible to obtain landcovers 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 at all simplification.

In my opinion, the landcover=* system to be useful should cover 90% of earth surface. Not just objects that do not imply landcover from other tags. See for example here which tags I had to process and some statistics (this system is not obviously ideal and contain some strange things ) -- Zkir (talk) 23:50, 13 January 2024 (UTC)