[RFC] Feature Proposal - landcover proposal V2

@Tjuro and I started a proposal to formalize the usage of landcover=*. The proposal is now open for feedback

Please discuss this proposal on its Wiki Talk page.


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 :grin:

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.

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.


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.


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.

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.


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?


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. :stuck_out_tongue:

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.

1 Like

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,

this would be absurd, “grass” isn’t a use and someone’s front yard is clearly residential use

or for cutting up the landuse=residential area into tiny chunks criss-crossed by yet-to-be-mapped landuse=highway and area:highway areas,

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.