[RFC] Feature Proposal - landcover proposal V2

General talk Tagging general discussion
,
15

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!

16

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
17

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.

18

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.

2 Likes
19

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.

20

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
21

Thanks for the examples. The proposal does not prohibit that landuse/leisure can overlap. This sentence from the proposal is important here: Currently, the landuse key on OSM contains both functional and physical objects. You can indeed have multiple functional objects overlapping, for example a cemetery and a park. However, landcover cannot overlap. The earth can only be covered by 1 physical object (e.g. grass, trees, shrubs etc). The current key contains both physical and functional objects in the same key. That is not possible.

This is indeed a good example of the problems/confusion that start occurring with the landuse key containing both functional and physical objects. I personally also map small residential areas (around blocks of houses), the discussion about making smaller chunks of residential area is outside of the scope of this proposal. That is about the level of detail a mapper chooses to map in.

1 Like
22

Yes because landuse is about function, one area can have two or more distinct functions. Also functions in other function can become more specific. In your horse farm example the whole function would be to raise horses. And the meadow would be for hoses to graze. But the grazing is a more specific part of the razing function.

However you can only have one landcover at a given location, of multiple types of objects are mixed it becomes a new type of landcover.

In the proposal I added a table with the differences between landuses and landcover. One difference between these is that with landuses specifying a border can be difficult as landuses are defined by there function its sometimes hard to specify what is and is not included in that function. With landcover these borders are much clearer as landcovers are always physical objects.

That’s a good idea I will consider that.

1 Like
23

I disagree, especially for residential roads. They are not dedicated to traffic only (maybe in some car centric parts of the world they are), they serve as public space, to meet, to play, to work and trade etc.
For me, residential roads are usually part of a residential landuse for the same reason a playground is part of it.

2 Likes
24

Up to a point, right? More than once I saw someone omitting each house’s driveway from the landuse=residential area.

yes, up to a point. A private driveway or garden usually are part of the residential (or commercial etc. according to what it is) landuse.

I think most of us recognize that there’s a limit to how complex we want the landuse geometry,

not so sure about this. Definitely there is a limit how complex we would want to see it represented in a map, but I could imagine people generalizing complex landuse situations into ”cleaner” map representations e.g. by omitting small areas with different landuse of a kind the map maker has decided can be omitted in the context of predominant landuse x.

but the criteria aren’t obvious to everyone, especially when we’re reserving space for the area:highways but not actually drawing them yet.

on a sidenote, landuse=highway can be different from area:highway if the latter is about the drivable area while the former the legal area of the highway (i.e. contains verges, shoulders, ditches etc.)

Separating landcover from landuse could at least make some of these distinctions clearer.

+1

But what you’re describing, at least in a North American context, is mapping easements – which is even more granular than mapping parcels.

yes, while it may generally make sense to see parcels as the building blocks for landuse areas, there could also be subdivisions of parcels when there are different landuses on the same parcel.

Regardless, there’s still the inherent difference in how people map formal, named landuse areas versus informal, unnamed landuse areas.

my idea for this is using “place” for such named areas, which I would not see as “landuse areas”, rather as settlement parts with potentially dedicated functions/predominant use (e.g. a commercial area must not necessarily consist only of commercial landuse (see the roads for example), and must not necessarily be represented by a single landuse object (although it should be accepted as a transitory method and shortcut, a less detailed representation that waits for improvement).

I think many mappers would hesitate to cut the service roads out of a cemetery or the parking lot out of a park,

landuse=cemetery is an odd tag in general as it is typically used for a feature (or could you map 2 adjacent cemeteries as one single landuse?), while there is no problem with parks which aren’t mapped as landuse.

Cheers Martin

25

However you can only have one landcover at a given location, of multiple types of objects are mixed it becomes a new type of landcover.

in practice, you can have areas with so small distinct “landcover” types that it will have to be generalized or not mapped because nobody is willing to do the work (maybe until we ask an AI to do it). E.g. a forest that blurs into a meadow by becoming more sparse until it disappears, could be mapped by representing the single trees, but there would have to be billions of trees and it’s not likely we can map it like this even less keep it updated. Regardless of landuse and landcover there will always be some need of generalization, we will never map all the small stones that occur on a field in some context (e.g.)

2 Likes
26

I disagree, especially for residential roads. They are not dedicated to traffic only (maybe in some car centric parts of the world they are),

traffic was not limited to vehicle traffic

27

Thank your for all the feedback so far. We would like to have feedback on a specific topic that is beeing discussed here and on the talk page. Duplicates with natural=*.

We didn’t want to make the proposal to large by deprecating natural tags. However, many people think the duplicates that are created are a bad thing. We see 2 solutions here:

  1. Add deprecation for the duplicate natural values.
  2. Remove the duplicate landcover values from the proposal and only introduce the tag with the initial values trees/grass/flowers (and still deprecate landuse=grass/flowerbed).

What are your thoughts on this?

The advantage of 1 is that along the tag, you also have quite some values to start mapping with. Other values can be added later. It also cleans-up the natural tag a bit.

28

I think that should read “… from the proposal and only”?

The tags natural, landuse, and landcover are all in significant use (landcover considerably less than the others, but still in use). Somewhat confusingly, the wiki just redirects to a very old, failed, proposal.

If you were to propose to document how the “landcover” tag is used currently (not how you would like it to be used) then I’m sure that there would be broad approval for that.

Minh’s post above identifies some of the issues, but there are many more. Any attempt to change the way that people map features currently mapped as “natural” or “landuse” is likely to fail, and just create more of a mess than we have now***. Even if the “proposal” was to pass with (say) a few dozen votes, most people will be completely unaware of it until their editor (probably unbeknown to them) uses a new tag in place of the old one, or a map or app they use supports the new tag and no longer supports the old one**. The whole rigmarole would be a complete waste of time - and the net result (map renderings etc.) woud be exactly the same as before! No new information is being captured; it’s not like the removal of a bad tag like “highway=ford” on a way - that was a bad tag because the value “ford” doesn’t let us say whether it’s “highway=primary” or “highway=secondary” etc.

Politics is the art of the possible. Politicians don’t always realise this, but it helps avoiding wasting everyone’s time if you understand what things are achievable before attempting a change.

*** Experience suggests that any attempt to change existing OSM data would not reach the required consensus.

** OSM Carto has a policy that can be described as “not showing incorrect tags”; other renderers may vary (I show all somewhat popular tags for things I’m interested in even if misspelt).

29

Thanks, I updated the sentence

That something is used a lot should not be a reason to not change it. Otherwise OSM is forever deadlocked with with a more and more unclear tagging scheme.

I disagree. This is a proposal that should improve the tagging scheme over the long term. As some people already replied, even experienced mappers sometimes struggle with the landuse/landcover tagging scheme. So overtime, it should become less and less of a mess. Even if that means that we now have to make some hard choices in commonly used tags.

And about the editors. Just like data users, we have to give them time to adjust. We have to properly document it on wiki and led people get familiar with it. I don’t expect everybody to just switch in the blink of an eye. It takes time and we acknowledge that.

1 Like
30

Somewhat confusingly, the wiki just redirects to a very old, failed, proposal.

the proposal is maybe “very old”
but there is nothing “failed” rather it is in use.

31

I agree that stuff like landuse=residential should be considered very coarse and approximate. After all, even the busy micromappers will probably not snoop on my garage-turned-workshop and decide to map it as landuse=industrial instead of landuse=residential where my nearby building=house resides. Not to mention that very often several stories high building=apartments over here will have some shop=* on the ground floor instead.

I would quite disagree there, unless you map on microscopic (literally!) level. In fact, in case of biomes that you mention, it is always intermixed ecosystem. It is just that some people mostly don’t care that majority of landcover=trees actual land surface area is actually grass or flowers or even mix of shrubs and trees or fungi or mosses etc.

So some people might first see the largest of objects there (e.g. “Trees”) and incorrectly map it is landcover=trees, even if it is in majority for example landcover=grass (with only some 30% trees surface area).

Now you might have a point if you’d take some other proposed example, i.e. for non-living surfaces - e.g. landcover=gravel might conceivably be covering 100% of the land surface – but there I simply don’t understand what was wrong with surface=gravel, especially after reading that extremely weak and also wrong section of the rationale (as I mentioned in the talk page there)

32

From the practical standpoint, it is always much better to improve on and change the new proposal (which is still very fluid), then to try to alter behaviour for existing tags (which have become quite rigid over time, and you risk alienating people by forcing them to change their habits).

Thus, I would suggest removing/deprecating all values from the new proposal, which are duplicated or implied by other already popular tags.

E.g. if someone uses natural=wood or landuse=forest, then proposal should indicate that implied landcover=trees should be omitted in that case; and that landcover=trees should only be used on tree areas which are explicitly not covered by either natural=wood or landuse=forest (and giving few examples with pictures of such situations).

Same thing for landcover=grass etc. - advise people in proposal not to use it if it is already implied by other tags (such as landuse=meadow or leisure=park+surface=grass etc.) and only use it if other already popular tags are explicitly not appropriate (also as above, give several clear examples with pictures of such cases).

1 Like
33

I agree that stuff like landuse=residential should be considered very coarse and approximate. After all, even the busy micromappers will probably not snoop on my garage-turned-workshop and decide to map it as landuse=industrial instead of landuse=residential where my nearby building=house resides.

I would say this depends on the workshop, if you are operating it as a business it should probably (in an ideal, detailed representation) get its own landuse, but if it is a hobby room it would be considered residential use.

Not to mention that very often several stories high building=apartments over here will have some shop=* on the ground floor instead.

this is a very common situation in many places and there is no clear answer to it. You could map the use of the individual floors and the “landuse“ becomes less important at that point. Typically people will map it as residential and add the shops as POIs or even as retail (if the area around is considered retail area).

If it is 7:1 it is still clearer how to proceed as if it is for example 10 floors of hotel and 10 floors of luxury apartments, or 2-3 floors of retail and some more commercial (office) floors and maybe 1-2 residential floors on top. In these cases we could have a “mixed” value for landuse and an additional tag how the mix is composed.

34

Actually, I’m even more worried now. Let’s take a very simple example - a new iD user wants to map an area with grass on it. Currently, they type “grass” into the search and get tw options back - descriptions that correspond to “natural=grassland” and “landuse=grass”. Links are available for them to see a quick summary of the difference - they can also click through to the wiki pages.

You seem to be suggesting that they’d instead just add “landcover=grass” and move on. Surely that would result in a lower quality of contributions?

A summary of that argument is “We must do something; this is something; so let’s do this (see also Politician's syllogism - Wikipedia)”