rendering of bare ground land covers

[imagico]

This change adds support for rendering natural=bare_rock and natural=scree and thereby resolves #298 and partly addresses #545.

Rationale: bare_rock and scree are currently the most widely used values (65k and 24k uses) for the natural key that are not rendered in the standard style and also generally among the most widely used area tags that are not rendered. Together with sand and undifferentiated loose material (for which no tagging has been established yet) they represent the primary types of natural landcovers in areas with no or very sparse natural vegetation like deserts, polar regions and high mountain areas.

The way this change renders these is somewhat different from the usual landcover rendering and likely not everyone will like it so i am going to explain my reasoning behind it:

• Use of plain colors for differentiating landcovers has reached the end of the line in this style - colors are already difficult to distinguish with existing landcover types and adding even more colors will just emphasize this problem.
• Therefore i decided to use the same color for all bare ground landcovers (bare_rock, scree and existing sand) and only differentiate between them at higher zooms by use of patterns.
• I tried to create intuitively understandable patterns, this is difficult with low resolution rendering like here, esp. for bare_rock.
• Colors chosen are fairly bright to avoid disturbing features drawn over them too much which seems important since esp. bare_rock and sand can cover large areas.
• The plain color rendering in the same color for all three starts at z=9, one zoom level after wood/forest but one before most other landcovers. This factors in that these tend to cover large areas and since the color is not too much different from the map background this should not be too disturbing with smaller areas either.
• The pattern rendering starts at z=13, one zoom level before the forest/scrub but the pattern structure works quite well even on small areas and the pattern is the only thing differentiating between bare_rock/scree/sand.
• The previously used strong yellow color for sand is eliminated by this - IMO this is a good thing but some might prefer the yellow for smaller uses of natural=sand. The most widespread is probably golf courses (36k out of 56k uses in total) but these should better be rendered based on golf tags anyway - which of course requires an osm2pgsql style change.
• In the code you can see that i included natural=shingle to be rendered like natural=scree to avoid mappers feeling additionally inclined to tag natural=scree despite this being technically wrong. Practically natural=scree is currently used for all kinds of medium sized loose material.

Rendering examples (from Alps and Sinai):

As said this is somewhat unusual design wise and fairly unexplored territory so i welcome suggestions how to improve it, esp. regarding the choice of colors.

And I will prophylactically address the remark from @dieterdreist that 'natural' is a suboptimal choice of key here ;-):

• these tags are well established and not easy to change
• bare_rock is actually not really a landcover but a lack of landcover
• scree is - when interpreted strictly - not a landcover either since it refers to a distinct geographical feature (German: Schuttkegel). Actual use is of course often much broader.

[matkoniecz]

Name display is currently missing for this features.

[imagico]

Yes, added that, examples:

[matkoniecz]

@sand: #ffdf88;

Is it now used somewhere? It seems that it can be removed.

[imagico]

Right - removing.

[matthijsmelissen]

Sand and bare rock are quite different, I would prefer to keep the difference.

I agree a rendering for bare_rock and scree are badly needed.

[matkoniecz]

I am not sure - on one hand there is a difference, on the other compared to other features difference is not so big.

Also, current yellow color is encouraging tagging for renderer - in golf courses, in sandpits etc.

BTW, it would be a good idea to improve https://wiki.openstreetmap.org/wiki/Tag%3Anatural%3Dsand - currently it is rather poor.

[imagico]

I outlined my reasoning for this approach to rendering - but if there are alternatives i would be eager to hear. If you have three colors that are

• more or less intuitively understandable
• can be well differentiated from other area colors (in particular urban landuses, beach, farmland, quarry)
• are suitable for larger areas where other things are drawn on top, esp. for bare_rock and sand

it would certainly be good to consider them as alternatives.

[matkoniecz]

I am happy about this PR, in my testing I see nothing wrong and plenty of improvements - but I admit that there is almost no valid use of natural=sand where I did tests.

It works also for smaller rock formations.

alternatives

Maybe add new ones, as in this PR and keep sand rendering unchanged? Or make sand background mix of proposed one and old yellow?

[imagico]

Maybe add new ones, as in this PR and keep sand unchanged as an alternative?

That would be possible of course but the combination with the strong yellow looks kind of ugly to me.

Generally i also would like to see these differentiated even at low zooms. A possible approach would be not to differentiate urban landuses up to z=12. This would avoid ambiguities at the low zooms. And if from z=13 on a pattern is used for the bare ground landcovers in addition to the color distinguishing them from each other and from urban landuse is easier. But it would also mean less continuity in styling across different scales.

I am happy about this PR, in my testing I see nothing wrong and plenty of improvements - but I admit that there is almost no valid use of natural=sand where I did tests.

You can find quite reasonable larger scale sand mapping around:

http://www.openstreetmap.org/#map=10/29.8025/29.0733

The combination of all three is best observable in the eastern Sinai i think although use of scree there is somewhat questionable.

[matkoniecz]

You can find quite reasonable larger scale sand mapping around:

For places that I never visited it is quite hard to decide whatever map is a good representation of reality. For example I have no good idea how important is the difference between sand and bare_rock in the Sinai, and I can only extrapolate from my experience.

That would be possible of course but the combination with the strong yellow looks kind of ugly to me.

Maybe make background for sand yellowish - mix of brown proposed here and beach background? Maybe it would be both more recognizable as sand and not so strong?

[matthijsmelissen]

For example I have no good idea how important is the difference between sand and bare_rock in the Sinai, and I can only extrapolate from my experience.

I have been in Morocco, and I think the difference can be quite significant (and abrupt). See for example this satellite imagery. Although the area on the left is perhaps rather scrub than bare rock.

[imagico]

OK, tried a yellow, fitted more or less between beach, this one, parking and school and it seems to work quite well - not using a pattern for sand also allows using the finer one for scree and thereby improving contrast between rock and scree:

@math1985 - Sand color varies a lot, primarily depending on iron content of the sand - between strong red (as common in Australia) and gray-white (like in some areas in the southwestern US)

[matthijsmelissen]

Sand looks fine to me now. I also wouldn't be opposed to rendering sand and beach equal, by the way.

I am not sure yet about the bare rock rendering - because of the irregularity, it might look like there is more data in it that we have, and people might confuse the pattern with contour lines or cliffs for example. I'm not sure what others think?

[matkoniecz]

@imagico Can you publish commit changing sand to yellow? Currently it is not pushed.

[matkoniecz]

@math1985 I would expect that making it closer to other fills would result in drastically more significant confusion. Also, such style is used for rocks on many maps, I would say that it is not too unusual.

[matthijsmelissen]

@mkoniecz This is still bare rock, right? I wouldn't expect something like this given the heavy texture.

[matkoniecz]

@math1985 Probably it depends on context - in places where such landcover is common it would not be marked with heavy texture (Iceland?). But for example in Poland it would be highly unusual and marked with strong symbol.

Making it less aggressive would make it less fitting for other formations where bare_rock is also a valid tag, like steep rocky slopes of mountains.

[matthijsmelissen]

Ok, makes sense.

[imagico]

Change to yellow is pushed now.

Regarding rock pattern - implying additional information is a general risk for random patterns. In case of rock this is a particular problem since patterns actually containing additional details are widely used in maps for this purpose as well. But i think for a zoomable map this is much less an issue than for a printed map since the viewer can easily see this is a generic pattern since it does not scale when zooming in.

Generally i think using a pattern for rock is much more intuitive than a plain color since in most cases natural rock areas have a strong macrostructure. There are exceptions of course but these are rare. What makes us recognize bare rock areas as such is often this macrostructure - and if it is missing we tend to have doubts if this is actually bare rock (like in your example).

[matkoniecz]

@imagico

@bare: #eee5dc; // bare ground landcovers

I think it would be better to have variable @bare_ground_landcovers or @rocky_ground or something else that would eliminate need for a comment.

Also, is it tested with many very small areas (test for polygon-pattern-gamma and polygon-gamma)?

BTW, this PR partly addresses #1029 (currently tourism=attraction labels are not displayed for natural=bare_rock elements).

[daganzdaanda]

Good to see scree and bare rock rendered!
I really like the concept of showing a flat colour at greater distance and then a pattern when closer. We don't have to show all the complexity at once, and I think we don't have to keep all things looking the same at every zoom level.

Also, sand looks better in your light yellow. It will be fine in Golf courses as well ;-)

[imagico]

Changed color name to bare_ground

I have not tested very much - the gamma values are just what is also used elsewhere. I do not expect this to be an issue though since gamma is mostly a problem with high contrast colors.

Here are two more samples from France (combination with forest, wood, larger rivers and beach) and Colombia (combination with glaciers)

[mboeringa]

In the code you can see that i included natural=shingle to be rendered like natural=scree to avoid mappers feeling additionally inclined to tag natural=scree despite this being technically wrong. Practically natural=scree is currently used for all kinds of medium sized loose material.

natural=shingle needs to be documented on the main natural=x page, and the page you pointed out (https://wiki.openstreetmap.org/wiki/Tag%3Anatural%3Dshingle) should be linked from there if we think this is a valid tag. Probably best under "Vegetation or surface related", like natural=scree:

https://wiki.openstreetmap.org/wiki/Key:natural

I have no experience with editing the Wiki, and the one time I tried, I couldn't figure it out right away, is there someone else who could do this?

I am not sure yet about the bare rock rendering - because of the irregularity, it might look like there is more data in it that we have, and people might confuse the pattern with contour lines or cliffs for example. I'm not sure what others think?

@imagico, can you try to lighten up the bare_rock pattern? I think there is room for improvement by simply lightening it up, without change to the pattern. I think this will remove the drawback of the pattern itself becoming "data"...

I also think dropping the coarser point pattern - as you already did - and only use the finer one, is an improvement. The coarse one had to big points.

[mboeringa]

By the way, I have seen some very large areas tagged with natural=rock, instead of natural=bare_rock. I would suggest treating them the same, and apply the same pattern, or at least a very similar pattern.

Not rendering natural=rock will still miss some big areas of rocky surface...

[matkoniecz]

By the way, I have seen some very large areas tagged with natural=rock, instead of natural=bare_rock.

See #34 and taginfo - natural=rock is used rather on nodes and is defined as "A notable rock or group of rocks, with at least one of them firmly attached to the underlying bedrock." ( http://taginfo.openstreetmap.org/tags/natural=rock ).

Therefore using it for large areas is most likely a tagging error.

[imagico]

I don't think making the rock pattern lighter would be a good idea - this would reduce contrast with scree. I tried making the pattern less structured, more uniform - see here:

This also makes it less rock-like IMO but smaller forms are probably better identifiable. If this is generally considered better i can switch it.

[mboeringa]

I don't think making the rock pattern lighter would be a good idea - this would reduce contrast with scree. I tried making the pattern less structured, more uniform - see here:

I still would be interested to see a lighter version of this pattern for comparison... next to scree of course. I think the current difference with scree is big enough to warrant a try of a lighter version. The patterns won't be easily confused, the're to distinct.

[imagico]

I still would be interested to see a lighter version of this pattern for comparison...

Here you go - but as expected it does not look good (at least IMO)

[mboeringa]

Here you go - but as expected it does not look good (at least IMO)

What if you change it to be the same hue as the background, just darker (the lightness of the last image for comparison)? It appears the pattern has a different, colder greyish hue, instead of mirroring the warm background. This makes it harder for the pattern to "blend in" naturally, and look acceptable.

[imagico]

This is intentional, with the pattern in the same tone as the base color the whole thing will be too similar to the farmland color i think. But feel free to experiment with it - should be easy since the pattern is only in the alpha channel and the image is otherwise plain color.

[mboeringa]

This is intentional, with the pattern in the same tone as the base color the whole thing will be too similar to the farmland color i think. But feel free to experiment with it - should be easy since the pattern is only in the alpha channel and the image is otherwise plain color.

It is probably not exactly what you meant, but what I did was downloading the image, opening it in Photoshop and selecting a suitable color range that more or less selected the pattern only, and subsequently adjusted the hue of the selection only to a slightly warmer hue. That probably isn't exactly the same, but I guess it is close. It gives this image, which I think may be a minor improvement over the colder pattern hue, but I leave it to others to comment.

By the way, I hope we are all seeing about the same image. I set colorspace to sRGB in Photoshop for this saved image, but a non-color aware browser, may actually cause a pretty stark distortion of the colors... In my browser (Firefox), the image @imagico created and the one I created are pretty much the same, just the changed rock pattern shows a small change in color:

[matthijsmelissen]

Check if your browser is color-managed here. The car in the big image on top should be yellow, not purple.

[imagico]

@mboeringa - what i meant is that when you do a channel separation on rock_overlay.png you will get uniform color on r, g and b channels and you can adjust that without worrying about the actual pattern. It is possible that the color space information in the file is not quite correct - mapnik does not seem to care so it does not really matter.

For explanation: what i did was

convert -depth 8 -size 256x256 xc:"#9F9B96" \( rock5a.png -negate \) -set colorspace RGB -alpha Off -compose CopyOpacity -composite rock_overlay4.png

and i probably should add a -set colorspace sRGB at the end.

[mboeringa]

Check if your browser is color-managed here. The car in the big image on top should be yellow, not purple.

Mine is... nice link by the way.

[matkoniecz]

@mboeringa - I prefer version from PR, https://cloud.githubusercontent.com/assets/7635726/5696349/6aeb69b6-99cd-11e4-8ed7-14e2f2682dc7.jpg is too reddish.

[mboeringa]

@mboeringa - I prefer version from PR, https://cloud.githubusercontent.com/assets/7635726/5696349/6aeb69b6-99cd-11e4-8ed7-14e2f2682dc7.jpg is too reddish.

That's fine, what is your opinion though on the case of the higher contrast original pattern, or the lower contrast version @imagico created and I adapted? Personally, I think the higher contrast version of the PR, starts to be a bit to dominant when applied to large continuous surfaces, as in some of the images @imagico posted. A lighter version with less contrast eases this problem to my feeling.

[matkoniecz]

@mboeringa - in terms of contrast there is no noticeable difference for me in these two versions.

@imagico - thanks, great PR. I am planning on merging it in a few days. But it would be good to merge commits into one, to keep history clean.

[mboeringa]

@mboeringa - in terms of contrast there is no noticeable difference for me in these two versions.

@mkoniecz, I wasn't refering to the contrast between my adjusted image, and @imagico's low contrast version, because those have the same contrast, as I just changed hue somewhat. I was referring to this:

which is the difference between the original PR (left), and the image @imagico created upon a request by me to try a lower contrast, lightened version (right).

Do you prefer the original one (remember @math1985 raised some concern about the pattern itself becoming "data")? The comparison is a bit difficult on these small patches, as the low contrast version may seem to light in these small patches, but it is pulled from one of the last images @imagico posted, and you can see it still works out quite nicely there. Better to also view the original larger image @imagico posted for more context.

[matkoniecz]

@mboeringa Hm. It seems that version on the right would reduce/eliminate problem of "what is data", maybe without any negative effects. It would be a good idea to run some tests and compare results (I will do this, but not today).

[dieterdreist]

Am 10.01.2015 um 14:36 schrieb imagico notifications@github.com:

And I will prophylactically address the remark from @dieterdreist that 'natural' is a suboptimal choice of key here ;-):

thank you, I do indeed share these points. Tagging issues aside, the proposed rendering looks nice ;-)=

[matkoniecz]

@imagico (alternative rock pattern)

This also makes it less rock-like IMO but smaller forms are probably better identifiable. If this is generally considered better i can switch it.

Smaller forms are identifiable, it is much better at not looking like fake data. It is also less distracting for large areas. I would strongly recommend using it as a pattern.

[matthijsmelissen]

Smaller forms are identifiable, it is much better at not looking like fake data. It is also less distracting for large areas. I would strongly recommend using it as a pattern.

+1

[imagico]

OK - changed the pattern and merged changes into one commit.

[imagico]

Great, thanks for the quick handling.