Render bare_rock pattern in landcover-area-symbols

[jeisenbe]

Fixes #3707 - I believe this is the only missing feature that is currently not rendered when in the intertidal range.
Also fixes #1473 which mentioned bare_rock

Changes proposed in this pull request:

• Remove pattern rendering for natural=sand
• Render bare_rock pattern in landcover-area-symbols, above water areas

Explanation

• The tag natural=sand is currently rendered with a unique color fill, different than beaches or bare_earth, so the pattern is not needed to distinguish sand from similar areas. Removing the pattern will make the map less busy. This will also make it easier to add a pattern for natural=dune areas, if desired.
• Removing the natural=sand pattern will also hide areas tagged natural=sand outside of the coastline. These should be tagged natural=beach or natural=shoal
• Rendering the natural=bare_rock pattern in the landcover-area-symbols layer, above water areas, will show areas of rock at the coastline, between the high and low tide lines. This will match with the rendering for natural=beach areas which also show the pattern above water.

(I considered changing the initial zoom level for the bare_rock pattern from z5 to z8 or z10, since at low zoom levels the pattern is usually not visible and mainly adds visual noise without conveying significant information, but I believe the natural=scree and natural=shingle patterns should also be changed at the same time, so this will be another PR.)

Test renderings

Horton's Nose - sand next to beach and a patch of bare_rock (on land, and another outside of coastline, upper right)

http://www.openstreetmap.org/#map=17/53.31607/-3.50920
z17 before

z17 after

Ty Anquer - natural=bare_rock outside and inside of coastline, next to natural=beach

z16 before

z16 after

z17 before

z17 after

Pointe de Trefeuntec

z16 before

z16 after

z17 before

z17 after

Beg an ty-Guard - bare_rock

z16 before

z16 after

[imagico]

The pattern over water looks different in different examples. And neither of them works for me as a pattern - the foreground-background contrast is too small for that.

This is technically tricky to tune because the two versions with different background colors cannot be adjusted independent of each other. You probably need to use two pattern images - one in the base layer that is covered by water and one in landcover-area-symbols. This way you could get the same visual results over land while getting a darker pattern over water.

Care also needs to be taken not to incentivize tagging rocky reefs with natural=bare_rock. Differentiating reef rendering by reef=* could prevent that.

The sand change looks fine to me - that is essentially reverting #2746.

[jeisenbe]

You probably need to use two pattern images - one in the base layer that is covered by water and one in landcover-area-symbols. This way you could get the same visual results over land while getting a darker pattern over water.

I don't quite understand how that would work. I can see how it would be easier to get a lighter pattern this way, by adding the two patterns. Would it require transparency?

[imagico]

Yes, you could also try other ideas using comp-op but that would probably be less intuitive. I have not tried this and i don't know if it would actually work as intended.

[jragusa]

I notice that the current rendering of natural=beach is different to your pictures. Is it normal ?

I agree about the too subtle rendering of natural=bare_rock.

Please also fix your addresses, they link to 404 error due to wrong place of "#" (map# → #map). And it's Point of Ayr ;)

[imagico]

I notice that the current rendering of natural=beach is different to your pictures. Is it normal ?

The map on osm.org currently lags significantly behind this style.

[jeisenbe]

Differentiating reef rendering by reef=* could prevent that.

https://taginfo.openstreetmap.org/keys/reef#values - used a little under 4000 times, vs a little under 19,000 reefs mapped as areas.

Main values are coral (3146 times), rock (493 times) and sand (46 times). So reef=rock could be rendered in a similar way to bare_rock. Could we rendering reef=sand with the sand pattern (as used for beach and shoal) instead, perhaps? Coral reefs could keep the current rendering.

[imagico]

I tried and you can get a reasonable color balance while keeping the results over land with a single pattern image by darkening the color and increasing transparency:

http://imagico.de/files/rock_overlay.png
http://imagico.de/files/rock_overlay.svg

The problem is that rendering the rock pattern in landcover-area-symbols would mean the pattern is not only rendered over ocean but also over all other water features including water lines. This creates a significant amount of noise. Overall there are currently a lot of areas where lakes, glaciers etc. are not cut out of a larger base mapping of bare_rock. Such rendering would provide feedback for cleaner mapping but it would certainly at first look fairly ugly in a lot of places and the reason for the different rendering results would not always be so clear to mappers. We have had a similar situation when we introduced the wood/forest pattern in the overlay.

I also produced a pattern that could be used for coral reefs:

http://imagico.de/files/reef_coral.svg

[jeisenbe]

rendering the rock pattern in landcover-area-symbols would mean the pattern is not only rendered over ocean but also over all other water features including water lines.

True, this also happens with the forest/woodland pattern and scrub pattern now.

Changing the river/stream color to a darker shade of blue, as planned, will help some.

Another option would be to use a less dense pattern for bare_rock. Some other patterns were already tried out in #2616 (comment) and #2616 (comment) - but these are probably not an improvement yet.

[jeisenbe]

4 new options which are less dense, and mostly smaller pattern size, compared to current pattern. All use the same color and opacity suggested above (opacity 0.3, color is #8a99a5)

1. Smaller, evenly spaced
   

2. Smaller but closer
   

3. Mid-sized, but more space
   

4. Even smaller, some space between
   

For comparison, here's the modified pattern that @imagico created; the shapes are the same as the current bare_rock pattern, (but opacity is 0.3 and color is #8a99a5, as in the others):

[imagico]

True, this also happens with the forest/woodland pattern and scrub pattern now.

Yes, and i have mentioned that when these were moved to landcover-area-symbols there was confusion because of unexpected rendering results, see #1754, #1796, #1821, #1954, #3347.

But also note these are pictorial symbol patterns with individually identifiable and readable symbols while bare_rock uses a structure pattern that is read and understood by map users based on its overall structure in combination with the base color. Due to this it is much more confusing seeing such pattern on a different background than with wood/scrub.

[kocio-pl]

Hi, @jeisenbe! Please remove the sand part, because it makes this PR more complicated in terms of discussion and these two are only remotely related.

Currently I don't agree with removing sand pattern (but this is not my final say - we can discuss the dune problem elsewere), while I don't have any opinion on rock rendering (but I don't see anything wrong with it, so I leave it to the interested people to decide).

[imagico]

I outlined a technical approach that could solve the drawing order and independent design for water and land problems in #3854.

[jeisenbe]

#3854 would change the water layers to use dst-out to cut out the shape of water and ocean areas from all the landcover, land patterns, water-lines and land, then use dst-over so that water and water patterns are rendered behind. This would work very nicely, and would not require changing the current bare_rock pattern on land, as suggested in this PR.

However, we could still consider changing the bare_rock pattern, if it's considered to be too busy compared to the scree/ shingle and sand patterns. While the changes in #3854 would allow using different colors and patterns over land and over water, it might still be sensible to use the same svg pattern for bare_rock over land and over water, for consistency, and the current pattern may be too solid for use over water?

Should I show some examples with the new options above?

[jeisenbe]

Here are tests with the new rock_overlay - same pattern, different color and transparency, which @imagico created above: #3851 (comment) - (opacity 0.3, color is #8a99a5).

It's certainly improved, but I will also show some other options:

z16 Pasir Putih
http://www.openstreetmap.org/#map=16/-4.0400/138.947516

z14 Puncak Jaya
http://www.openstreetmap.org/#map=14/-4.0719/137.1774.png

z17 ty Anquer
http://www.openstreetmap.org/#map=17/48.15064/-4.27294

z17 Pointe de Trefeuntec
A couple kilometers south of ty Anquer

(These are with bare_rock5, from the most recent commit 5fd8ffd)

[jeisenbe]

1) bare_rock1.svg (with opacity 0.3, color #8a99a5).
This pattern is smaller and has some space between each symbol. It turned out looking a little too regular, so I don't think this one works well.

z16 Pasir Putih
http://www.openstreetmap.org/#map=16/-4.0400/138.947516

z14 Puncak Jaya
http://www.openstreetmap.org/#map=14/-4.0719/137.1774.png

z17 ty Anquer
http://www.openstreetmap.org/#map=17/48.15064/-4.27294

z17 Pointe de Trefeuntec

Commit f05a1d2 - this is the current, most recent, commit.

[jeisenbe]

2) bare_rock2.svg (with opacity 0.3, color #8a99a5).
This pattern is denser than 1) but a little less dense and the elements are a little smaller than the current pattern

z16 Pasir Putih

z14 Puncak Jaya

z17 ty Anquer

z17 Pointe de Trefeuntec

Commit 137b3a6

[jeisenbe]

3) bare_rock3.svg (with opacity 0.3, color #8a99a5).
This pattern is larger than the others. I think this makes it too strong; it's hard to see paths or streams.

z16 Pasir Putih

z14 Puncak Jaya

z17 ty Anquer

z17 Pointe de Trefeuntec

From commit 7baec10

[jeisenbe]

4) bare_rock4.svg (with opacity 0.3, color #8a99a5).
This pattern is the smallest and slightly more closely spaced than 1), though still not overlapping like the current pattern.

This is the best-looking in some situations, though it might need to be a little darker.
I believe 2) is the next best, and then the current pattern is ok too.

z16 Pasir Putih

z14 Puncak Jaya

z17 ty Anquer

z17 Pointe de Trefeuntec

Tested in commit 3691c70

[imagico]

I think you should concentrate on one thing in this PR and not mix it with other things. Changing the bare_rock pattern is separate from how to render bare_rock over water.

When you compare different structure patterns it is often useful to separate differences in pattern weight from differences in pattern structure. The most reliable way of doing that is to generate for every pattern variant a sequence of different rendering intensities and then move these relative to each other so they match in overall weight. Technically this is much more efficient to do by compositioning the pattern using imagemagick than by rendering again and again with mapnik.

The reason why the bare_rock pattern is currently heavier than scree/shingle is because bare rock areas are usually 'heavier' (in other words: more serious obstacles, more weighty appearance) than scree/shingle. Most maps rendering rock and scree use a similar or even stronger difference in weight of rendering styles.

[jeisenbe]

The current commit uses the existing pattern, with the new color and transparency, as shown in #3851 (comment) - but I thought I should try some other options to see if it was easy to improve the rendering.

Since none of the 4 new patterns was clearly an improvement, I agree with keeping the existing pattern.

[jeisenbe]

@imagico - are you in favor of this PR in the short-term? I imagine that implementing #3854 will take some time.

[imagico]

I would not be in favor of it but i would not block it if others see it positively.

#3854 is not a matter of difficult implementation i think but i am not sure if there is consensus in support of it.

[jeisenbe]

I am not sure if there is consensus in support of it.

Best way to find out would be to submit a PR. I believe this could be done before changing the river color (or ocean color), and in fact it might be good to discuss first, since it could influence color choices for water areas. Would you be willing to finish the code? I'm willing to do test images and review.

[jeisenbe]

Closing for now in favor of the solution proposed in issue #3854. If that solution is rejected we can reconsider this PR.