Proposal:Landcover proposal V2
| landcover proposal V2 | |
|---|---|
| Proposal status: | Proposed (under way) |
| Proposed by: | Cartographer10, Tjuro |
| Tagging: | landcover=* |
| Applies to: | 
|
| Definition: | A key to describe the physical coverage of an area. |
| Statistics: |
|
| Draft started: | 2023-01-28 |
| RFC start: | 2023-02-10 |
Proposal
The goal of this proposal is to introduce landcover=* and create a orthogonal tagging scheme that separates the tagging of functional and physical objects. This updated tagging scheme will make landuse/natural/landcover much easier to use and understand for new and experienced mappers but also for data consumers. This will also make introducing new tags easier. In general, it should create a consistent and scalable tagging scheme for the future of OSM.
Introducing landcover
The landcover key will be introduced with the following definition: To describe the physical coverage of an area.
The following initial landcover tags are introduced:
- landcover=grass
- landcover=trees
- landcover=mud
- landcover=shingle
- landcover=bare_rock
- landcover=sand
- landcover=scree
Cleanup landuse and natural values
In order to support this stricter division between functional and physical objects, some existing values have to be introduced under the landcover key. The following tags should be deprecated and replaced with their landcover=* equivalent:
Rationale
The first landcover proposal Proposed_features/landcover on OSM dates from 2010 already. However, this proposal never reached enough consensus to be brought to a vote. Since then, the OSM tagging scheme has undergone many changes and mapping landcover and landuse has always been a topic of discussion within the OSM community. This has led to confusion among mappers and inconsistencies in the tagging scheme for landuse and landcover mapping.
The biggest problem with the current tagging scheme is that tags for functional and physical tags got mixed up in tags. The result is that there are often discussions about which tag to use. Even for experienced landuse mappers, it is not always clear what tag to use. The result is that wrong, functional tags get used for describing the physical coverage and that details in landcover cannot be captured easily by mappers because correct tags are missing.
The proposal sees the following tags in relation to each other:
- Landuse: The landuse tag should solely be used for tags that describe the functional use of the land. For example, landuse=meadow describes that a grass field is used for agricultural purpose. landuse=residential describes that an area is used for living. Tags like landuse=grass however describe the physical coverage. It does not describe a function. This function should be covered by tags like landuse=recreation_ground, leisure=park or amenity=festival_grounds. These areas then consist of pieces of, for example, grass and sand. Nearly all current landuse tags already comply to this definition.
- Natural: The natural tag should solely be used for natural entities like landscapes, landforms and other physical features. Think of volcano's, plains, beaches, caves, wetlands, forest (continued to be tagged with natural=wood), tree_rows, valleys and water bodies like lake and rivers (continue to be tagged with natural=water). The natural tag already has most of these cases covered. Note that this does not cover things like national parks. These are boundaries and are tagged separately.
- Landcover: The landcover tag should be used to describe the physical coverage. A forest (as in ecosystem) consists out multiple landcovers like trees but also smaller clearings like with grass or sand. The natural forest tag is used to describe the forest (name, wikidata etc) and landcover is used to fill the area with smaller polygons of landcover=trees, landcover=grass, landcover=sand etc.
- Leisure: This tag also contains some values like leisure=park or leisure=garden that describes the function of an area rather than the physical coverage. For physical coverage, lower tags like landcover and natural (for example for mapping natural POI's in a park or garden) should be used.
Advantages
Such a separated system has several advantages:
1. Finding tags is much easier: As a mapper you have to ask your self, do I want to map physical coverage, the function of an area or a natural entity? Based on that question, you should be able to quickly find the correct tag. This makes it easier for both new and experienced mappers to find the tags they need.
- As example, imagine you see a grass area on a satellite image you want to map. If you don't know the function, it is still valuable to map the grass as landcover=grass. Another mapper can than add the function like landuse=meadow.
- The same with natural=grassland. You can always objectively say, this land is covered with grass where it is not always clear whether something also classifies as natural=grassland. Instead of potentially incorrectly using a tag, map the physical coverage and let another mapper redefine it if they know more.
- Another example is natural=beach. The beach it self is a natural feature. See it as a natural point of interest (POI). The tag it self however does not describe the landcover. For this, landcover values like sand should be used. If the beach consists out of multiple landcovers (e.g. sand and rock), the individual landcover polygons should be mapped inside the polygon of natural=beach. This is a good example of the division between natural entities and landcovers.
2. Introducing new values becomes easier: Because of the separation of function and physical coverage, it should no longer be a discussion where to introduce a new value.
- As example, during the discussion of the shrubbery proposal (Proposed_features/shrubbery), the discussion often was about what key to use. With the proposed changes, you are basically automatically redirected to the correct key based on whether you want to describe: a function, a physical coverage or a natural entity.
3. Improved data usage: For data consumers, this tagging scheme also makes using the data easier to use and understand.
- Take renderers as example. Because of the mix of functional and physical objects it can be hard to create a logical and consistent rendering. With landcover it is possible to create more logical rendering. A possible render philosophy for landcover and landuse would be to render landcover with high contrast and render the underlying landuse with less contrast. In this way you have the freedom to only map landcover but also have the freedom of mapping the landcover on top of an landuse.
- Also for other data users, a more consistent tagging scheme is easier to understand and thus to use.
Ongoing tagging discussions
This proposal sets the foundation for a better tagging system. However, some values are deliberately left out due to ongoing discussions. The community is encouraged to discuss these issues and resolve them in separate proposals. Some of these discussions are:
- Tagging forests and forestry areas (see Forest).
- Mapping highways as areas (and as such mapping pavements of an area).
- What to do with landuse=flowerbed and landuse=greenery.
- Have another critical look at some landuse/natural values whether they should be moved to landcover to.
Differences with surface key
One might argue that there is much overlap with the surface=* key. This is however not the case. The following sentence from the surface wiki page describes it the best:
The surface key is used to provide additional information about the physical surface of roads/footpaths and some other features, particularly regarding material composition and/or structure.
The surface tag is used to for example indicate the material of roads, path and man made structures like sports fields ( and more things then listed here). Some values like surface=grass on a soccer field imply landcover=grass ( there is no need to double tag). The surface key is a property of the soccer field however and not a tag to describe the feature.
Some also argued that the surface key should be used as top level key like landuse and natural. This is however not desirable. This means that a single tag can both be used as an attribute key (e.g. for a highway in the case of surface) and as top level key to for example map a grass field. This means that the two features collide, that has unwanted consequences like needing to sort feature keys on what feature is more important when used in a combination. And not knowing what part of the attributes belongs to what feature tag.
Choice of the landcover system
During the 2010 proposal, different landcover systems were proposed. We decided not to adhere to much to an existing system but shape it to the needs of OSM. Below paragraphs explain this reasoning more.
Why not use a more traditional landcover system?
Like stated earlier, a landcover must be a homogeneous object where you can point at the object. This contrasts with many other landcover systems. These usually also include values like: “cultivated”, “urban” and “built_up”. These values would not work for OSM, as OSM is more focused on detail and smaller objects, in comparison to landcover maps of the world. If a landcover contains other landcovers, it’s not a landcover.
Why not use a higher, abstract classification system?
Some users suggested on the 2010 proposal to use an abstract classification system like *paved, vegetation, construction, water, non-vegetated* and then use sub tags to further define the landcover (e.g. https://en.wikipedia.org/wiki/Land_cover). The biggest downside of this is that this makes it unnecessary complex. To map simple features like grass and trees, mappers would have to use 2 tags compared to 1 in the proposed scheme.
Tagging
Landcover should only be tagged as an area. Different landcover areas generally should not overlap (physically layered landcover e.g. landcover below a cliff covered in grass excluded). It is possible however that a landcover is contained in a larger, higher meaning object like landuse=residential or leisure=park.
Values
The following initial landcover values are proposed. These are currently the most used values (value inspiration https://wiki.openstreetmap.org/wiki/Proposed_features/landcover en https://en.wikipedia.org/wiki/Land_cover) or clear landcover examples from the natural key.
| Tag | Definition | Comments | Taginfo counts |
|---|---|---|---|
| landcover=trees | For areas covered with trees | Useful additions are tags like leaf_type=* and leaf_cycle=* | |
| landcover=grass | For areas covered with grass | Use landuse=meadow for grass fields with an agricultural function | |
| landcover=mud | For areas covered with mud | Also see wetlands for vegetated, flooded plains | |
| landcover=shingle | For areas covered with shingle | - | |
| landcover=bare_rock | For areas covered with bare_rock (also sometimes called bedrock [1]) | - | |
| landcover=sand | For areas covered with sand | - | |
| landcover=scree | For areas covered with scree | - |
landcover implications
Some current tags imply a landcover and therefore, landcover does not need to be added to these tags. Whether a landcover key is implied depends on the function of the tag. If the function only ever uses one landcover you can imply that landcover. If there is a chance there could be more than one landcover, the landcover cannot be implied as this would inhibit the mapping of landcovers in that area.
- Example implied landcover: landuse=meadow implies landcover=grass. The definition of meadow in OSM is that it is a grassland used for agricultural purposes.
- Example where landcover is not implied: landuse=recreation_ground. This area can consist out of multiple landcovers like grass, sand etc. Therefore, landuse=recreation_ground cannot imply a single landcover
Examples
In the table below, some tagging examples are given.
| Image | Tagging | Comments |
|---|---|---|
  |
landcover=grass | |
 |
Large portions of this area can be tagged with landcover=trees + landuse=forest / natural=wood | For compatibility reasons until the forest tagging has been resolved, double tagging with landuse=forest or natural=wood is recommended. |
 |
Example of landcover=mud | |
 |
Example of landcover=shingle | |
 |
Example of landcover=bare_rock | |
  |
Example of landcover=sand.
For the second image, additional to landcover=sand, the area can be tagged with natural=beach |
|
 |
Example of landcover=scree |
Migration
The proposed changes are significant. Several deprecated tags are well established and phasing them out takes time but there is no hurry. The following migration is advised:
- This proposal does not justify mechanical edits to re-tag object. Mechanical edits should always be discussed within the local community.
- Renders are encouraged to add support for landcover in their maps. Given the usage of some of the deprecated tags, it is advised to keep rendering both tags for some time to remain backward compatible. See also the rendering section for a simple an pragmatic rendering proposal.
- OSM editors are encouraged to update their editors to support the proposed changes. This means that users should be notified that some values are deprecated in favor of others. Also presets have to be updated in the various editors.
See the table below for a summary of the proposed changes:
| Old tag | New tag | Comments |
|---|---|---|
| landuse=forest, landcover=trees | landuse=forest, landcover=trees | Due to the ongoing tagging discussion about how to map forest, this proposal does not change how forest are tagged yet. The proposal merly formalizes landcover=trees which is already one of the 6 documented ways to tag forest. |
| landuse=grass | landcover=grass | |
| natural=mud | landcover=mud | |
| natural=shingle | landcover=shingle | |
| natural=bare_rock | landcover=bare_rock | |
| natural=sand | landcover=sand | |
| natural=scree | landcover=scree |
Rendering
How landcover is rendered is up to the individual renderers. It is however important to keep backwards compatibility. Also, landcover values can be rendered in a very pragmatic way. Render the landcover values the same as the original counterparts. E.g., landcover=grass can be rendered the same as landuse=grass. The same applies with for example landcover=trees and the other forest values.
Because landcovers are precise, they can be rendered with more contrast. Then the rendering of landuse should be lighter so landcover mapped on landuse has sufficient contrast. However, if a landuse implies a landcover then the rending of the landuse should be similar to the rendering of landcover. In that way mapping landcover on top of other landcover is discouraged.
Features/Pages affected
- Wiki page landcover=* need to be edited.
- The wiki page and all references for tags listed to become deprecated need to be edited due to deprecation.
- Wiki pages have to be made/edited for the proposed landcover values.
External discussions
- In 2010 and later, quite some discussion happened on the original proposal: Proposed_features/landcover.
- Forum announcement: https://community.openstreetmap.org/t/rfc-feature-proposal-landcover-proposal-v2/8818
- Mailing list announcement archive: https://lists.openstreetmap.org/pipermail/tagging/2023-February/066971.html
Comments
Please comment on the discussion page.