[Tagging] landcover=trees definition

Friedrich Volkmann bsd at volki.at
Sun Aug 16 10:00:11 UTC 2015

On 16.08.2015 04:00, Daniel Koć wrote:
> http://wiki.openstreetmap.org/wiki/Landcover

There is no definition of the landcover=* key. The page features a wide
range of keys including amenity=* and tourism=*.

Even if there were a definition, it would be the wrong place. The definition
belongs to the proposal (Proposed_features/landcover) and/or feature page

> Somebody has just suggested that one should tag the lawns as landuse because
> everything is "use", so this key can be stretched too.

Not everything is "use". E.h. hazard=* is rather the opposite of use. Most
natural=* features denote what's there, not how it is used. Well, you *can*
use a swamp, but if you don't use it, it is a swamp anyway, so this is
really independent of use.

> Of course this is not a substitute for the forest and I try to be clear that
> I don't like it to be used as a general type.
> If you know it's a forest, you should tag it accordingly (once we have
> definition again). But if all you know is "there are some trees", you don't
> know if there are all these things, so you can safely tell only about what
> you know, hence landcover=trees is what you really know.

I have a feeling that this landcover=* thing aims mainly at armchair mappers
who map from arial images but don't know how to interpret them because they
have never been outside. So they cannot distinguish urban lawns from rural
meadows, or meadows from heaths, or orchards from parks or gardens. But they
can distinguish trees from no trees. So they use landcover=trees where they
see trees, and landcover=grass where they see no trees. I came across areas
which were tagged landcover=grass although they were mostly covered by

>> If you cannot decide between landuse=forest and natural=wood, take either
>> one. Just like picking a tracktype.
> Last resort in case of doubts should be something more general, even
> partially, not rolling the dice! Of course that's what people do now, but
> we're discussing here to help them avoid such wicked games with database.

When picking a tracktype you have to roll a dice as well. There's no clear
line between grade4 and grade5 definitions. When in doubt, you have to
choose one randomly. It's still better than omitting the tracktype, because
grade4 and grade5 are on the same end of the scale, so this bears useful

Same for forest/wood. There's no clear line between their definitions, it's
a pity that we have two first-level tags for them in the first place.
Anyway, they are also very similar to each other, and very different from
other "tree-covered" areas (such as avenue trees). So it's fine to pick one
of forest/wood, even if it turns out later that the other would be more
correct. The tags in the database are not graved in stone, we can correct
mistakes at any time. After all, we have not a single faultless object in
the entire OSM database. All of the coordinates are inaccurate to some
degree. Mapping is not an act of collecting faultless data, it's a process
to continuously improve the data.

> Your questions about what lancover really is made me read the wiki and it
> seems it's just a twin for "surface", which "is meanwhile also used to
> indicate the surface type of larger areas, like for a Landuse but is
> generally used as a secondary tag."
> This means more or less that maybe surface=trees would be good, however
> people use it very infrequently and I don't know if it is "primary" or
> "secondary" tag then:

I agree that landcover=* strongly sounds like surface=*, but we can hardly
compare them as long as there's no definition for the landcover=* key.

There's nothing wrong to use surface=* for areas, but due to its original
use it still describes the surface at ground level. Surface=trees would be
strange, because a barely visible path in the forest typically has the same
surface as its surrounding area, which would imply surface=trees on the path.

Friedrich K. Volkmann       http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

More information about the Tagging mailing list