Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stop displaying natural=wood and landuse=forest differently #1724

Closed
iansan5653 opened this issue Aug 5, 2015 · 16 comments
Closed

Stop displaying natural=wood and landuse=forest differently #1724

iansan5653 opened this issue Aug 5, 2015 · 16 comments

Comments

@iansan5653
Copy link

Current woods (natural=wood) are rendered as a solid dark olive green, and forests (landuse=forest) as a brighter light green with trees. Example: https://www.openstreetmap.org/#map=19/26.54415/-81.75739

The differences between the two are discussed here: https://help.openstreetmap.org/questions/324/when-should-we-use-landuseforest-rather-than-naturalwood. The primary conclusion being reached is that the traditional ways of choosing between the two are misleading and the tags are essentially used interchangeably. Some people use all forests, some use all woods, some use forests for managed areas and woods for unmanaged areas, and some just use them arbitrarily.

That being the case, it makes no sense to render the two differently when they essentially mean the same thing -- an area with dense trees that's not being used for agriculture. I reccomend that they be merged into a single style.

@kocio-pl
Copy link
Collaborator

kocio-pl commented Aug 5, 2015

There is an active discussion around using a random symbology for forests, which also proposes such unification.

@matkoniecz
Copy link
Contributor

See also #647 (AFAIK this idea is no longer considered as rejected).

@Gazer75
Copy link

Gazer75 commented Aug 7, 2015

Not sure I like this idea. In Norway "wood" is used for naturally grown forests, even if its been cut down at one point, and "forest" is used for plantations growing things like Christmas trees.

@matkoniecz
Copy link
Contributor

@Gazer75 It is not about difference between forest and wood. It is about difference in landuse=forest and natural=wood.

In some cases tag names are unfortunately partially or completely misleading.

@kocio-pl
Copy link
Collaborator

kocio-pl commented Aug 7, 2015

BTW: What about landcover=trees? It has 9k uses and while it has no special Wiki page at all, it's mentioned in the examples section:

Currently the landuse=forest or natural=wood are used but neither of these work well for planted and managed trees in a park for example.

@pnorman
Copy link
Collaborator

pnorman commented Aug 8, 2015

BTW: What about landcover=trees? It has 9k uses

I can't see rendering it. We already have multiple tags covering the same subject matter, and the tag has both low geographical use and is used essentially by two users - one for an import, the other is dieterdreist.

@polarbearing
Copy link
Contributor

used essentially by two users - one for an import, the other is @dieterdreist.

Hm, how do you get the stats for this? I see http://taginfo.openstreetmap.org/keys/landcover#overview with 17k, last edited by 750 different users, of which 54% is trees. I'll start using it, makes 751 ;-)

@pnorman
Copy link
Collaborator

pnorman commented Aug 8, 2015

Hm, how do you get the stats for this? I see http://taginfo.openstreetmap.org/keys/landcover#overview with 17k

that's landcover overall, see http://taginfo.openstreetmap.org/tags/landcover=trees

select count(*), (select name from users u where u.id = user_id) as user_name from ways where tags @> 'landcover=>trees'::hstore group by user_id order by count desc; is how I got the numbers. It's not perfect - it only counts the last edited by so it ends up showing a longer tail than actual users of the tag, but it's good enough for this.

@dieterdreist
Copy link

sent from a phone

Am 08.08.2015 um 05:28 schrieb Paul Norman [email protected]:

I can't see rendering it. We already have multiple tags covering the same subject matter, and the tag has both low geographical use and is used essentially by two users - one for an import, the other is dieterdreist.

to me this is a hen egg problem. People are used to tag even the smallest row of trees with landuse=forest and it renders the way they expect. Why should they add another tag that is not rendered at all?

@dieterdreist
Copy link

sent from a phone

Am 08.08.2015 um 10:47 schrieb Paul Norman [email protected]:

It's not perfect - it only counts the last edited by so it ends up showing a longer tail than actual users of the tag

that's your assumption. If thousands of different users would have added this tag and then someone performed an automated edit to these objects it would look as if only one user put this tag (just hypothetical, not stating it is like this). FWIW, those users at least didn't remove the tag

@kocio-pl
Copy link
Collaborator

kocio-pl commented Aug 8, 2015

Thanks for checking, guys! I'm not that into SQL so I couldn't check it myself. OK, so this evidence weakens this case in terms of usage practice, albeit we're not sure how much.

However I think this tag makes perfect sense nevertheless, so I will try to help it spread by creating Wiki proposition at least, so people know there is such scheme available. Imports are not that important themselves, but on the other hand it clearly shows how really useful is to have such scheme when we don't really know - and which other scheme covers this case (or those "planted and managed trees in a park"), as you claim? I'm not aware of anything like these, natural=wood and landuse=forest seem to be overloaded with clearly false meanings and I think this effect can be substantial.

@SomeoneElseOSM
Copy link
Contributor

@dieterdreist - re "landcover", if you think that the current "standard" rendering "gets it wrong" maybe try coming up with a rendering that incorporates it? I did look at landcover use with a view to incorporating it in https://github.com/SomeoneElseOSM/SomeoneElse-style but in England and Wales (which is all that I was rendering) there simply wasn't enough usage to justify trying to do something with the tag.

On the general point I agree that in most places landuse=forest and natural=wood don't have clear, different meanings, so when I added leaf_type support to https://github.com/SomeoneElseOSM/openstreetmap-carto-AJT etc. I did merge them. Maybe places people or places that have maintained a clear consistent difference (perhaps Norway?) could come up with a local rendering that does maintain that difference?

@fkv1
Copy link

fkv1 commented Aug 15, 2015

Rendering of natural=forest just changed. I suppose it was changed to the natural=wood style. I like the fact that landuse=forest and natural=wood are rendered the same, but I do not like the particular style. I prefer the former landuse=forest style, it's a more natural green, the embedded tree-habitus icons were smaller and they only appeared at zoomlevel >= 14 while the new icons already appear at zoomlevel 13. I find these icons annoying. Foliage (alias leaf_type etc.) is not interesting at all to map users, and those symbols sincerely obstruct the visibility of other map features. So please render forests as plain green areas without any habitus or foliage icons.

@jengelh
Copy link

jengelh commented Aug 16, 2015

@fkv1 Z13 is the one where highway=track, waterway=ditch and so on start getting rendered, so rendering the tree from Z13 on at least seems like a coherent decision.

@fkv1
Copy link

fkv1 commented Aug 16, 2015

@jengelh It may be coherent, but the zoomlevel where these features get visible is the one where the tree symbols are most obfuscating. I would like to see the tracks etc. at the first glance, without further zooming in or touching the monitor with my nose.

@ximex
Copy link

ximex commented Aug 16, 2015

@fkv1 is right. tracks got thicker in Z15. so maybe we should render the icons from Z15 and not Z13

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests