> The end to this madness is for renders to recognise that the landuse=forest needs to be rendered differently from natural=wood.
Until several years ago the “standard” style (Openstreetmap-Carto) did show a difference between landuse=forest and natural=wood. However, mappers used these two tags interchangeably even then. The rendering was changed to match actually database usage on a global scale, which is that both tags are often used to tag any area covered with trees. The current rendering follows tag usage and the current wiki page, which also discusses this issue in depth. I wish it were possible to fix this, but the different meanings of “forest” and “wood” in various English dialects make it difficult, even before we add other languages and cultures to the mix. On Mon, Jan 21, 2019 at 8:04 AM Warin <61sundow...@gmail.com> wrote: > On 21/01/19 05:52, Kevin Kenny wrote: > > > On Sun, Jan 20, 2019 at 1:33 PM David Marchal <pene...@live.fr> wrote: > >> All is in the title: when hiking in a forest (I mean, an area > considered as a forest by authorities), I often encounter other landcovers, > like scrubs in recently teared down parcels, or scree in the mountains. > These area, although, clearly and morphologically, not a forest, are still > mapped as such, as they are considered to be part of the forest and are > treated this may, but they are morphologically not the forest: the forest > is the area administratively regarded as such, but it is not always the > case; if I want, for instance, to map them as a scrub area of the forest, > as the polygons overlapped, they are rendered in a mixed way. Is there a > recommended way of handling such cases without broking display? If so, what > are they? The landcover tag? boundary=forest_compartment? Another? > > This again. > > And it will continue to occur! > > And reoccur, again and again. > > > > > There's a failed consensus here - and you risk reversion with either > decision. > > > > I tend to follow the principle that landuse=* denotes the land USE, > > not the land COVER, so I don't demand that every square metre of > > landuse=forest be covered by trees. > > +1 > > > But many do, and the renderer > > follows their inclination. > > > > natural=wood is a possibility to show tree cover - but that leads some > > to argue that it has to be a 'natural' wood - whatever that means. > > I've heard it argued that the 'old second growth' forest that's > > increasingly common near me is still not 'natural' because a skilled > > forester can still find the human impact. (Of course, that was true > > even before the Europeans arrived - there was considerable > > pre-Columbian human impact on these forests.) > > Those who argue this have no problem abusing the landuse tag, so I see no > reason why the tag 'natural' cannot be similarly abused. > The OSMwiki for 'natural' even states that is can be used for human > effected things. > > > > > landcover=trees doesn't render, but is at least unambiguous that it > > means tree cover and nothing else. > > > > landuse=forestry, for a managed forest, has been proposed but received > > a lukewarm reception. > > For forestry area I tag landuse=forest with produce=trees (or what ever is > produced by the area for human use). This makes it clare that the area is > for productive human use. > > > > > For the state forests and wildlife management areas around here, I tag > > at least boundary=protected_area. (Tag with the right protect_class, > > and add leisure=nature_reserve if it fits: 'nature reserve' covers a > > lot of things.) If I'm mapping land cover (I seldom do), I will use > > natural=wood to mean 'tree cover' and let others fight over it. > > I too use natural=wood with landcover=trees to map a tree area. > > -------------------------- > The end to this madness is for renders to recognise that the > landuse=forest needs to be rendered differently from natural=wood. > The essential difference between the two is that landuse must have some > human benefit, a produce, and a clear way of doing that is to add the > rendering of a axe to the tree. > > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
