Tag natural=rock (node and area) is not rendered

[mkyral]

I've changed incorrectly mapped natural=cliff area to natural=rock and it is not render at all.

https://www.openstreetmap.org/way/263176747

I thought it is only connected to area, but later on I've find that even node is not rendered.

http://www.openstreetmap.org/node/3841474372

JOSM uses following icon: https://josm.openstreetmap.de/export/11963/josm/trunk/images/presets/misc/rock.svg

[imagico]

Yes, we currently do not render this. The numbers:

• about 145k nodes
• about 10k areas
• nearly all of the nodes (about 135k) are from canvec imports
• only about 3400 features have a name tag

We could render areas with the same styling as natural=bare_rock and an outline in addition. Nodes could be rendered with a small icon - design wise it would make sense to consider having two slightly different variants, one for natual=stone, one for natural=rock.

[HolgerJeromin]

nodes could be rendered as a grey dot (similar to barrier)...

[mboeringa]

nearly all of the nodes (about 135k) are from canvec imports

If that is the case, than probably almost all of them are obstructive dangerous rock formations on the coast and inland waterways and lakes, which also explains almost none having a name.

Look at this section of a scanned CanMatrix map: the symbol used is a "+" and notice how they show up near an island of an inland lake:

[mboeringa]

Which also raises the question if they shouldn't be re-tagged according to OpenSeaMap: seamark:type=rock

The "+" sign also seems in accordance with S100 / OpenSeaMap symbolization: http://wiki.openstreetmap.org/wiki/Seamarks/Rocks

Actually, quite of a lot of these may even be underwater, at least temporarily based on tides. The "+" symbol even seems to be the sign for permanently submerged dangerous rock formations based on the OSM Wiki page.

[mkyral]

But not all rocks are on water. E.g. Czech Republic has no sea ;-)

[imagico]

Don't worry - there are no intentions here to base rendering primarily on use of a tag in imports which may or may not be in line with how the tag is used otherwise.

[aaronstar]

As an example, recently I changed several features around Uluru, Northern Territory, Australia to natural=bare_rock from natural=rock. In this instance natural=bare_rock was more appropriate, however, this decision was also supported by the fact that natural=rock was not rendered. It would be good to see some form of rendering of this feature.

[Tomasz-W]

Do you think we should consider only icon/ dot rendering or area fill also?

[PontiacCZ]

I am for filling the areas as well, there are rocks tens of meters in diameter (or even hundreds).

Looking forward to see rocks and stones rendered! :-)

[Tomasz-W]

I propose:

• for icon: edited memorial=stone icon in man-made-grey (but I'm open to any other ideas)

• for areas: #bfbab6 fill + rock_overlay.png

Here are some Photoshop mock-ups:

[PontiacCZ]

I was thinking about a texture instead of a solid color for rocks too and this looks good!

[Adamant36]

Rock area as how @Tomasz-W suggested

@Tomasz-W, do you want to provide an .SVG of the memorial=stone icon filled in so I can test it?

[Tomasz-W]

@Adamant36 https://gist.github.com/Tomasz-W/e2bcbebf5f5ebb05c01272ba16325d24

Please add more examples (with different rock areas surroundings), I'm considering using a little bit darker shade for rock areas. What do you think?

[jeisenbe]

I’d suggest using the same area rendering for natural=bare_rock and natural=rock. (Fixed typo)

[Adamant36]

@jeisenbe, you mean natural=rock and natural=bare_rock? Also, how come? What's wrong with natural=rock being rendered different? I guess the difference between them is sort of superficial.

[jeisenbe]

Yes, sorry of the typo.

The wiki says "natural = rock describes a notable rock feature or small group of rocks, attached to the underlying bedrock" and natural=bare_rock can also be used for bedrock: "An area of bare rock [that] is sparsely vegetated or not vegetated at all, so that the solid bedrock becomes visible."

So I believe it would be best to render them the same, when tagged as an area feature.

Also, for the node rendering with an icon, take a look at natural=stone - although it's not approved.

[Adamant36]

You don't think that since its the difference between a level feature versus one sticking out of the ground that you have to climb on that they should be rendered slightly differently? Like, what about natural=rock's that are mapped next to or inside natural=bare_rock areas? It would then look like one continuous rock. Which would be misleading.

[jeisenbe]

its the difference between a level feature versus one sticking out of the ground that you have to climb on

Bare_rock can also be used for vertical features. This is one of the example images on the natural=bare_rock page:

what about natural=rock's that are mapped next to or inside natural=bare_rock areas?

Good point. It might be a good idea to try an outline for natural=rock; this would be sufficient to show the extent of the feature. This would mainly be useful if the rock has a name, eg. used for bouldering / rock climbing. Perhaps something like:

    [zoom >= 17] {
      line-width: .3;
      line-color: darken(@bare_ground, 20%);
      [name != ''] {
        line-width: 0.5;
      }

[Adamant36]

I think outlines work good, if even, for "imaginary" borders like administrative boundaries. Not so much for natural features though. For something like rocks it would be to abstract and there would be zero way for anyone to know that's it was. At least alone. Maybe there could be an outline with the pattern, but then it would be pointless because there's a pattern.

[jeisenbe]

It would mainly be useful if the rock / boulder is named, hence my suggestion to render the outline with a slightly wider line (0.5 pixel) if name is not null. On Mon, Dec 3, 2018 at 8:32 AM Adamant36 notifications@github.com wrote:

I think outlines work good, if even, for "imaginary" borders like administrative boundaries. Not so much for natural features though. For something like rocks it would be to abstract and there would be zero way for anyone to know that's it was. At least alone. Maybe there could be an outline with the pattern, but then it would be pointless because there's a pattern.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gravitystorm/openstreetmap-carto/issues/2616#issuecomment-443552836, or mute the thread https://github.com/notifications/unsubscribe-auth/AoxshNboFMoU6KGEKE4cgv3Yguchn-Hmks5u1GMXgaJpZM4ND8zO .

[Adamant36]

only 4909 of them out of 170,279, or 0.01%, have names and who knows how many of those are ways versus nodes. Its a really small percentage to have a special rendering based off of.

[jeisenbe]

Many if the unnamed rocks are from a big French import; see the earlier discussion in this thread.

4909/170279= 3% On Mon, Dec 3, 2018 at 9:25 AM Adamant36 notifications@github.com wrote:

only 4909 of them out of 170,279, or 0.01%, have names and who knows how many of those are ways versus nodes. Its a really small percentage to have a special rendering based off of.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gravitystorm/openstreetmap-carto/issues/2616#issuecomment-443556899, or mute the thread https://github.com/notifications/unsubscribe-auth/AoxshKYyVG39v4kUyh-1ZEZpMOJ1sACGks5u1G-RgaJpZM4ND8zO .

[Adamant36]

Just because they are from an import originally doesn't necessarily mean they shouldn't be rendered.

@Tomasz-W, what do you think?

[Tomasz-W]

@Adamant36 I would go with https://github.com/gravitystorm/openstreetmap-carto/issues/2616#issuecomment-443490688 or a little bit lighter shade + icon for rock nodes

[kocio-pl]

I guess area should be adjusted to natural=bare_rock - probably just less granular pattern (this is also how natural=bare_rock is different from natural=scree and natural=shingle).

[Adamant36]

@Tomasz-W, you want to come up with a less granular pattern based on the one for natural=bare_rock? It makes sense to do it that way for me.

[Tomasz-W]

@Adamant36 I've tried many times and I still can't use that Imagico's tool for patterns properly, so I can't help there.

[Adamant36]

Bummer. Me neither. Since its just thinning it out, you can't edit the dots out in a normal program?

[jeisenbe]

It would be best to use the pattern generator to keep the semi-random look. Also note that it makes a pattern that repeats properly at tile boundaries.

I can upload some patterns tomorrow for you guys. On Sun, Dec 9, 2018 at 5:05 AM Adamant36 notifications@github.com wrote:

Bummer. Me neither. Since its just thinning it out, you can't edit the dots out in a normal program?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gravitystorm/openstreetmap-carto/issues/2616#issuecomment-445486032, or mute the thread https://github.com/notifications/unsubscribe-auth/AoxshOulxEe8umZf5xWbAXQ8Kr_cIB7wks5u3Bt1gaJpZM4ND8zO .

[Adamant36]

Alright. Thanks.

[jeisenbe]

Here are a few options to consider. I'm not sure what direction to take this pattern.

I tried #d1c8be for the first 3 patterns, which is about 10% darker than bare_earth (#eee5dc). This is darker than the current bare_rock pattern, however.

1)

2)

3)

These use #dfd6cc for the pattern, more similar to the current bare rock pattern: 4)

5)

6)

Zip with the 6 original svg files: rock.zip

[Tomasz-W]

@jeisenbe We need some 'side by side' examples near bare_rock to compare.

[jeisenbe]

I was hoping that @Adamant36 might want to make some test images. I have not yet downloaded any areas that have natural=rock areas next to bare_rock.

Here's a sample of the current bare_rock to compare:

[Adamant36]

Sure. I'll do it when I get some time. The first three patterns look interesting.

[kocio-pl]

I like 2 the most, because the difference is visible (not a general surface, there are single objects visible).

[jeisenbe]

More rock patterns to try, similar to 1), 2) and 3), which were popular.

I think they pattern may need to be smaller however; I remember that the large square patterns looked good alone for allotments, but on the map smaller patterns work better, especially at mid to low zoom levels where many area features are very small.

7) 0.25 scale, closer together (distance 6), with darker pattern in #d1c8be http://www.imagico.de/map/jsdotpattern.php#x,256,jdp82238;g,6,32,32;rx,250,2,32,32;rd,1,0,1,rock,0.25,24,24,0,jdp3249,d1c8be,eee5dc;

8) 0.5 scale, distance 18, #d1c8b3 http://www.imagico.de/map/jsdotpattern.php#x,256,jdp83313;g,18,32,32;rx,250,2,32,32;rd,1,1,1,rock,0.5,24,24,0,jdp81566,d1c8be,eee5dc;

9) 0.2 scale, distance 10, #d1c8b3 http://www.imagico.de/map/jsdotpattern.php#x,256,jdp83313;g,18,32,32;rx,250,2,32,32;rd,1,1,1,rock,0.5,24,24,0,jdp81566,d1c8be,eee5dc;

Zip file with original svg files (which need conversion to png with transparency prior to use): rock-7-8-9.zip

[Adamant36]

I really like 8. It looks better then 1 did. 9 is good also.

[Adamant36]

@jeisenbe, totally off topic but do you think we apply the same thing with parking lot areas to show their surface or do you think it would even be worth doing? A few of the patterns you created kind of make me think it would possibly be cool.

[jeisenbe]

Do you mean to distinguish unpaved parking lots from paved?

That could have some benefit but Inwoukd use a more subtle pattern, similar to those tested in the unpaved roads rendering issue. And we would need to have a rendering for unpaved roads first - that would be a higher priority On Thu, Dec 13, 2018 at 4:19 AM Adamant36 notifications@github.com wrote:

@jeisenbe https://github.com/jeisenbe, totally off topic but do you think we apply the same thing with parking lot areas to show their surface or do you think it would even be worth doing? A few of the patterns you created kind of make me think it would possibly be cool.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gravitystorm/openstreetmap-carto/issues/2616#issuecomment-446710269, or mute the thread https://github.com/notifications/unsubscribe-auth/AoxshD29U_zR4MpIq6ssan7lrSA3Xq38ks5u4Va9gaJpZM4ND8zO .

[Adamant36]

Yeah exactly. Hhhhmmm OK. I was thinking about how rendering for unpaved roads should probably come first. Since it would look weird if they had to do different of a pattern and I agree roads should have the priority. So I'll wait to do an issue about the parking lot thing until after that's done.

[Adamant36]

Zip file with original svg files (which need conversion to png with transparency prior to use): rock-7-8-9.zip

@jeisenbe, you want to convert them to png and do the transparency thing so I can use them, since your the one that came up with them? Graphics aren't my thing and @Tomasz-W is busy so he's not going to do it.

[jeisenbe]

I’ve been using http://cloudconvert.com On Sun, Jan 27, 2019 at 4:10 PM Adamant36 notifications@github.com wrote:

Zip file with original svg files (which need conversion to png with transparency prior to use): rock-7-8-9.zip

@jeisenbe https://github.com/jeisenbe, you want to convert them to png and do the transparency thing so I can use them, since your the one that came up with them? Graphics aren't my thing and @Tomasz-W https://github.com/Tomasz-W is busy so he's not going to do it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gravitystorm/openstreetmap-carto/issues/2616#issuecomment-457894501, or mute the thread https://github.com/notifications/unsubscribe-auth/AoxshN7liT_IGZJ44y-b5-IVlAsfG9pSks5vHVDxgaJpZM4ND8zO .

[jeisenbe]

Link to the files on cloudconvert: https://jackie.infra.cloudconvert.com/download/~329742a5a0aec0bea47829e7a722a14f07c0172b37dbcf7945b6937a355e25cc3e4a5b96d66762e7d3724cc9

Or this should work: rock.zip

[Sjord]

There is a filename clash: natural=bare_rock currently renders using symbols/rock_overlay.png. That filename would also be a obvious name for rendering natural=rock. So I propose to rename the current rock_overlay.png to bare_rock_overlay.png. An alternative would be to use render both using the same overlay.

Here are the images for what is called rock 8 above. These have transparency.

rock_overlay.png:

rock_overlay@2x.png:

Also, remember to copy 8-rock.svg into symbols/generating_patterns/rock.svg.

[jragusa]

Since it's just a matter of size according to the wiki page, the pattern of natural=bare_rock could be applied with a latter rendering (z=16 or 17). An alternative would be to have a more spaced pattern.

[PontiacCZ]

Something went wrong with the commit from August 2019? Currently natural=rock is not rendered.

https://www.openstreetmap.org/node/7058306101#map=19/49.18632/17.36780

[imagico]

This issue is open, natural=rock is not rendered (and has never been IIRC).

[Adamant36]

Nothing went wrong with it. It was declined and closed without being merged (this issue should probably be closed also to reflect it).

[PontiacCZ]

Oh, I am sorry. I saw the commit and thought it finally resolved this issue.

No problem with closing this isue but... maybe it would be good to get the natural=rock rendered first? At least nodes (currently over160k of them worldwide), areas can be tagged with bare_rock.

https://taginfo.openstreetmap.org/tags/?key=natural&value=rock#map

[Adamant36]

No problem with closing this isue but... maybe it would be good to get the natural=rock rendered first? At least nodes (currently over160k of them worldwide), areas can be tagged with bare_rock.

There was a reason it ended up not getting rendered. If I recall correctly it was because the tag wasn't being used constantly enough as intended. I don't see that changing any time soon since its largely due to the ambiguous meaning of the word "rock." This isn't the place for a tagging discussion though.