@Tjuro and I started a proposal to formalize the usage of landcover=*. The proposal is now open for feedback
https://wiki.openstreetmap.org/wiki/Proposed_features/landcover_proposal_V2
Please discuss this proposal on its Wiki Talk page.
7 Likes
You could save everybody some time in simply removing deprecation of tags from your proposal.
At this point in OSM proposals history, this should be considered a simple courtesy to your fellow mappers 
1 Like
Yes, I understand that some people always find ādeprecatingā difficult. Only OSM today has arrived in a situation where you can improve and clarify the tagging scheme only just not only add new, but also replace must act.
1 Like
Deprecation does not mean anything needs to be removed right now. Just that its not recommended to use for new objects. The history is of course relative. In 30 years when I hope that OSM is still going strong. This proposal will be in the early days.
Please read āMigrationā and āWhy deprecate landuse=grass and landuse=flowerbed?ā for more detail.
3 Likes
This is not a proposal for improvement, merely a proposal for change.
I have read the rationale, and quite honestly my first thought was āwell, thatās X minutes of my life I wonāt get backā. The distinction between āusefulā and ānot usefulā makes no sense here - whoās to say that flowerbeds arenāt useful? Are the one in peopleās gardens the results of a conspiracy by Big Flowerā¢? People plant them because they find them beneficial to them in some way - i.e. they are useful.
OSM categorises things linked by complicated real-world concepts. Renaming a few tags will not change that - and new OSMers have this hidden from them by their editor anyway.
1 Like
It is not about usefulness in the sense that flowers have no benefit or what people think about them. It is that flowerbeds are part of a larger landuse (or leisure in the case of for example a park). Flowerbeds (or landcover=flowers as proposed) defines how the land at that place is covered. A park for example consists out of many landcovers that together fill the landuse. A flowerbed cannot be compared with other landuse like residential, farmland etc.
4 Likes
on the other hand everyone knows that if landcover=water would be approved we would quickly get people claiming that natural=water should be replaced.
There are still people misleadingly claiming that highway=bus_stop was deprecated.
Therefore I see this as a bad idea.
The only āpositiveā is that Forest - OpenStreetMap Wiki would get to list even more confusion.
1 Like
When I started mapping with OSM one of the first problems I encountered was the mixup of landuse (utilization) and landcover (physical coverage) all under the landuse key and as a result out of this mixup the use of 2 or 3 different landuses overlapping each other in certain places. It does not make sense to me and it does not to several other mappers, as you can easily see in view of lots of discussions adressing this issue again and again.
From that point of view a proposal with the target to provide better and more clear definitions of landuse and landcover for OSM use in accordance with the definitions of these terms in real life sound like a big improvement to me (and will definitely get my full support).
I agree to you that not each and every landcover must get a landcover tag. If it is described well by an existing natural tag there would be not need to replace it at this stage. But a single questionable tag canāt be reason enough to reject the whole as a bad idea imho.
Definitely not because landcover=trees is already part of the wiki āForestā page so making use of it cannot add confusion.
4 Likes
The āthis might be farmlandā image brought up some missing opportunities to propose:
landcover:conditional=snow @ winter
landcover:conditional=soil @ early_spring
landcover:conditional=crops @ late_spring-summer-autumn
I donāt understand whatās the difference between natural=wood and landcover=trees. Is it that orchards and vineyards are not natural=wood, but are landcover=trees? Thatās it?
How do you migrate to this new schema? Say, someone changes natural=wood to landcover=trees, but the data consumers donāt know about the landcover=trees. This is actually a problem already today.
Also there is a funny thing suggested that
landuse=cemetery could imply landcover=graves. Iāve imagined how the land is tiled with tombstones. ŠŠ¾ŃŠ¾Š¶ŠŗŠ° ŠøŠ· Š½Š°Š“Š³ŃŠ¾Š±Š½ŃŃ
ŠæŠ»ŠøŃ Š²Š¾ ŠŠ»Š°Š“ŠøŠ¼ŠøŃŃŠŗŠ¾Š¹ Š¾Š±Š»Š°ŃŃŠø - YouTube
But many cemeteries are also in the forest. How do you specify two landcovers?
Or imagine a park with trees. The trees may have bushes underneath like in a real forest or they may have a lawn. How do you specify this? Does the grass cover the land or the trees?
2 Likes
like now, with overlapping areas
people would be even more confused whether one of variants is approved (in a case of proposal getting approved) or rejected (in case of a proposal being rejected) or it rejection applying only to the tag or only to proposal or also to mapping forest in this specific way and what it means for other variants
āat this stageā will not make people less nervous
if it would result people in trying to suggest that natural=water should be replaced then it is
In general if people are unhappy with any part of a a proposal then they will vote against it
1 Like
It was used as an analogy to explain the concept. The proposal also says that it is not proposed.
You donāt. 2 or more landcovers cannot overlap. There is only 1 landcover. The example you give is not different from the current situation. If I see a park with trees and grass underneath it, I tag the grass and map the trees individually instead of saying it is a forest/group of trees.
We didnāt want to go as far as deprecating natural=wood because that requires a separate proposal in combination with landuse=forest. The topic of how to map forest is to large/ controversial to be included here. The reason why we added it is because it is the most used landcover value on OSM right now. We tried to use current used values as much as possible. That is why it is proposed to double tag landcover and natural until decent support or another proposal fixes the forest tagging.
We removed landcover=water from the proposal. It became clear that to many people reject this value.
Please read āmigrationā.
The proposal does not state landuse=cemetery can imply landcover=graves. it says landuse=cemetery must contain landcover=graves. Please read āLanduse implicationsā.
There can only every be one landcover for each layer= tag. with landcover=trees you donāt map the canopy but the ground on with the trees grow.
If there are mutable options like bushes or grass, its up to the mapper to decide what is the landcover that is most relevant, but generally you map the grass and map each tree separate.
There can be a lot of trees quite tightly grouped together and now you introduce a problem for a general application which displays a map. It must somehow group these trees together into an area if it wants to show the user that there are trees there at lower zoom levels.
Relation: 11737303 | OpenStreetMap look at this example. The result would be that the work is so tedios that we just wouldnāt have ANY data about trees.
I donāt think micromapping is the answer.
Thanks, didnāt see it somehow, my bad. This works for me!
I would like to clarify something about āMust containā as there is some confusion about that. āMust containā basically is a soft implication where itās still possible to map on the landuse that āMust containā a landcover. āMust containā means that you will find(irl) that landcover there and itās also an indication to map a given landuse.
This contrasts with implication where every square meter is covered in that landcover so mapping on top would technically result is double landcovers with is redundant.
If we have the cemetery example:
To map a cemetery some graves would be expected, to carry out the main role of a cemetery, however there are other landcovers that can assist in the function of a cemetery and therefor cemetery cannot imply landcover=graves.
Another example would be orchards, to map an landuse=orchard. A mapper needs some landcover=trees + other functional requirements as an indication to map a landuse=orchard. So if you go to an orchard its safe to assume that some part is coverd in landcover=trees. However, there might also be some accompanying landcover=grass.
This is not a requirement to start mapping these āMust containā landcovers. but is important to understand possible rendering methods for landuse and landcover. That is why the whole part is under the āRenderingā part of the proposal.
1 Like
You may be right, I really donāt know, but it would not make sense to me. If there is a reasonable proposal which I generally would support including a single issue I do not like wouldnāt it be the next step to express my disapproval to this single issue instead of downvoting the whole proposal? Is this not what the talk page of the proposal is made for?
Anyhow, the problem I see with landcover (although i really like the idea) are the many duplicates with well established natural values (not only water) - but that is an issue for the talk page.
Bummer, I was really looking forward to mapping landuse=reservoir areas coincident to landcover=water areas, to clarify that the reservoir is covered by water. 
What I most appreciate about this discussion is the awareness that land use is orthogonal to land cover. I regularly encounter confusion on this point not only among new mappers but also among experienced mappers who, for instance, argue for cutting a hole in a landuse=residential area to accommodate a lush landuse=grass in someoneās front yard, or for cutting up the landuse=residential area into tiny chunks criss-crossed by yet-to-be-mapped landuse=highway and area:highway areas, or fractalizing a landuse=residential to exclude parts of residential buildings merely because of some overgrown trees. Confounding matters are the non-landuse tags like amenity=hospital and leisure=park.
The proposal strikes me as something that wouldāve been pretty reasonable at the outset of the OSM project (well before my time). If the community had agreed to distinguish between landuse and landcover in raw tags upfront, there wouldāve been less of this confusion. Here in the 2020s, it should be possible to educate mappers without as much disruption by clearly distinguishing between landuse for land use and landuse for land cover when organizing presets in an editor UI or organizing wiki articles in a category. iD does this to some extent, putting some land cover presets under āNatural Featuresā. However, we would have to trust data consumers to be aware of the LU/LC distinction regardless of an explicit distinction in key names.
Perhaps the column would be less confusing with a name like āNormally containsā.
Thereās something to be said for delineating land use and land cover based on what can and canāt overlap. However, it seems inevitable that there will be some gray area, because large properties often contain a hierarchy of uses. For example:
- This horse farm contains several pastures for grazing, which up to now have needed to be tagged as
landuse=meadow. - This local park contains a golf course, athletic fields, a campground, and a heritage farm.
- This cemetery doubles as an arboretum (which is by definition tree-covered) and contains a nature preserve.
I realize this proposal is primarily about land cover. However, I hope it doesnāt promote the idea that we can eliminate overlapping land use areas too.
2 Likes
I regularly encounter confusion on this point not only among new mappers but also among experienced mappers who, for instance, argue for cutting a hole in a
landuse=residentialarea to accommodate a lushlanduse=grassin someoneās front yard,
this would be absurd, āgrassā isnāt a use and someoneās front yard is clearly residential use
or for cutting up the
landuse=residentialarea into tiny chunks criss-crossed by yet-to-be-mappedlanduse=highwayandarea:highwayareas,
I am doing this and I believe rightfully, because a road is not residential use, it is a road, space dedicated for traffic.
It is also a mapping style that is typically leading to precise but simple (low complexity) landuse mapping that is easy to maintain and improve. We should encourage this.
Up to a point, right? More than once I saw someone omitting each houseās driveway from the landuse=residential area. I think most of us recognize that thereās a limit to how complex we want the landuse geometry, but the criteria arenāt obvious to everyone, especially when weāre reserving space for the area:highways but not actually drawing them yet. Separating landcover from landuse could at least make some of these distinctions clearer. But what youāre describing, at least in a North American context, is mapping easements ā which is even more granular than mapping parcels.
Regardless, thereās still the inherent difference in how people map formal, named landuse areas versus informal, unnamed landuse areas. I think many mappers would hesitate to cut the service roads out of a cemetery or the parking lot out of a park, because these landuse areas represent something already well defined: you enter the park, continue driving on the road, and park inside the park. A specific retail or residential development can be just as heterogeneous as a park, even if we coincidentally apply the same tag as on another area that weāre drawing as a vague generalization.
2 Likes