The following landcover types are currently not rendered:
It would be nice to have these tags rendered.
natural=wetland is rendered. See http://www.openstreetmap.org/way/276099816
Thanks, didn't realize that one was in the water file rather than the landcover file. Removed.
natural=sand is also rendered.
Here is a quick change I just did on a golf course
http://www.openstreetmap.org/#map=19/53.53682/-2.24720
Yes I noticed, I removed it already.
2014-05-20 17:21 GMT+02:00 Rovastar [email protected]:
natural=sand is also rendered.
"sand" is IMHO not a good value for natural, as it is not a geographic
feature but a surface / material. Using the landcover key (or surface in
some cases) would be better. E.g. natural=beach & landcover=sand
landuse=quarry seems to be rendered already.
I am not sure justification for natural=beach being natural but not natural =sand.
Landcover is another issue entirely. Personally I think landuse and landcover is just semantics and they should be are are used interchangeably sand, grass, etc. But this is the wrong palce for this discussion.
Do we even use landcover in cartocss?!
Add to that natural=bare_rock, see #298.
Maybe also worth rendering is natural=shoal, even if it's not used a lot yet.
It would be nice to have landuse=salt_pond because there is a salt production region near where I live. It bothers me to see big blank map as if there were nothing on OSM.
I would tag salt ponds as landuse=industrial, with industrial=salt_pond (or maybe man_made=salt_pond)? landuse=salt_pond is extremely specific (though, unfortunately it seems to be frequently used - over 4k instances on taginfo).
@mkoniecz Thanks for the suggestion.
landuse=plant_nursery is also missing, see #187.
natural=fell (or similar) is needed for medium alpine area above the tree line but not already bare_rock
Regarding natural=fell, is there anything in particular one can contribute with?
Visually speaking it's a tag that seems appropriate to render with a colour slightly grayer than grass, with perhaps a symbolic/pattern of sorts indicating the uneven-ness of the area itself?
Not at the moment, I think. We should first roll out #947, which makes all the landcover labelling consistent. After that, we will need to look at the colours of the existing landcovers, and I think only after that is done it makes sense to start thinking about the colours/rendering of new landcover.
@math1985 understandable! With that in mind, is there any particular issues except for #947 that people could help with; with regards to colours of existing landcovers, does any overview/table of the various mappings exist?
Basically, how can a CSS-experienced OSM-addict help, if possible? :+1:
Sorry, I gave the wrong issue, I meant #941 rather than #947 (although probably both should be rolled out first).
does any overview/table of the various mappings exist?
The code can be found here: https://github.com/gravitystorm/openstreetmap-carto/blob/master/landcover.mss
A picture of the current rendering: https://cloud.githubusercontent.com/assets/5251909/4258446/def475f0-3ad2-11e4-81c9-b3d7c519aac9.png
All colours with a Lch vaue commented have been reviewed recently. All others still need reviewing. Some, like desert, look particularly bad. It would be nice if we could give all or most colours the same lightness, while still being able to distinguish them.
If you're looking for a small project, you could start with the sports colours. See also #919 for that.
Another thing that needs to be done is changing the landcover images so that they are a factor of 2 wide/tall, see #937 - but see also #938.
Probably not everything is documented as clear as it could be, but if you have any questions, let us know and we will clarify.
natural=dune conflicts with more widely used natural=sand, is used on areas less than 800 times, never went through any kind of approval process. I would suggest dropping it from this list.
natural=dune conflicts with more widely used natural=sand
And with natural=scrub, depending on the type of dunes. See here.
The problem is that natural formations are mixed with the substances in the tags. Beach can be sandy or stony, dune can be sand or nicely grown over with dune grass.
2015-01-11 1:01 GMT+01:00 polarbearing [email protected]:
The problem is that natural formations are mixed with the substances in
the tags. Beach can be sandy or stony, dune can be sand or nicely grown
over with dune grass.
+1, this is clearly a tagging problem. natural=sand/mud/bare_rock are "bad"
because they are describing properties of an object rather than a class of
object, thereby creating tagging conflicts/incompatibilities. They should
go under another key where they would fit, e.g. "surface" or "landcover".
Unfortunately these tags are rendered currently and there are presets for
them, so that mappers are encouraged to continue using them.
What's up with natural=fell now? If you can't decide how to render it, you may treat it as a synonym for natural=grassland or landuse=meadow. That's better than leaving the areas white.
The problem of natural=fell is that it is somewhat poorly defined in the wiki and accordingly used for a wide variety of purposes. Areas tagged natural=fell often consist at least in parts of the following:
As @dieterdreist explained this is partly due to the mixture of tags for landcovers and landforms we have in OSM. For rendering in the map with a color fill/pattern landcover tags describing the local observable properties of the land surface are better suited than landform tags where definition arises from the context and the boundaries are often blurry - in this case fell in a strict sense refers to the upper lying parts of a hill landscape near the tree line. Practical use of the tag is however much more vague and inconsistent.
natural=tundra has probably been set up to overcome this problem since it does not have the landform component but is purely ecologically defined. It is however also very broad and equally overlaps all of the above tags to some extent.
The most prominent use of natural=fell is probably for alpine tundra where coloring it like natural=grassland might seem appropriate. Due to the broad definition of natural=fell mapping however often is also extremely broad which makes it not so suited for rendering in grassland green like here:
http://www.openstreetmap.org/relation/1354524
http://www.openstreetmap.org/way/197815853
http://www.openstreetmap.org/way/27869519
http://www.openstreetmap.org/way/61374902
These comply with the wiki definition of natural=fell (except the last maybe) but IMO are too diverse to be rendered in grassland color.
From the mapping side i think it would be a better approach to tag alpine vegetation above the treeline as natural=grassland/landuse=meadow/natural=heath with a supplementary tag (alpine=yes or similar)
On 03.05.2015 15:13, imagico wrote:
The problem of natural=fell is that it is somewhat poorly defined in the
wiki and accordingly used for a wide variety of purposes.
It has been part of map features for ages, and I think that the definition
is quite clear. If you find it unclear, discuss it in the wiki or in the
tagging mailing list.
Areas tagged
natural=fell often consist at least in parts of the following:
- natural=grassland
- landuse=meadow, meadow=agricultural (i.e. pasture)
- natural=heath
There may be some overlap with the above, but look, all of them are green.
- natural=wetland + wetland=bog
- natural=bare_rock
- natural=scree
These differ from natural=fell by definition.
- geological=moraine
This is independent from natural=fell, as a moraine may be covered by forest
or a meadow or whatever. And it seems that most geological=moraine were
created by an import. The tag was never proposed.
As @dieterdreist https://github.com/dieterdreist explained this is partly
due to the mixture of tags for landcovers and landforms we have in OSM.
natural=fell is basically a vegetation related tag. That's why it is in the
"vegetation related" section of the natural=* wiki page. That's how it is,
even though some people such as Dieterdreist don't like it.
There's no point in putting approved and widely used tags in question here.
natural=fell is used 9461 times, it is approved, and it has its wiki page,
thus it should be rendered. You may render it using a pattern of red hearts
and purple stars, although a light green or gray tone might be more intuitive.
The most prominent use of natural=fell is probably for alpine tundra where
coloring it like natural=grassland might seem appropriate. Due to the broad
definition of natural=fell mapping however often is also extremely broad
which makes it not so suited for rendering in grassland green like here:http://www.openstreetmap.org/relation/1354524
http://www.openstreetmap.org/way/197815853
http://www.openstreetmap.org/way/27869519
http://www.openstreetmap.org/way/61374902These comply with the wiki definition of natural=fell (except the last
maybe) but IMO are too diverse to be rendered in grassland color.
Some detailed mapping (splitting the areas up in fell/bare_rock/etc.) is to
be done in these examples. So far nobody cared, because natural=fell is
"rendered" white, and white looks like rock and glacier.
I've seen lots of areas which should be natural=fell but are actually tagged
landuse=grass just to make them look green.
This is a chicken-egg problem. You will not get people to use the proper
tags as long as you don't render them properly.
it is approved, and it has its wiki page, thus it should be rendered
This is absolutely _not_ how we decide what things to render.
Do you throw a dice?
@fkv1 I strongly suggest to avoid unhelpful trolling.
I would tag salt ponds as landuse=industrial, with industrial=salt_pond (or maybe man_made=salt_pond)? landuse=salt_pond is extremely specific (though, unfortunately it seems to be frequently used - over 4k instances on taginfo).
see http://wiki.openstreetmap.org/wiki/Proposed_features/industrial for documentation of this tagging scheme
So will you wait with rendering something until your preferred way of tagging is approved? Why not rendering it right away and then switch the tags when a new method is approved? E.g. salt_pond can even be mass-edited in the database to the new tagging.
So will you wait with rendering something until your preferred way of tagging is approved?
It depends on situation. For example in case of landuse=greenhouse_horticulture it was clear that usage is widespread and it is commonly accepted, so I merged #1435 despite my opinion that it is a bad tagging scheme.
salt_pond can even be mass-edited in the database to the new tagging
It can be done only establishing wide consensus that it is a good idea (and it should not be done here).
The good thing about landuse=salt_pond is that it is intuitively clear it is meant to be use for the salt pond itself and not the whole area while landuse=industrial tends to be applied to the whole area including dams, storage areas etc.
There is also wetland=saltern by the way with 1300 uses which is also not a really good choice of tagging. In other cases salt ponds are also tagged as water (like here). An attractive and clear rendering of landuse=salt_pond that clearly indicates a pond and not just an industrial area would help avoiding such taggings.
Should this issue maybe split into several issues? For example natural=reef is rendered in osmand already and the solution there looks well to me. So this should be easy to implement? Also it does not collide with the issues raised in #1547
Hi, can rendering natural=fell be implemented? It is already used 10000 times. I would propose a color less green than a grassland, something more in the direction to the brownish natural=heath. Currently it is shown as pure white which looks like untagged areas.
You can see e.g. at http://www.openstreetmap.org/#map=14/49.1547/20.0369 where the vegetation levels should be properly mapped according to the altitute and shape of the peaks/aretes (forest->scrub->fell->scree->bare_rock). Only fell rendeding is missing there.
Thanks.
Please read what i wrote above in https://github.com/gravitystorm/openstreetmap-carto/issues/545#issuecomment-98479426 - natural=fell is a fairly ill-defined tag based on a term (fell) with a specific regional meaning describing a certain landform (the upper parts of a hill/mountain landscape near the tree line in mostly oceanic/subarctic climate in northern Europe). In other parts of the world it is used with a very broad meaning with no universally defining local properties except the lack of trees.
Therefore we should not render it here implying to the mapper that this is something specific, locally verifiable.
I know it can be difficult to make the distinction in mountain areas between scree/bare_rock, grassland and heath and it can be appealing to have an umbrella tag for any treeless area with at least some amount of vegetation. My advise here: just take a pick, look at the area and decide which is the most dominating element (bedrock, loose rock, herbaceous plants or woody plants). If other mappers disagree they can change it or split the area and change parts of it and thereby improve mapping.
To all: i updated above issue striking out things already implemented. I would suggest to further remove landuse=harbour due to low use and two competing taggings (landuse=port and industrial=port) with similar volume of use and natural=fell due to the above. This leaves natural=dune and landuse=salt_pond - for which it might be a better idea to open specific issues. natural=dune IMO mostly is a matter of finding a good way to render it.
If you read the OSM wiki page about fell, nowhere there is such warning and the status of the tag is "Approved", it should be rendered as should be "natural=tundra" and let the mapper decide between the two, perhaps some remapping should occur in some part of the world.
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dfell
Please read the previous discussion above, the wiki does not dictate our decisions here. We take into account the documentation of the meaning of the tag on the wiki but it does not matter if someone writes there a tag should be rendered in this way or someone indicated it to be 'Approved'.
Maybe, but when a tag is documented on the Wiki with a 'Approved' status, all major OSM editors (iD, JOSM,...) have a preset for it and it is used about 10000 times around the world then just saying everyone else is wrong, IMHO, is not the good answer...
Well - in OSM there is no central authority deciding what is to be done and what not. Everyone - mappers, style developers and editor developers - can decide on their own what to do and this also means everyone is responsible for their decisions. We try to take our responsibility here seriously by not relying on some perceived authority (like the wiki or editor presets) when making them. This does not mean others are wrong when they come to a different conclusion, we just have different perspectives and priorities.
IMHO resigning entirely from rendering accepted and widely used tag seems as bad idea which makes one ask why it was approved as the proper tag and added to list of tags that are in need of rendering in the first place if it is so bad?
I think more appropriate solution should be adding conditional rendering to the tag instead of resigning from using it. Just like here https://github.com/gravitystorm/openstreetmap-carto/issues/2556#issuecomment-278262720 I prepared code based on the situation same may be done for natural=fell.
As a mapper, I would like to see the fell and/or tundra rendered too.
As a mapper, I would like to see the fell and/or tundra rendered too.
How should they be rendered then?
@wmyrda said
IMHO resigning entirely from rendering accepted and widely used tag seems as bad idea which makes one ask why it was approved as the proper tag and added to list of tags that are in need of rendering in the first place if it is so bad?
Something being widely used, accepted, and having gone through the wiki process to display approved doesn't mean we want to render it. The tags listed in this issue were raised as issues with the old osm.xml styles in Trac and something we can consider rendering, not something we've decided to, or that we need to.
How should they be rendered then?
THAT is the ÂŁ64,000 question, isn't it?
I've had some ideas about rendering natural=fell the same as natural=heath and then changing the latter to use a grass or scrub pattern. But i'm still a total noob on Docker, so it's taking me some time to get the hang of it :(
THAT is the ÂŁ64,000 question, isn't it?
I answer such questions here almost on a daily basis, so where can I get the cash? :smile:
But seriously - do you need some help with Docker? Maybe this documentation would be more in depth than what we have in this repo
Something being widely used, accepted, and having gone through the wiki process to display approved doesn't mean we want to render it. The tags listed in this issue were raised as issues with the old osm.xml styles in Trac and something we can consider rendering, not something we've decided to, or that we need to.
This is kind of answer that lead people tagging for the rendering and not for what is on ground...
To add to what @imagico said above, natural=fell does get used for all sorts of things. In the UK it's used for "generic upland landuse", and also (on nodes) instead of natural=peak, and also for paths (often indeterminate) up hills. I'm not defending any of that; just mentioning it since people are talking above about testing a rendering out (and talking about this issue elsewhere) and if they aren't careful what to exclude they might get some surprises!
On the other hand - that might be what would help to see the problem and fix it. You never know.
It's interesting for me to find a source of this problem. It's definitely not tagging for rendering. Maybe it's just lack of proper tagging and it should be created? Maybe it's a real world problem with deciding what it is, or maybe definition is too broad or not precise enough (like with landuse=farm)?
Possible rendering for natural=fell (vegetation/grass islands):

Given very low usage of landuse=harbour (less than 1000 worldwide) I would be strongly against rendering it. This style should show clearly established tags, rather than promote new ones.
https://taginfo.openstreetmap.org/tags/landuse=harbour
Given that https://trac.openstreetmap.org/ticket/3612 proposed rendering 7 years ago and harbour is not unusual or niche feature I would not consider this tag as candidate for rendering.
given problems described in https://github.com/gravitystorm/openstreetmap-carto/issues/545#issuecomment-98479426 and documented on wiki at https://wiki.openstreetmap.org/wiki/Tag:natural%3Dfell
Actual use of the tag for areas as of October 2017 includes different kinds of treeless areas, in particular areas vegetated primarily by grasses (Poaceae) which are commonly tagged as natural=grassland or landuse=meadow, areas mostly vegetated by dwarf scrubs which are more commonly tagged natural=heath, rain fed peat producing wetlands for which the established tagging is natural=wetland + wetland=bog and areas with very little or no vegetation which in most cases qualify as natural=scree or natural=bare_rock. When mapping preferably choose the tag that best and most precisely describes the specific setting you are looking at. Data users should not expect a particular type of surface or vegetation for areas tagged natural=fell.
I share @imagico opinion and propose to not render natural=fell.
Iff there is something not covered natural=grassland, landuse=meadow, natural=heath, natural=wetland, natural=scree or natural=bare_rock then new specific and clear tag should be introduced rather than rendering poorly defined natural=fell.
I marked natural=fell and landuse=harbor as rejected in the https://github.com/gravitystorm/openstreetmap-carto/issues/545#issue-33896407
natural=dune, see also https://trac.openstreetmap.org/ticket/3815
Can somebody give an example of OSM element where rendering this object makes sense? Given that it may be sand or not, covered by vegetation or not rendering landcover makes no sense.
In addition usage ( https://taginfo.openstreetmap.org/tags/natural=dune ) is really low.
The only part that makes sense for me is rendering name - but given low usage I would not do even that.
http://overpass-turbo.eu/s/sLn - 148 natural=dune worldwide have name tag, most of names are rendered anyway thanks to other rendered tags.
natural=fell rejected in #545 (comment)
I marked natural=fell and landuse=harbor as rejected in the #545 (comment)
why ???????
https://taginfo.openstreetmap.org/tags/natural=fell ---> 13 798 uses
why ???????
see https://github.com/gravitystorm/openstreetmap-carto/issues/545#issuecomment-98479426 https://github.com/gravitystorm/openstreetmap-carto/issues/545#issuecomment-341895192 https://github.com/gravitystorm/openstreetmap-carto/issues/545#issuecomment-277207366 and https://github.com/gravitystorm/openstreetmap-carto/issues/545#issuecomment-341894371 linked from https://github.com/gravitystorm/openstreetmap-carto/issues/545#issue-33896407 (and text that you initially quoted)
https://taginfo.openstreetmap.org/tags/natural=fell ---> 13 798 uses
usage is required for rendering, but not sufficient. Just because something is widely used does not mean that it should or will be rendered.
natural=dune, see also https://trac.openstreetmap.org/ticket/3815
Can somebody give an example of OSM element where rendering this object makes sense?
Rendering dunes is not uncommon in maps. Two examples:
https://geogreif.uni-greifswald.de/geogreif/geogreif-content/upload/alg200/NR105Ouargla1932.jpg
https://geogreif.uni-greifswald.de/geogreif/geogreif-content/upload/sahara/Hassi%20Bourarhet.jpg
If what is currently mapped as natural=dune is suitable for creating such a depiction is a completely different matter though. A few examples where this might be possible:
https://www.openstreetmap.org/way/439124398
https://www.openstreetmap.org/way/403607112
https://www.openstreetmap.org/way/374415265
sent from a phone
On 4. Nov 2017, at 14:13, Mateusz Konieczny notifications@github.com wrote:
Can somebody give an example of OSM element where rendering this object makes sense? Given that it may be sand or not, covered by vegetation or not rendering landcover makes no sense.
a famous dune that comes to mind:
https://en.wikipedia.org/wiki/Dune_of_Pilat
http://www.openstreetmap.org/relation/2244861#map=13/44.5893/-1.2146
and also this (probably came to existence because of missing rendering):
http://www.openstreetmap.org/node/1287572058#map=15/44.5895/-1.2135
Just an idea with the natural=fell issue:
Could natural=heath by subdivided like wetlands to have different types of heath such as _coastal_, _moorland_, _alpine_, etc?
Could natural=heath by subdivided like wetlands to have different types of heath such as coastal, moorland, alpine, etc?
Is it an idea for a new tag? Then it should be discussed on tagging mailing list/OSM wiki, not here.
Before I get there, i'd be interested to see if it is: a) technically feasible; and b) a desirable solution to the above issue
Please rendernatural=dune in the same way as natural=beach is been rendering.
@geozeisig I think natural=sand pattern would be more appropriate.
Notice that dunes are frequently located next to a beach in Europe (e.g. Spain, France, Belgium, Netherland, Germany and UK)
See for example this overpass request
@jragusa They may be located next to beach, but at least in Poland are protected and unlike on the beach you may not freely walk around it therefore differentiating them from beaches seems reasonable to me.
I thought about this pattern for landuse=salt_pond
https://www.openstreetmap.org/#map=16/43.0338/3.0202

what do you think ?
I like the way it looks, but have no clear idea if it is good in this case.
It's good to remember that this is about industrial area for producing salt from the salt water. Natural area is rendered in a different way:
https://wiki.openstreetmap.org/wiki/Tag:wetland%3Dsaltmarsh
Working salt ponds will sometimes be filled with water and sometime dry.
The operator fills a pond with seawater and then lets the water evaporate.
After it is completely dry, the salt is scraped off of the bottom, and then
the pond is refilled.
So it’s a saltwater feature, then a wet mud flat, the a dry salt flat, and
then similar to an open salt quarry.
I’d suggest an intermittent (salt-)water pattern over quarry pattern on a
functional basis, but it would look strange with the current quarry and
intermittent water patterns.
I don’t know if there is a current rendering for dry salt flats?
Blue water-color dots over light brown “mud” color might work.
If we had a good “salt flat” rendering, that could be the base color.
Perhaps an off-white granular pattern?
On Wed, Nov 7, 2018 at 7:25 AM kocio-pl notifications@github.com wrote:
I like the way it looks, but have no clear idea if it is good in this case.
It's good to remember that this is about industrial area for producing
salt from the salt water. Natural area is rendered in a different way:https://wiki.openstreetmap.org/wiki/Tag:wetland%3Dsaltmarsh
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/gravitystorm/openstreetmap-carto/issues/545#issuecomment-436431505,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AoxshGAjzJcAV_F92_9mm4FlKAWgwuYJks5usgxGgaJpZM4B8j68
.
I like the idea of some white pattern, but I would like to see irregular small dots pattern to compare.
I will try a small dots pattern but I'm not convinced by the quarry, it's not intuitive.
there is two possibilities:
1/ considering the same behaviour than forest/wood and make no distinction between human managed and natural salt pond. Moreover some natural salt ponds/lakes are partially exploited by people (example: Salar de Uyuni)
2/ use the above mentioned pattern for natural one (natural=wetland + wetland=saltern) to remain consistent with other wetlands and use a triangle pattern for human managed in relation to their extraction (example)
I think it would be worth rendering human managed/exploited ones differently. Maybe in a similar way to a quarry. Since they are kind of the same thing, just a different resource.
@Tomasz-W, can you go through this and turn what still needs to be done into a checklist. Then maybe create a sub checklist in your meta ticket with and what is left of the other issues dealing with "natural" stuff like valley, ridge etc?
Thanks
@Adamant36 Remaining elements + my propositions:
landuse=salt_pond -> https://github.com/gravitystorm/openstreetmap-carto/issues/545#issuecomment-436427703 + https://github.com/gravitystorm/openstreetmap-carto/issues/545#issuecomment-436519696natural=dune -> natural=sand reusenatural=fell -> landuse=grass reuseWasn't rendering natural=fell already rejected previously
https://github.com/gravitystorm/openstreetmap-carto/issues/545#issue-33896407) in this thread (https://github.com/gravitystorm/openstreetmap-carto/issues/545#issuecomment-341897289) and in #2923 and #3165?
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dfell
"Actual use of the tag for areas as of October 2017 includes different kinds of treeless areas, in particular areas vegetated primarily by grasses (Poaceae) which are commonly tagged as natural=grassland or landuse=meadow, areas mostly vegetated by dwarf scrubs which are more commonly tagged natural=heath, rain fed peat producing wetlands for which the established tagging is natural=wetland + wetland=bog and areas with very little or no vegetation which in most cases qualify as natural=scree or natural=bare_rock. When mapping preferably choose the tag that best and most precisely describes the specific setting you are looking at. Data users should not expect a particular type of surface or vegetation for areas tagged natural=fell."
@Adamant36 they don't use hammer in a salt_pond
@Tomasz-W I can try with the dot pattern of garden
@jragusa But it should be some irregular dots pattern, and a garden one is regular.
Re: natural=dune - if we remove the beach pattern rendering from natural=sand, it would be possible to use a pattern to distinguish these. Most are covered by sand, but some will have areas of grass, and they can overlap with non-dune areas of natural=sand, so it might make sense to show a pattern, and base the fill color off of surface=sand/grass or the presence of natural=sand overlapping.
Australian topo maps:


Old map (1919) dune patterns:


This is from USGS topo maps in 1955: https://pubs.usgs.gov/circ/1955/0368/report.pdf
"Area patterns. --Intricate surface areas too irregular to contour except in a very generalized manner, such as lava beds, sand dunes, and open strip mines, are shown by a variety of symbol patterns. The patterns are made up of dots, hachures, or form lines that indicate the typical appearance of the area. Where symbol patterns are used, no attempt is made to represent the topography in detail." - unfortunately they did not provide an example.
Sand/Scree pattern from OsmAnd:
Standard resolution:

Full resolution (phone screen):

sent from a phone
On 29. Aug 2019, at 06:16, jeisenbe notifications@github.com wrote:
Old map (1919) dune patterns:
this shows nicely a possible distinction between different types of dunes / dune orientation.
Unfortunately at the moment it is not visible that natural=dune is consistently used by mappers in a way that is actually helpful for rendering. There is some use of natural=dune as a landform tag for individual dunes but most of the use on polygons is essentially as an aggregate landcover tag combining wind formed natural=sand and vegetated areas without intensive human use with wind formed sandy ground beneath. As long as this is the case i see very little possibility to render natural=dune in a way that would provide constructive mapper feedback.
Note most rendering concepts for dunes in traditional maps are based on more in depth knowledge about the dunes (shape, direction) which is not currently mapped in OSM.
Re: natural=dune - if we remove the beach pattern rendering from natural=sand, it would be possible to use a pattern to distinguish these. Most are covered by sand, but some will have areas of grass, and they can overlap with non-dune areas of natural=sand, so it might make sense to show a pattern, and base the fill color off of surface=sand/grass or the presence of natural=sand overlapping.
I'm not sure if I understand you here, this sentence is too complex for me, but I believe current system is more logical. We have:
If we show a pattern for sandy beach, but remove it from sand areas, we would loose this coherence (we show that sandy beach is similar to sand area in some way, and sandy beach is similar to general beach in another way).
I also feel that a sand overlay is too light and would like to make dots more visible.
landuse=salt_pond could be rendered. This appears to be used consistently.
Re: natural=dune - checking taghistory, very few features have been added since 2011. Most of the existing 843 ways were added around then (there were only a dozen in late 2010, then briefly over 3000 in early 2011, dropping back to 600 in mid-2011).
As mentioned above (https://github.com/gravitystorm/openstreetmap-carto/issues/545#issuecomment-526086758), this tag has not been used very consistenly on areas, unfortunately. I checked several regions, and most of the areas with this tag are roughtly drawn, or might better be tagged natural=sand.
So for now, I'm editing the title to remove natural=dune. If this tag starts being used more commonly and consistenly in the future, a new issue can be opened about it specifically.
Most helpful comment
Hi, can rendering natural=fell be implemented? It is already used 10000 times. I would propose a color less green than a grassland, something more in the direction to the brownish natural=heath. Currently it is shown as pure white which looks like untagged areas.
You can see e.g. at http://www.openstreetmap.org/#map=14/49.1547/20.0369 where the vegetation levels should be properly mapped according to the altitute and shape of the peaks/aretes (forest->scrub->fell->scree->bare_rock). Only fell rendeding is missing there.
Thanks.