Proposal talk:Landcover

From OpenStreetMap Wiki
Jump to navigation Jump to search

Natural/landuse treat secondary info as primary

  1. Primary info: what is there on the ground (scrub? lawn? bedrock? wood?) This Information is required and quite easy to know.
  2. Secondary info: why it is there (naturally there, man made there). This Information is optional and sometimes hard to know.

Unfortunately the tags in use (landuse=*, natural=*) give secondary info along with the primary. Thus you have to know things you actually sometimes cannot know.

Therefore landcover=* is favorable: it gives primary info (what is there) without the need to know secondary info (why is it there).

All it takes for landcover=lawn (just an example) to have the same info as landuse=meadow is: man_made=yes (just an example again). A missing man_made=yes means: natural.

So, yes, that's one tag more if it is man made. landcover=* plus man_made=*.

And yes, there are some landcover=*s that are man_made by design: landcover=farmland implicitly is man_made=yes.

I agree that it has to be possible to map "what's on the ground" without being forced to add any secondary information. But please note that currently natural=* doesn't actually mean that the feature is "natural". That's a misconception that has unfortunately been turned into a rule in one case (natural=wood), but is not part of the definition of any other tag using that key. You can tag an artificial lake as natural=water, and a manually planted tree as natural=tree for example. --Tordanik 17:48, 14 December 2011 (UTC)

Not a good idea

We already have landuse=*, natural=* and surface=*. Your proposal is not an improvement (just renaming) and creates more confusion where newbies are asking for simplicity. --Pieren 15:30, 16 November 2010 (UTC)

+1 with pieren. I would prefer to keep backward compatibility as much as possible. Propose to add tags to the existing ones to increase information. Exemple, add water_type=ocean/sea/lake/... to natural=water while retaining compatibility with a simple natural=water without additions. Also I agree your landcover is a good word for a good purpose, but there is not that much benefit for a big confusion risk and loads of software, mind, usages to adapt. sletuffe 01:02, 17 November 2010 (UTC)
This tagging really no benefits. Don't try to clean up the tagging without improvements, some type of key categories are always bad approximations, but in this case, they also do not really exist here. --Fabi2 19:54, 18 November 2010 (UTC)


I know that we have landuse, but is has nothing to do with landcover. I know that we have natural, but it has almost nothing to do with landcover, and the few examples where there are the same values should be moved from natural to landcover IMHO (as they are creating inconsistency at the moment). E.g.: natural=water is used for all kinds of water bodies (even swimming pools) that have nothing to do with "natural". Natural=water doesn't fit into the logic of using natural for geographic features (which are the majority: e.g. coastline, bay, beach, cliff, cave_entrance, peak, spring, volcano). Right now you would tag natural=bay for bays and all other water-bodies as natural=water. Does this sound logical? Water is a physical substance, bay isn't. A lake neither. natural=water doesn't fit at all in the scheme, just that many people recognize this, because water is somehow "natural" --- simply this doesn't count IMHO. -- Dieterdreist 18:22, 17 November 2010 (UTC)
-1 with Pieren. The landcover proposal will enable us to make a more logical tagging language. The proposal is not about abolishing natural and surface, but to reorganize them, and in some cases (surface) let them return to their original and meaningful purpose. "Surface" makes sense for roads and the like, but surface=grass??? What do you tell the visitors that come to a summer barbeque at your house? "Step into my grass-surface?" ;-) --mok0 10:56, 25 November 2010 (UTC)
Nothing wrong with surface=grass, you also don't tell them "my landuse farmland" either and tags don't have to fully match spoken language. -- SwiftFast (talk) 09:44, 20 May 2017 (UTC)
It seems that we have trouble with the semantics of the keys. It seems that most people here interprets the key "landuse" as something that should describe how a area is predominatly used for/planned for. One can then understand that it would be nice to have a more "physical" view, in the meaning of showing how an area looks like, what it is made up of or maybe how it could be used for transporting.
To bad that there seems to be some semantic issues with the existing landuse-alternatives. I believe that the key "natural" is supposed to mean a natural feature/geographic feature, on of those things that mankind have had names for since the beginning of speech and that is why there could be found a bunch of rather small scale and specific tags, e.g. cliff, mixed with more generalized water (meaning open water I suppose). The problem seem to be that we only use the key "natural" for things that are not formed/altered/maintained by man, and in our civilized world we will then get a lot of similar-looking features needing different tags because of how it have been used before.
I guess that the point of this proposal aims on this. To have a key that is more objective, more focused on how it is perceived than how it is used. Then we have to discuss or decide on what physical features we want to focus on when using the key "landcover", and on what scale. For me land-cover means a general description of the nature in a large swath of land, e.g. the land-cover of Belgium is farmlands in the West and forests in the East (The land is covered in farms and forests). As OSM do a lot of small area mapping I see a imminent risque that landcover could be confused with the cover of the ground, that is the properties of the surface looked on close, e.g gravel or grass.
So do we want a detailed description for small areas of how it looks and feels like from the soil and up, for vegetated areas this could be done dividing the volume in grass, shrubs and tree -canopy; for developed industrial or residential areas this could be a bit more exhaustive with its barriers and structures, but for parks and lawns the same scheme as for natural areas could be used./Johan Jönsson 22:34, 30 August 2011 (BST)
Yes, I fully agree that landuse is the actual, current landuse of an area, i.e. how it is used. I don't agree that this would be what an area is planned for. The latter might be the same as the former, but also not, and if it isn't the same I'd only look at how it is actually used. What you are after with planned for (and what is relevant for many planning projects) is the legal status or the permitted landuse, one that can't be observed and is maybe not even realized, but is the intention of the government how it should be. We might have a tag for this in future OSM, but it should not be landuse, and frankly, there is not a big point in having it, as we can't change or modify this (it would be more suitable for an overlay). --Dieterdreist 19:32, 20 October 2012 (BST)
-1 You forgot about leisure which is also used instead os landuse=*/natural=*. --Cracklinrain (talk) 08:35, 20 June 2013 (UTC)
+1 with Pieren. There are already too many redundant keys for the same kind of things. Inventing yet another makes it even worse. Remember that the schisma was not resolved by installing a third pope. --Fkv (talk) 06:16, 22 October 2013 (UTC)
That's right. The schisma was resolved in deprecating the old ones, while installing a new one. --Rudolf (talk) 17:50, 28 April 2014 (UTC)

A very good idea

The landcover tag is a major improvement, and allows for an orthogonal tagging scheme to landuse. I propose to include a generalized tag for vegetation (landcover=vegetation) with the type of vegetation specified in a vegetation=* tag. This would enable a granular tagging of for example a forest, which often has areas of characteristic vegetation, such as grass, pine, etc. that could be specified in this way. Other examples are landcover=desert, landcover=bush, landcover=trees, landcover=pampas, landcover=marsh, etc.

In other words, landcover would typically describe the physical geography:

  • Geology (rocks and minerals)
  • Landforms
  • Soils
  • Vegetation
  • Environment
  • etc.

where landuse would be used to describe the human geography:

  • Settlements
  • Agricultural systems
  • Recreational areas
  • Economic activities
  • etc.

User:mok0 18:54, 16 November 2010 (UTC)

All of the "physical geography" features you mentioned here can be specified with natural tag. Use natural=scrub or natural=heath instead of landcover=bush; natural=wetland+wetland=marsh instead of landcover=marsh; natural=wood instead of landcover=trees and so on. There is natural=* (may be with surface=*) for "physical geography", and landuse=*, man_made=* for "human geography". There is no reason to introduce a new tag like "landcover" to describe landscapes. --Surly 15:56, 7 February 2011 (UTC)
+1 Just one example, why natural is not the same. landuse=military and natural=wood do not come up with each other, because natural=wood describes wood which is not use for timber production and landuse=forest is double tagging. --Cracklinrain (talk) 08:16, 20 June 2013 (UTC)
The word natural=* to many people implies no human intervention, thus scrub land that has been re-vegetated does not fit this understanding. The landcover=* tag does not have this drawback as it precisely describes what is being mapped. Warin61 (talk) 03:10, 5 February 2017 (UTC)

+1 for landcover=vegetation --Extropy 08:46, 23 November 2010 (UTC)

I find this key appealing but I have had some trouble to pin down exactly what it is about and what differentiates it from the natural-key. I have had a great help in a defintion and classification system by United Nations Food and Agriculture Org, FAO, FAO land cover definition.
They stress the importance for a classification system to be scalable and source independent.
(as opposed to the rendering/legend that should adopt to the situation)
For primarily vegetated areas they suggest a classification to be done something like this,
in decreasing importance:
  1. ) vegetated or not?
  2. ) main vegetation type: tree/shrub/herbs?
  3. ) description of the main vegetation type in height/coverage/distribution
  4. ) secondary vegetation type
  5. ) third vegetation type
  6. ) further details on the vegetation
I hope the link can be of some use. /Johan Jönsson 16:21, 6 February 2011 (UTC)

I see the main use of landcover=* tagging scheme in it's orthogonality to landuse, while it actually could interfere with surface=* scheme. Current landuse=* and natural=* schemes are not describing just the surface or structures covering it. Landuse also means some intentional usage and, likely, man-made origin of an object. While natural=* strictly points to natural origin of it. It's common problem with many current tags - not only wide meaning (it's normal abstraction, good for maps) but mixed meanings (single tag+value pair corresponds to several entities or properties).

With landcover=* tag we could show just what we want without assuming it's usage or origin. It could also be used as scheme of preliminary tagging during import of low resolution remote sensing products, because there we usually could see "trees" or "sand" without any knowledge if it's natural wood, commercial forest, sand quarry or natural beach. --BushmanK (talk) 08:36, 1 September 2013 (UTC)

Very logical idea which would be an extension of the usability/universality of the OSM database. Separating landcover and usage is in practice often not necessary but very logical. Currently areas are defined by tags which combine both keys: natural, landuse, leisure and amenity. It works most of the time because landcover and usage are often linked unambiguously. But there are exceptions: Military, graveyard, park, trees, grass, picnic. However, regarding the sparation of landuse/landcover: It is not necessary for the mainstream renderer, because landuse is more important than landcover. A side note: I see the surface tag as road or vehicle-exclusive, so it shall be kept away from landuse/landcover. --Lukie80 (talk) 10:35, 14 June 2017 (UTC)

Complicating things without benefit

natural=desert, natural=srub (or bush if you like), natural=wood / landuse=forest, natural=pampas, natural=wetland, etc.

I other words, this proposal complicates things for mappers (now you have to know / decide between three possible keys) without gaining any real advantage -- Ulfl 20:42, 16 November 2010 (UTC)

+1. This proposal is for specialized maps, not for a crowd sourced project like OSM. Please don't introduce this as a standard. Average contributor won't use two or three different tags (sometimes overlaping, sometimes not) just to say what is on the ground. --Pieren 11:43, 17 November 2010 (UTC)
no, this would simplify tagging for people tremendously because it introduces some logics and creates a consistency of which we could only dream 'til now. landuse has a value "grass", what on earth does this mean? "grass" is no landuse. natural is all kind of features, from physical ones to abstract ones (peak), and hides this under a "natural" coating. There is no logics besides "tradition" for the values of natural. Nobody can tell if a new value would fit there, or not, because the already existing are not consistent. We should not go on like this. Mappers don't have to decide with these new values, they can use them all at the same time for the same object but different, well defined, aspects of them. -- Dieterdreist 18:28, 17 November 2010 (UTC)
Sorry, there is no well defined aspects here. How to tag e.g. trees above bushes (http://de.wikipedia.org/wiki/Datei:Blaubeerwald.jpg), do I have to tag the bushes or the trees above. Is a highway a physical landcover regarding this proposals or not? This proposal exchanges a not well defined state of the art with a more complex, again not well defined proposal. -- Ulfl 22:54, 20 November 2010 (UTC)
Trees above bushes would be simple to tag with landcover=vegetation, specifying vegetation=trees; vegetation=bushes. For your Blaubeerwald, you might even be fancy, and specify vegetation=la:Pinus radiata; vegetation=la:Vaccinium uliginosum :-) I find it strange that those opposing the landcover feature on one hand use the argument "this is too complicated", and on the other hand come up with all kinds of weird and complicated situations and ask "how would you tag this using landcover?" You can't have it both ways. -- mok0 10:16, 25 November 2010 (UTC)
Landcover for highways would be asphalt or whatever the highway is paved with. Landcover would be very helpful for mapping outlines of wide highways. --Extropy 08:44, 23 November 2010 (UTC)
To be preceise the highway (see Wikipedia:highway) would be tagged with a landuse=highway tag. Parts of the highway, including the carriageway and footway may be tagged with landcover=asphalt but the the Wikipedia:road verges are likely to be tagged with 'landcover=grass' (or possibly natural=scrub or similar). In most places the assumption will be that the road are covered with asphalt though so that it not that important a tag in my view. This confusion of landuse and landcover is exactly what this proposal aims to resolve. PeterIto 12:49, 28 December 2011 (UTC)
Landcover will simplify tagging for mappers, not complicate it. What is difficult for us newbies is when we find it difficult to find tags that characterize what we observe on the ground. You can have a park, that is a neat place with roses and lawns you aren't allowed to walk on, and you can have a park that is almost like a forest. Do you tag both landuse=park? The average newbie will spend a long time browsing the wiki and the mailing lists for answers, because it isn't obvious that both are just "parks" because they look so different. Plus, this is information you know about that you would like to convey. If you separate the landuse (park) from landcover (grass or trees or rocks or whatever) it all makes sense because it is logical. These are principles you can easily memorize. Using the verb "natural" for landcover is absolutely not a good idea, because it indicates something about the origin of the landcover, namely that it is natural and not man-made or cultivated. Is grass in a park "natural"? Is grass on a field "natural"? You don't know and it's hard to find out. What you do know is what you can observe, and that is the landcover. The whole point is to develop a logical, systematic and expressive tagging language, that will enable us to describe the features we observe on the ground as accurately as possible. That is what gives "crowd-sourcing" its value. -- mok0 10:34, 25 November 2010 (UTC)

Deprecating landuse=forest

I like this proposal. The two landuse=* values that I abuse far too often are landuse=grass and landuse=forest. I see forest isn't mentioned as a value that will be deprecated, but I believe it should. I'm mostly working in residential areas that have significant tree cover, and have been using landuse=forest for those areas of tree cover between houses (not just one or two trees, but many). I didn't use natural=wood because these are areas that are actively managed, i.e. if a tree falls across a path, it is removed. I would much rather use landuse=residential for the entire neighborhood and use landcover=trees for just the areas where I've been using landuse=forest. -- Joshdoe 19:48, 24 May 2011 (BST)

For this reason alone I like this proposal. I have marked a lot of trees - wrongly, I realized - with natural=wood in parks; landuse=forest seemed wrong [1] and natural=wood is also wrong. landcover=trees would solve my problem immediately. Can we start using it already? ([1] leisure=park also seems wrong, but it's another story. Shouldn't it be either amenity or landuse??) Mirar 19:04, 19 May 2012 (BST)

landuse=forest is for those areas where the trees are used to produce something for example lumber for houses or furniture. The missuse of this tag demonstrates why the landcover tag would be useful ...for mappers it would clearly distinguish the use of the land (use the landuse key) and the coverage of the land (use the landcover tag). Warin61 (talk) 20:56, 9 January 2017 (UTC)

Surface

i see the need for a cleanup of the landuse tag, but isn't landcover=* just a synonym for surface=*? if not, you need to explicitly explain the difference in the proposal. --Flaimo 08:35, 25 May 2011 (BST)

From the discussions I've read it seems most agree that landcover=* is only to be used on areas defining the type of land cover, and surface=* is to be used on highway=* objects to define the very surface of the earth. In other words, you could have a national park mostly consisting of trees, which you would tag as an area with landcover=trees, and then if you have a road or hiking path through the area you would tag the way with surface=asphalt or whatever. Now certainly someone could come along and want to map to a finer level, and they would split the giant landcover=tree area into many areas, having areas covering the roads and paths separately, and presumably those could be tagged landcover=asphalt. However I don't think many would go to that level, at least not for many years.
Regarding your park example, why not use natural=wood and surface=asphalt? Surface catches all flat things, natural catches elevated natural things, and landcover seems to mix both. -- SwiftFast (talk) 06:30, 20 May 2017 (UTC)
There's certainly some overlap between the values of landcover=* and surface=*, however they're not identical. For example it wouldn't make much sense to tag a highway with surface=trees! Perhaps surface=* values could be a subset of landcover=* values. -- Joshdoe 11:55, 25 May 2011 (BST)
the wiki page for surface doesn't say, that it is only for highways. actually it says "The surface=* tag is one of the … tags, which can be used to supply extra information about the surface in conjunction with highway ways … and other features." so i think there isn't enough differentiation (or any at all) between landcover=grass and surface=grass for example. --Flaimo 16:29, 25 May 2011 (BST)
+1 for both of you! As OSM is centred around the ways, I assume that the key "surface" predominantly will be used to describe the surface of the road/path, as a sub-tag of the main one describing that it is a road in the first place. In the same way could the key "surface" be used to extend the information on an area mainly tagged by the key "natural", "landuse" or in this case "landcover". With surface I believe we mean the (near horizontal) surface which upon we walk or otherwise travels, e.g. the bottom-most level of a forest, the undergrowth. /Johan Jönsson 22:48, 30 August 2011 (BST)
Yes, in some circumstances surface has the same meaning than landcover (at least according to this proposal, e.g. for "sand"), on the other hand for vegetated areas surface doesn't make sense and especially in the case of trees the surface would be different than "trees". For simplicity I'd use landcover also for the cases that might be expressed with surface. --Dieterdreist 19:39, 20 October 2012 (BST)
You are just admitting that the landcover=* key mixes diffent informations that have nothing to do with each other. Your suggested values for landcover=* fall into 2 categories: 1) The nature of the surface. This is exactly what the surface=* key has been invented for. 2) Plants and vegetation. Your proposal classifies areas to be vegated by either trees, bushes, or grass. This is highly naive. E.g. a wood/forest is a complex ecosystem that consists not only of trees, but also of bushes, herbs, mosses, fungi, algae, lichens, and animals. Tagging a wood with landcover=trees would only be a small portion of the truth. A key like plant_community=* would be much more to the point. --Fkv (talk) 06:16, 22 October 2013 (UTC)
The landcover=* tag is a physical feature in itself. The surface=* tag is associated with some other physical feature. A good example is surface=wood ... that says lumber has been used to provide a suitable surface ..if someone were to tag landcover=wood ... most would take it to be trees growing there. As for the understore of trees ... I know of no proposal to tag/map it. Are you saying that is needed? Then where is your proposal? Warin61 (talk) 03:22, 5 February 2017 (UTC)
Landcover is redundant. For flat things, it duplicates "surface", For elevated natural things (e.g. trees, bushes) it duplicates "natural". We can already tag everything using these two keys. This one adds no extra flexibility but adds complexity. -- SwiftFast (talk) 06:27, 20 May 2017 (UTC)
Natural is both 'natural' and 'man affected' as such it is confusing! I do not like using it for a grassed area that is maintained in a park ... that is not a meadow. The landcover tag is much better. The surface key is a property of another key, so surface cannot be used by itself. Landcover solves both the confusion over 'natural' and provides a solution to tagging an area that may have no other properties. Rather than being redundant it is superior. Warin61 (talk) 06:48, 20 May 2017 (UTC)
You aren't supposed to use natural for grassed area in a park. -- SwiftFast (talk) 08:39, 20 May 2017 (UTC)

Table with all values

For migrating purposes the proposal should list the top 20 of all currently used landuse values and which of them need to get transferred to a landcover key (or not). --Flaimo 08:37, 25 May 2011 (BST)

How about the top 25:
Top 25 landuse=* values (as of 2011-05-25)
Raw Count Count (%) Value Change to Notes
1 264 973 27.1% forest landcover=trees how many are actually used for forestry vs. parks/residential/etc.?
878 151 18.8% grass landcover=grass definitely not a land use
755 220 16.2% residential N/A
374 478 8.0% farm N/A
206 988 4.4% farmland N/A
183 106 3.9% reservoir landcover=water, water=reservoir?
181 504 3.9% meadow landcover=meadow? or perhaps landcover=vegetation, vegetation=meadow?
107 328 2.3% industrial N/A
96 285 2.1% farmyard N/A
75 430 1.6% orchard N/A
73 571 1.6% cemetery N/A
62 870 1.4% commercial N/A
59 413 1.3% quarry ?
46 781 1.0% allotments N/A
43 098 0.9% vineyard N/A
39 436 0.9% retail N/A
33 433 0.7% construction N/A
27 548 0.6% basin landcover=water, water=basin?
26 653 0.6% recreation_ground N/A
25 201 0.5% village_green N/A
18 672 0.4% conservation N/A
16 929 0.4% garages N/A
8 547 0.2% wood landcover=trees
7 809 0.2% brownfield N/A
6 680 0.1% military N/A
This is just my opinion, I'm not trying to match it up against the existing proposal. For the complete list of values see the TagInfo results here -- Joshdoe 12:30, 25 May 2011 (BST)
I think it is the mighty three it all boils down to: landcover=trees, landcover=grass, landcover=water as they can be used to tag both natural and man-made features that looks and behaves the same. And the greatest benefit is to get rid of landuse=grass, the second best thing to map a forest and a wood with the same tag. but as pointed out here, there are some flaws, uncertanties, sematic and defintion issues./Johan Jönsson 23:15, 30 August 2011 (BST)
This is not about "transfering" keys, it is about describing a different property, the polygons for landcover are not necessarily the same than those for landuse, indeed often they will not be. There are only very few values that are currently tagged for the landuse-key that should be transfered to landcover, from your list this is only: grass. --Dieterdreist 19:54, 20 October 2012 (BST)
I would suggest just adding the landcover tag to a few of these:
Top 25 landuse=* values (as of 2011-05-25)
Raw Count Count (%) Value Change to Notes
374 478 8.0% farm add landcover=plantation
206 988 4.4% farmland add landcover=plantation
181 504 3.9% meadow add landcover=grass
43 098 0.9% vineyard add landcover=plantation
25 201 0.5% village_green add landcover=grass
at least unless there's a better tag already on them defining them. Mirar 19:26, 19 May 2012 (BST)
Please stop creating lists which landcover tags might be automatically added to which landuse area. This is not a proposal about automated edits. An area tagged with landuse=farm will most probably not have a landcover-tag. If you wanted to add landcover to such an area you will have to apply the landcover most probably to sub-areas of the landuse.--Dieterdreist 19:57, 20 October 2012 (BST)

I started to create a "cleaned up" version of landcover, landuse and natural a while ago. It is in most parts identical to the tags this proposal suggests and it also contains a table comparing "old" and "new" tags. You can find it here. Maybe it is of some use here. --Imagic 10:30, 6 June 2012 (BST)

landuse=forest in most parts of Australia is a landuse - I have tried to move the others over to natural=wood + landcover=trees. landuse=grass is a 1:1 move over to landcover=grass .. there should be no contention here! Plantation to me is is land use .. not a landcover. farmland might be wheat one year and vegetables the next ... it is not something I'd be comfortable mapping unless I knew it was consistent. I don't see these tables as being helpfull as too many of the suggestions have difficulties with the conversion. Warin61 (talk) 07:01, 20 May 2017 (UTC)

Comments

I think this is a good idea. landuse=grass, for example, is contradictory and just doesn't make sense (“grass” is not a use). Wikipedia has separate articles differentiating the concepts. (There is a type of thematic map called land use/land cover, but I think this breaks down when we consider the more detailed map scales that we have available in OpenStreetMap.)

Some comments about the proposal:

  • “Geology, soil.” – Soil is not land cover, although it can influence land cover. Landcover maps and soil maps are two different kinds of thematic maps. Their subjects are, by definition, separated by the land's surface.
  • “... Climate” – I can't imagine how this relates. Some land cover types may be a result of climate, I suppose, but we're not mapping the climate. I would think we should use tags that are descriptive and independent of climate, e.g., forest, mixed forest, or perhaps rainforest, and not differentiate Pacific temperate rainforest.
  • “Landforms, water” – Land cover is, by definition, on all the bits that are not water.
  • “landcover=trees” – forest or woods is a land cover type, in which the presence of many trees is the main, but not only, characteristic.
  • “landcover=bushes” – similarly, brush or scrub is a land cover. “Bushes” specifically, are more precisely called shrubs. Also, to be confused with bush, a synonym for forest.
  • “landcover=bare_rock” – Why not just landcover=rock?
  • “landcover=ice” – That would be glacier?

The proposal should define some range of scales that land cover is conceptualized at. I don't think we intend to be mapping very large-scale, complex, or heterogenous phenomena like ecozones, ecoregions, ecosystems, biomes, etc.

 Michael Z. 2011-07-28 02:42 z

Great comments, +1 on geology and climate. Water:I wish there was a better term than landcover. I really think that there should be at least three things describing a forest: undergrowth, scrubs, trees, that implies the use of subsidiary tags and the existence of a supertag (=vegetation?). bare_rock is based on the many meanings of the word rock, especially the confusion with boulder and cliff, see natural=bare_rock, but I guess it wouldn´t be so confusing when used in the landcover key. Glacier is one of those nice things to use the key "natural" on./Johan Jönsson 23:04, 30 August 2011 (BST)
I support the proposal the principle. I note the suggestion that surface could be developed to cover landuse but think it may be better to create a landuse tag as you propose. I also agree with some of the comments above, that we should avoid tampering with existing tags which are functioning well if, they have an unambiguous use and only need some clearer documentation. For example riverbank is working just fine as far as I am concerned as is natural=water - these are both 'landcover' tags and be documented to make this clearer; if they are also primarily used as a major shipping route then they should also be tagged with a suitable landuse tag. I am particularly keen that we deprecate landuse=grass and clarify that landuse=forest is only to be used for areas of agroforestry and propose an alternative tag to describe landcover=trees. We also need the landuse=highway tag for areas of land devoted to road infrastructure. Can I suggest that we limit this proposal to resolving the more immediate issues and establishing the landcover tag for any 'missing' concepts and document other tags where there may be confusion. I have just reworked the text of this proposal to clarify what is being proposed. I have also created a new Landuse article for a general discussion of Landuse and created a redirect from Landcover to this proposal. Fyi, PeterIto 11:36, 28 December 2011 (UTC)

I thoroughly approve of this idea. The current system is full of problems; land-use and land-cover are quite distinct things. Eg. 'grass' is not a land-use (ie. a piece of land cannot be said to be 'used' for grass- that's merely a description of what's on the land, which could be part of for instance a residential area. --SDavies 11:20, 22 January 2012 (UTC)

I really do like this idea. I would also suggest landcover=hedge for planted hedges (wikipedia) (but it could also be covered by shrubs or bushes?) and landcover=bedding for plant bedding (wikipedia). Could this also maybe improve city squares (highway=pedestrian in area=yes)? Mirar 19:12, 19 May 2012 (BST)

References

I've only skimmed these, but they may be useful in deciding whether and how to map land cover:

 Michael Z. 2011-07-28 03:04 z

Good idea/concept

I found this page while searching for my own - very similar proposal. If there is this one, I'll just add my ideas (bulletpoints for easier reading ;) ). Any tags names or namespaces are just for illustration and not meant as definitive

  • Reasoning - it is all complicated today, number of keys describe the same feature, one feature is described by more keys.
    • There should be a distinction between what is there (landcover) and to what purpose does it serve (landuse).
    • landuse and landcover are independent - there can be a tree-covered area (forest,wood...) used comercianlly, for recreational purposes, for scientific purposes etc.
    • Ridiculous combinations like landuse=grass could disapper. Grass is just cover, the use can be anything from golf course to wild grass areas
    • on a general map it is landcover that should be rendered (there is a forest, building...) not landuse (whatever is there is used commercially, for residence, for recreation). There can even be multiple landuses for the same place (unlike landcovers).
  • Useful for
    • rendering in higher zoom leves
    • "fake" aerial imagery
    • analysis visibility (I am standing in point A, can I see point B?)
    • environmental analysis (flood risks, animal migration possibilities...)
    • many more I cannot think of now (that is the point of open geo data)
  • Total coverage - Landuse should be designed in a way making possible that any part of earth is covered exactly by one landcover tag. Therefore:
    • two landcovers should never ever overlap
    • landcover should be tagged prominently as multipolygons (not on the way itself), probably with use of some sort of multiline.
    • Only the border should be tagged on the way (fence, curb/kerb, wall...)
      • Same cover divided should be tagged as separate multipolgon
      • if there is no physical divider, only source would be tagged on the way itsef
  • Ease of tagging (and automated data processing)
    • there should be a limited number of base tags to describe any landcover (landcover = [paved, vegetation, construction, water, non-vegetated]).
      • This should be rarely canged, if at all.
      • Anyone should be able to classify any given piece of land within the top class
    • each of these could than by expanded (most common values would be stable, other values would be allowed)
      • landcover:paved=[asphalt,concrete, setts,...]
      • landcover:vegetation=[forest,grass,bushes,...]
  • Difference between landcover and surface is mostly customary
    • surface for linear features such as highway
    • landcover for areas
    • lancover together with usability could in fact deprecate surface=*, but that is really a long run
    • surface became quite useless, since there are so many values (writing a router that could tell you where you can get is virtually impossible - one would need to enumerate all English words possibly describing surface)
  • Why it is really needed and not some sort of re-factoring exercise
    • numerous proposals around this have been made, mappers are botherd
    • nobody knows not only what value to use for certain real-world object, but not even the key
    • it should be as easy as "what_I_describe(:more_specifically)=how_I_describe_it" - landcover is, other combinations are just not
    • Having asked this question, I could not get any acceptable answer (besides splitting the places into smaller areas and tagging almost each flower separately) - because of missing landcover tag

--LM 1 20:34, 26 January 2012 (UTC)

Ease of tagging

(As a response to the bullet, "ease of tagging" above) To avoid the situation with the many-valued surface, I think there need to be some kind of hierarchy in the land_cover keys. It would be practical if the top level could have something between three and seven values. There shouldn´t be to many levels either, two or three, more lvels only used for very specialized mapping.

One possibility/problem is that top level categorization is easily done in a binary fashion, with questions like this (i.e.):

  • Land or water?
  • Vegetatated yes/no?
  • "urban" or "nature" (bad names)
  • and many more quetsions.t or

This could give some branches on a tree:

  • industrial landscapes: Land/NotVegetated/"Urban"
  • bare_rock/desert: Land/NonVegetated/"Nature"

If I avoid the urban land cover (buildings/industries/large areas of paved nothingness) I find it rather easy in the very top levels:

  • Water
  • Land/Vegetated
  • Land/NotVegetated

this high in the hiearchy, one can easily skip one level and flatten the structure to:

  • Water
  • Vegetated (land)
  • Unvegetated land

Unvegetated land in nature is a few areas , high mountains with visible bedrock, deserts and coastal cliffs. My little problem is that it also includes many urban areas, I really would like to find something that says unvegetated "nature".. /Johan Jönsson 20:16, 21 February 2012 (UTC)

I think your suggestion is a very good one. Is there any recognised hierarchy in professional/academic circles that we could adopt I wonder? PeterIto 13:46, 22 February 2012 (UTC)
Yes, there are a couple, they have been discussed. Can´t find the discussion of them above, it must have been held on the maillist. Anyhow, the UN-organization FAO have one:
See figure 7 in ch 2.3.1. in http://www.fao.org/docrep/003/x0596e/x0596e01f.htm#p617_50319
  • Level1: Primarily_vegetated or non-vegetated
  • Level2: Terrestial or Aquatic/flooded
  • Level3: "Cultivated" or "natural" (a bit irritating land_use connection)
Giving in total: eight different top categories.
Example of the eight:
1) Farmland/forest 2)Steppe/jungle 3)Rice_paddy 4)mangrove_marsh 5) Townland 6)Bare_rock 7)Dam 8)Lake
I think they are way to theoretic and we need to find a way to i.e. separate jungle from plains on the top_level.
Btw, I think the openstreetmap wetland-scheme is so good that we do not need to think more about all those odd cases (it covers the vegetated and unvegetated aquatic)./Johan Jönsson 19:30, 22 February 2012 (UTC)
I am not an expert in this field, but would be happy to support an proposal that made sense and came from an organisation of standing such as the FAO. My only comment is that from the article I am still not clear how to work at the more detailed level. How should one tag a 'forest' area which consists of tress that are only a few feet tall, or grassland with interspursed mature trees or thick cover of trees with a closed canopy. They allude to such a classification distinction but I don't see a complete hierarchy for us to implement. PeterIto 18:07, 23 February 2012 (UTC)
I wrote the above as a comment on the "ease of tagging"-bullet, where LM 1 asked for a set of a few top-level categories. The FAO-system tries to be a bit dynamic. At top-level there are 8 classes but each class then have its own tailored set of subdivisions, called classifiers. I am not suggesting that we use the classifiers-system, I was only looking for possible ways to form the top-level categories for land_cover. (More on FAO in a separate header, below) /Johan Jönsson 17:14, 23 February 2012 (UTC)
USGS land cover definition to be used for remote sensing, NLCD92, also have 8 top-level categories. (and only a total of 23 on second level). http://landcover.usgs.gov/classes.php Here is a comparison between FAO and USGS
The eight FAO-categories, with my own names and some grouped together.
  • FAO-1) cultivated vegetation
  • FAO-2) natural vegatation
  • FAO-3 & 4) wetland
  • FAO-5) urban
  • FAO-6) barren
  • FAO-7 & 8) water
The eight NLCD92-categories, with corresponding FAO-category (NLCD92 have more diverse vegetation):
  • "cultivated" (herbaceous planted/cultivated) (FAO-1)
  • "orchard" non-natural woody (FAO-1)
  • "Grassland" (Herbaceous Upland) (FAO-2)
  • Shrubland (FAO-2)
  • Forest(ed upland) (FAO-2)
  • Wetlands (FAO-3)
  • Developed (FAO-5)
  • Barren (FAO-6)
  • Water (FAO-7)
/Johan Jönsson 18:49, 23 February 2012 (UTC)

FAO land cover system for vegetation

(Posted as a response to a detailed question on a discussed classifying system, if to be used in OSM simplifications is needed.)

The FAO-system for classifying vegetatated areas uses the shape and form of the vegetation, rather than a species-related classification. the system is based on this method:

  1. identify all vegetation
  2. divide it into groups: tree, shrub and herbs
  3. Determine for each group its "cover": is it sparse, open or closed
  4. Choose the dominant lifeform, non-sparse trees goes first, then shrub, then herbs.

For PeterIto questions above, the fAO answer would be:

  1. How should one tag a 'forest' area which consists of tress that are only a few feet tall
  2. " woody plants lower than 5 meter are classified as Shrubs"
  3. I assume closed or open cover.
  4. dominant lifeform is shrubs.
If the cover was closed it is called a "thicket".
If the cover was open it is called "shrubland"
  1. grassland with interspursed mature trees
  2. trees and herbs
  3. I assume the trees are sparse.
  4. Dominat lifeform is herbs.
It is called "herbaecous"
If the trees where not sprase, it would become a "woodland"
  1. thick cover of trees with a closed canopy.
  2. trees
  3. closed
  4. dominant lifeform is clearly trees
It is called "forest"

After this initial work it is possible to add classifiers on height, leaftype, leaf phenology (decidious), spatial distribution. /Johan Jönsson 17:52, 23 February 2012 (UTC)

So this would allow one to say "The area consists of a closed herbaceous layer of unimproved grassland with scattered tall deciduous trees". That would be neat and I could see how a clever visualisation system in a computer game could have a go at creating a realistic representation of the scenery based on that description. I think that it pretty interesting. PeterIto
It is indeed very interesting, but it is more complex than what Johan is describing. The second question is actually if there is water and if the area is permanently or temporarily completely covered with water. They use a 2-phase-classification system, where the first phase consists of 3 steps (easy yes/no-questions) resulting in 8 type of basic classes. These get refined in the second phase.--Dieterdreist 20:01, 20 October 2012 (BST)
I think from the above two sections that the FAO system is definitely NOT what this osm key should be used for. Most notably landcover intentionally does not distinguish between managed and unmanaged plants. landcover=trees applies equally to anything from primordial coniferous woods to a commercial Christmas tree plantation, the distinction between the two is their land use, not their land cover. Similar for any other plant and non-plant land cover.Jbohmdk 05:06, 10 June 2013 (UTC)

Status of proposal

At what point should we say this proposal is essentially dead and without a viable future _or_ that it remains live and is ready for a vote? --Ceyockey 00:52, 22 November 2012 (UTC)

I wouldn't call it dead. I'm using it wherever possible, but I'm also aware that this topic is disputed. The main problem in my opinion is the fact that land cover is something you want to see on the map. As long as there is no support for the most important values in the main renderers people will not use the tag. And as long as the tags are not used, renderers ...... duh. --Imagic 12:17, 22 November 2012 (UTC)
As a relative newbie I found the above discussion very helpful to read, and I like the idea of the concept of landcover even if the proposal doesn't go anywhere. I had a hard time understanding natural=* for a long time because I kept fixating on whether it was untouched-by-man natural or not; eventually I realised that whatever the actual word "natural" means, in OSM it means landcover and is used to tag landcover (except when there's an appropriate landuse tag instead). This was useful for natural=water, where I spent a lot of time dithering and reading wiki pages as to whether something was a "basin" or not, before finally deciding that it's all water and can be tagged with a landuse later if that's appropriate. I also spent a lot of time trying to understand the debate over natural=wood vs landuse=forest, and in the absence of knowing who planted the trees or how often (if ever) they get logged (which you can't tell from the air or from a physical survey) I settled on natural=wood because it is neutral as to how the trees are actually used, if you understand the tag "natural" to mean "landcover". It also is amenable to overlapping with various other landuses, such as landuse=residential.
All of which is to say that I found the discussion on this page relevant, so if the landcover=* proposal ever officially dies it would be nice to incorporate some of it over at natural=*. This was a very confusing issue as I was trying to get up to speed. --Blahedo 00:24, 25 November 2012 (UTC)
I've been using things like 'landuse=grass' and 'landuse=basin' for quite some time and I think it is useful to use 'landcover=grass' and 'natural=water' instead of these as they are merely descriptive rather than illustrative of an inferred use case. For instance → http://www.openstreetmap.org/?lat=39.631936&lon=-75.661163&zoom=18&layers=M , where all the green and blue could be accurately revised to landcover and natural, respectively, retaining the landuse for the water cover as they are known to be basins for rainwater runoff. --Ceyockey 17:08, 25 November 2012 (UTC)
Isn't the proposal ready for voting? It's already more than 2 years old and there hasn't been any discussion for a while anymore. Getting this in to the wiki might boost the usage of it and the render hopefully will insert it into there themes.

Should "area" be added to "landcover"?

In other words, when we use "landcover=" should we also use "area=yes", or is "area=yes" provided by the interpretation of "landcover"? --Ceyockey 15:07, 24 November 2012 (UTC)

In my understanding the key landcover describes how an area of land is covered, therefore area=yes is implied. --Imagic 07:42, 25 November 2012 (UTC)

bushes vs. scrub

Lately I did some research amongst native speakers regarding "bushes". I mostly got the feedback that it is not a good word for land cover and that scrub(land) or shrub(land) would be better. As the usage numbers of "bushes" are still rather low I want to suggest to change bushes to scrub. This would also be more consistent with natural=scrub. (I myself am a german native speaker so I fully understand if some people prefer "bushes". But in OSM we should use british english words.) And if someone is interested: I started a JOSM style for landcover. --Imagic 09:11, 23 January 2013 (UTC)

I support landcover:scrub --Hedaja 20:23, 18 March 2013 (UTC)
I believe we need to distinguish two meanings of the words bush and bushes here. I suggest we use landcover=scrub for the landscape type consisting of low wild-looking vegetation found in places where trees cannot grow or simply have not yet grown high enough to be seen, while we use landcover=bushes for a dense but somewhat uniform growth of many instances of the low plant type individually known as a "bush". And yes, I have seen both within a short distance of each other.
Scrub is the landcover typically seen in landuses such as uncultivated natural "scrubland", landuse=greenfield and landuse=brownfield. Bushes on the other hand is a landcover typically seen in gardens, parks, hedges and plantations (e.g. tea and various berries). Either landcover may be found in places such as woods. In suburban areas, some gardens may have scrub, others bushes depending on the residents personal tastes and abilities. There is full orthogonality and mixability here, a plantation can include many acres of bushes grown for their commercial produce and some unused areas with scrub. A (semi-)natural wood can include some patches of scrub and some patches of bushes with wild berries.
Oh, and the African landscape type known as "the bush" is something quite different from either and more a landuse than a landcover, as it is diverse enough to hold multiple landcover types within it.Jbohmdk 04:52, 10 June 2013 (UTC)
Wahtever, I would simply add landcover=scrub to the table and see what mappers pick. landcover=bushes seems almost unused though.

Another way to distinguish land cover, surface and land use

From reading the comments, I realize that a way to clarify and untangle the concepts involved here:

  • land cover is what you can actually see in aerial photography or by looking down/around from normal human eye level, especially if it is biological or geological (as opposed to e.g. buildings and roads). It is what faces the sky: Tallest plants (not one by one), barren soil, barren mountain rocks etc. A land cover is typically (not always) larger than the typical C/A GPS uncertainty of 2.5m to 25m. Not all of planet Earth has a land cover. landcover can only be tagged on areas, not on ways or points.
  • surface is the upper layer of the planet if vegetation etc. is hypothetically stripped off (without actual ecological consequences as this is only hypothetical). This may be a natural surface such as rock, sand, soil, water or a man made surface such as asphalt, concrete, paving stones, or pebble stones. Surface is mostly tagged on mad-made barrent things such as the active parts of roads, plazas, sports pitches etc., but may also be tagged where the surface beneath a landcover is unusual, such as trees growing on water (mangrove) or grass growing on sand. surface can be tagged on areas but would mostly be used on ways and points that already carry a primary tag which makes it relevant. For instance a way tag as a highway will often have a surface to indicate if and how it is paved.
  • landuse is the how an area is used, which may or may not related to its landcover and/or surface. It is not the why or the what, it is the how. E.g. being legally designated as a public access commons (in England) is not a land use, being used as the commons of an English rural community is a land use. Similarly growing trees with a focus on producing valuable construction timber is a land use. Land use tags should be used where the use is known and not implied by some other tag. E.g. A highway is already a land usage excluding most others (it could still be part of an aerodrome or a car racing track), so there is no point in having a landuse=road tag.

All 3 tag types should be simple but not oversimple classifications easily understood by novice mappers, such as "trees", "bushes", "grass", "mud", "barren" (specify with surface) or "steel", "asphalt", "concrete", "earth", "sand", "mud", "water". Fine distinctions unlikely to be understood by a mapper should be delegated to subtags such as trees=oak (not trees=deciduous, deciduous=oak which is too complicated). Implicit grouping of related predefined tag values into broader categories is a job for the data consuming software.

Some examples:

A village pond will often be landcover=waterplants, landuse=water, water=pond (implicit: surface=water).

The Sargasso sea is probably landcover=seaweed, natural=ocean, (implicit: surface=water).

Most of the Atlantic is probably natural=ocean, (implicit: surface=water) (implicit: no landcover if not specified)

Memorial trees in a graveyard may be landcover=trees, surface=grass, landuse=cementary .

A tree lined boulevard with trees so large their branches touch across the road may be highway=secondary, surface=asphalt.

Jbohmdk 06:26, 10 June 2013 (UTC)

Lancover=lawn

I propose to change the name of the landcover=grass on landcover=lawn and add landcover:type.

Type of grass can be tagged as grass:type.

--Władysław Komorek (talk) 12:03, 29 September 2013 (UTC)

The usual convention is to tag the attributes, where "type" can refer to all sorts of different classification lists (by taxon? by (maximum) height? by usage? by soil moisture? by sharpness of the edges?). And even if there is a globally agreed primary classification list, a convention would be to use grass=* instead of any *:type key. Alv (talk) 21:47, 29 September 2013 (UTC)

Rendering

It appears to me the proposed and proper separation of landcover (or surface) and landuse would also help renderers to guess the vertical stacking of features. E.g. landuse= (just an administrative intention of usage of the area) would be the lowest level, then landcover= on it, then highway= and building=.

Currently it is not so easy. Consider an area of highway=pedestrian+area=yes+surface=paved (or leisure=park+surface=paved) and then smaller areas overlapping it being landuse=grass. On Mapnik I get the whole area as grey with no trace of the grass (and layer=1 does not help). On other renderers I get grey main area with green areas where tagged. Maybe these are bugs in some of the renderers, I don't know. But I can't argue with them as long as the meaning is not well defined in OSM itself.

Until the stacking is well defined, it sometimes is a hit and miss experimentation on which tags to use on which areas or whether to use a multipolygon with the grass areas being "inner" roles. For some areas multipolygon may be appropriate, for some it may not (e.g. the paved and grass areas are all formally part of a park or pedestrian zone, you do not want to exclude them). Currently, do we want the renderers to have special exceptions, e.g. to know that all landuse is on the lowest level, except when it is grass? Properly separating the layers would allow you to have big landuse=residential and small landcover=grass on top of it. Currently, when both are landuse, how should renderers choose the precedence? The one that is smaller is on top? - Aceman 17 Oct 2013.

Update 2014

While mapping in the Alpes I also got a problem with the mishmasch of landcover features. After reading this proposal and the comments I studied two landcover classification systems: NLCD92 and LCCS.

To get an overview of this existing landcover classification systems I created two tables with pictures:

Then I tried to find a workable conclusion of this two systems in due consideration of some existing tagging-scheme in OSM. I concluded with 8 main categories and 36 subcategories, describing the whole earth's surface with one main key and 8 sub-keys.

Please take a look at: User:Rudolf/draft_landcover

--Rudolf (talk) 06:18, 29 April 2014 (UTC)

It may be a nice cleanup but not worth it. Reality is often more complex than "every place has a single landcover". How would you map underwater rocks, surfaces or "a mostly sandy area with intermittent water cover and sparse vegetation of several listed types"? RicoZ (talk) 12:19, 16 May 2015 (UTC)

Landcover class or classifier?

The Land Cover Classification System (LCCS) by FAO includes landcover classes and classifiers. The land cover classes are created by the combination of sets of pre-defined classifiers. These classifiers are tailored to each of the eight major land cover types.

For every area you assign the related main type and then allocate all matching classifiers. This can be a number of different classifiers, e.g. trees, shrubs, herbaceous, lichen, mosses also sands, bare rock, gravel and so on. The landcover class (e.g. forest, woodland, shrubland, grassland) is the result after allocation of classifiers. Normally you get the result by software, e.g. dedicated LCCS software or rendering software.

Very simple examples:

  • classifier = "trees" --> class = "forest" or "woodland"
  • classifier = "shrubs" --> class = "shrubland"
  • classifier = "herbaceous" --> class = "grassland"
  • classifier = "herbaceous"+"trees" --> class = "grassland with trees"
  • classifier = "trees"+"shrubs" --> class = "forest with shrubs"

Therefore I propose to define the values trees and grass as landcover:classifier=*.

The key landcover=* should be reserved for the landcover classes, such as woodland or grassland. Otherwise we got a mixture of classes and classifiers, which is very difficult to evaluate. If we use only the classifiers, then we got the result not until rendering. --Rudolf (talk) 21:15, 8 May 2014 (UTC)

Is grass surface or landcover?

Is grass surface or landcover? Bushes? Scrub? Rock? With exception of rare cases there will be always confusion. The only think which is obvious is trees (landcover, not surface), but it is not much :( Otherwise I like the proposal, but why not just to reuse the surface? (with exception of rare things like trees in water etc, which can be solved differently) --Jakubt (talk) 08:19, 26 August 2016 (UTC)

The surface=* is used to describe another physical feature e.g. a road. The landcover=* is a physical feature itself, so it needs no other tag. So it this 'grass' part of another physical feature - then add the tag surface=grass to it. If the 'grass' is not part of feature .. then tag it as landcover=grass Warin61 (talk) 04:02, 5 February 2017 (UTC)

Exclude flat things

I think this key would have been far less controversial and logical if it excluded flat things like grass, asphalt, etc. This ensures it does not overlap with surface=*, and it creates a nice order:

  • landcover=* would describe the non flat landcover (mainly trees or bushes), but it can be omitted when implied by other tags. esp. natural=*.
  • surface=* already describes the flat landcover, and it is already omitted when implied by other tags. e.g. natural=bare_rock
  • landuse=* already describes human use of the land.
  • natural=* already describes for naturally occurring features with no, or with minimal human intervention, and it often also implies the non flat landcover or flat landcover.
  • man_made=* already describes non naturally occurring features.

Examples:

This is backward compatible because landcover and surface are often implied by tags which are already widely used tags. e.g. tagging a forest with only natural=wood implies the non flat landcover is tree, and therefore is compatible.

Additionally, all previous grass uses should be discouraged in favor of surface=grass for maximum consistency with the order above, but this is still backward compatible with current uses, e.g. landuse=grass implies surface=grass. (natural unmaintained grasslands would still be natural=grassland)

This would require abandoning the weird distinction between "highway/routing surfaces that should have surface=* and area surfaces that should have landcover=*" which is suggested in the original proposal.

As an aside, I think landuse=forest should be removed and landuse=wood_farm should be introduced to avoid confusion with natural=wood, but that's a different story.

I am willing to draft a new proposal if people like this. Opinions? -- SwiftFast (talk) 09:23, 20 May 2017 (UTC)

Your flat vs. non-flat distinction does not help, as any theshold would be artificial. Grass grows from 0 to maybe 50 cm, bushes to 200, and trees to 2000, so your definition of flat is just a matter of scale. And I don't like surface to be mixed in when not describing the property of a particular feature.--Polarbear w (talk) 14:44, 20 May 2017 (UTC)
The threshold isn't the exact height. If it's something you walk on, it is flat. If it's something you walk beneath/beside, it is non-flat. Such a threshold is pragmatic, because any given piece of land can have any combination of things you walk on and things you walk beside/beneath. Since it's a combination, these are two distinct attributes requiring two distinct tags (which are sometimes implied and need not be explicit). Unlike manmade lawn, a grassland is an edge case, because it's the only thing you walk *through*, but this one is already covered by natural=grassland, so we're good. -- SwiftFast (talk) 17:40, 20 May 2017 (UTC)
This is getting even more confusing. So if the threshold is "walking on" it means cut lawn falls into flat, and non-flat when unmaintained. And what if people trample over the bushes?--Polarbear w (talk) 22:34, 20 May 2017 (UTC)
Yes. if it's nice to walk on, it's surface=grass. If it's jungly, it's natural=grassland. The map should distinguish the two. Please don't resort into Sorties Paradoxes, in 99.99% cases the distinction is obvious. And when it's right on the edge both tags are fine by me. (You could make such philosophical arguments to "invalidate" any spectrum related tags like hamlet/village, pond/lake)
"And what if people trample over the bushes?" - What if people climb trees or parkour on buildings? It's not regular walking surface and therefore isn't given a surface tag. -- SwiftFast (talk) 18:13, 21 May 2017 (UTC)
And I don't like surface to be mixed in when not describing the property of a particular feature. Is there any technical reason why this would be bad tagging? (e.g. area=yes, surface=asphalt). I thought not liking this is a subjective preference, but Osmose sometimes warns me about it. -- SwiftFast (talk) 06:21, 15 June 2017 (UTC)

Tagging grass under trees?

It can't be both landcover=grass and landcover=trees? So what do we do? what about sand under trees? -- SwiftFast (talk) 18:08, 21 May 2017 (UTC)

If you are on this level of detail, you can tag landcover=grass and draw the individual node for the tree, with natural=tree. Quite common method already. Would you mind calming down a bit? --Polarbear w (talk) 19:54, 21 May 2017 (UTC)
I am very calm and that was a genuine question. I am not even sure my proposal is better and I'm comparing things. I apologize if somehow I sounded combative. -- SwiftFast (talk) 05:11, 22 May 2017 (UTC)
What if I don't want to go into this level of detail, and I still want to indicate this park is gravel-covered and that one is grass-covered? (could be useful information for picnics or ball games and such). I think this demonstrates what I meant by saying any piece of land has two attributes (flat and non flat covers) that can never be recorded by a single tag. -- SwiftFast (talk) 05:15, 22 May 2017 (UTC)
We desperately need a landcover definition encompassing vegetation levels plus topmost layers of geology. Started toying with ideas some time ago User:RicoZ/What_is_needed. RicoZ (talk) 10:56, 30 July 2017 (UTC)

landcover=green

What about a generic value for green landcover for situations where the presence of grass, bushes or trees cannot yet be verified, but what is a identified as a green area. The value description should of course encourage to refine the kind of green.

This would help to resolve the common misuse of leisure=village_green for small green spots that do not qualify as park, garden or recreation ground.--Polarbear w (talk) 17:50, 1 December 2017 (UTC)

Missing from the urban mapper's toolbox

Mapping in a detailed urban area often entails defining areas of (planned) vegetation. Currently this mean abusing these three tags:

  • landuse=grass
  • natural=scrub
  • landuse=forest

What is really being tagged are clumps of trees, bushes, and patches of grass in an area often already defined by another landuse (residential, industrial, railway, etc.). It makes sense to have these available as a consistent landcover set. JeroenHoek (talk) 08:02, 23 January 2018 (UTC)

Main problem is: you never get people to (re)tag to landcover values, unless these tags are rendered appropriately. If the rendering is there, many taggers would adopt the new more consistent scheme. Nobody likes tagging for not-rendered. So you need renderers to a. Assert the renderability, b. set out a course and a date to actual rendering.--Peter Elderson (talk) 09:47, 5 June 2018 (UTC)

Usage - quick note about Paraguay import

I run a quick check why landcover=trees usage massively increased in 2018. It turned out to be result of a single import in a Paraguay that added over 96 000 of landcover=tress elements. It is a great example that raw usage count is not a perfect metric to judge how popular is tag among mappers.

Just because tag usage is growing (even quickly) it does not mean that real mappers are actually using it. Currently about half (depends on how it is counted) of landcover data is from this single import (and remaining data is not checked, even larger part of landcover tags may be imported) Mateusz Konieczny (talk) 08:59, 6 March 2019 (UTC)

--Peter Elderson (talk) 16:44, 8 July 2019 (UTC) I would like to add that Paraguay was a single project by real mappers, but not a single import. The landcover key was selected as best fit for the project. It would not be right to discard this. It is valid usage.

Is this proposal planning to deprecate landuse=forest and natural=wood?

It is not stated outright but implied that part of this proposal is deprecation of landuse=forest and natural=wood. I think that it would be a good idea to make explicit is deprecation of this tags proposed along deprecation of landuse=grass Mateusz Konieczny (talk) 14:14, 6 March 2019 (UTC)

--Peter Elderson (talk) 16:58, 8 July 2019 (UTC) At the same time it is not necessary to ban the old tags all at once. The proposal, in my view, is a preference for landcover over landuse-that-is-not-landuse.

revisited: landcover vs natural

I get the impression that the broad interpretation of "natural" to incorporate artificial/managed/groomed things that grow or flow naturally, has won the battle against the strict interpretation that natural=untouched by humans. natural=tree, natural=tree_row, natural=water are long accepted values in the broad natural category.

In that case most of the proposed values for the natural key would fall under the definition.

landcover=grass => natural=grass. landcover=greenery => natural=greenery. landcover=trees is already covered by natural=wood. landcover=sand => natural=sand

I think the distinction natural=wood (wild wood) vs landuse=forest (managed forest) is not the global OSM-usage of the keys, even if individual (groups of) mappers or communities still maintain this difference for a country or region. With both tags, you can be sure that there are trees covering the area, but you cannot be certain about the use or the management of the wooded area. Even within residential areas both tags are used for areas covered mainly by trees.

Maybe it's time to make that official and change this proposal to use natural=* for all the values. I was all in for landcover, mainly because of the natural=wood vs landuse=forest debate: using landcover avoided the clash. Now I am beginning to feel that maybe the balance has shifted enough to go all natural for this purpose. --Peter Elderson (talk) 21:13, 10 March 2021 (UTC)

Idem. If natural=shrubbery succeeds it would be interesting to take stock and see if the concerns raised by landcover can be addressed via the natural=* namespace. landuse=grass is an obvious candidate to eventually provide an alternative for because it is used for any bit of grass anywhere, which often has nothing to do with landuse and often overlaps with proper landuse-tags. --JeroenHoek (talk) 21:31, 10 March 2021 (UTC)
I would like to point out:
  1. natural=* is many things, including land-cover, land-form (also natural=cave_entrance; cf landform=*), some non-land-cover water-related features (depends on how much nautral=bay, natural=spring, etc is considered land-related), objects (natural=stone), plants (natural=tree, natural=shrub), etc. Key:natural#Values is already breaking it down quite clearly.
  2. natural=* is basically the same argument against man_made=*, that it is too broad and ambiguously named. It feels a bit contradictory that people start to see man_made=* is a problem, while natural=* is accepted.
---- Kovposch (talk) 05:08, 11 March 2021 (UTC)
Broadly agree with Kovposch. The problem with natural=* is the use of it for 'unnatural' things particularly with new mappers who use a stricter definition of the word. By grouping things into land use, land cover, land form etc this makes things more orgainised for both mapper and render. While most think landuse=forest is always covered with trees, this is not always the case as at some point in time the trees may be harvested leaving bare ground while new trees may be planted. Warin61 (talk) 08:30, 11 March 2021 (UTC)
I agree it's a broad category, but it's reasonably well defined as "features that form, grow or flow by themselves, even if created, planted and/or maintained by humans". Man_made and amenity are a lot worse, I think, but even that does not really pose a problem. They all mean "this thing is...." and you have to know or look up which one to use. With natural, I think the knowing and looking up is much easier. New mappers will learn very soon that natural is broadly but clearly defined, it makes much more sense than using landuse for landcover that is not use of the land; that never makes sense. That's why landcover usage increases despite not being rendered.
I think the broad definition of natural is the current state of affairs. You can't simply reorder that by making the subcategories separate toplevel keys; you would just add more confusion. Even if you could I think it would create more definition and borderline problems than it solves, making the learning curve even steeper.
natural=wood at the moment can be anything from a patch of trees in an industrial zone to an immens forest, and so can landuse=forest. (Both can have permanent or temporary sections without trees. Now if sections without trees are not mapped separately, you can't do anything about that, you van only render or use what is mapped.) Probably with rain forests there is a preference for natural=wood, and the managed forests of Europe might prefer landuse=forest, but for the bulk of the data the data user can't be sure. That's why they will use only what they can be sure of, and that is: there are trees. In some cases an educated guess may be possible, but then they would have to apply the algorithm to both tags equally. So in practice there is no difference between these tags at the user end.
--Peter Elderson (talk) 10:04, 12 March 2021 (UTC)

Januari 2023 state of affairs - Usage of the landcover key is still growing. I asked OSM Carto for rendering when the usage was about 75000, got turned down because of low usage. I asked what usage would be enough, and 100000 was mentioned. After that the arguments shifted to "we're not counting the import", and "only a few unique users"... probably yet other arguments have taken over since! Interesting to see that landcover=trees is by far the most used tag, even though there are two tags, one in natural and one in landuse, with globally the same meaning: there are trees. Number two: grass, also with matching natural and landuse variants (grassland and grass), also all meaning one thing for sure: there is mainly grass. Number three, scrub, has no landuse variant but a commonly used natural-counterpart, again in practice meaning the same: there is scrub. The notion of natural=* meaning "this is (a) natural *" has weakened even further, I think, and "this item flows, grows or evolves more or less naturally" is now the general view. Of course, mappers may have differences in mind when using one or the other of the variants. Thing is, others have other differences in mind, or other preferences. End result is that the dat user can not draw conclusions from the variants in the database, only the common aspect: this land is covered by *. Other in-use values of landcover are covered by either natural (according to the "grows by itself"-definition) or surface. I think these should simply be natural=* or surface=* tags. --Peter Elderson (talk) 14:28, 20 January 2023 (UTC)