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

mkyral · 2017-04-21T07:21:20Z

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 · 2017-04-21T09:37:10Z

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 · 2017-04-21T12:50:48Z

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

mboeringa · 2017-04-21T17:01:22Z

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 · 2017-04-21T17:32:15Z

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 · 2017-04-21T19:14:00Z

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

imagico · 2017-04-21T19:44:55Z

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 · 2017-08-24T05:54:49Z

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 · 2018-07-15T12:06:46Z

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

PontiacCZ · 2018-10-18T14:30:54Z

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 · 2018-10-19T19:44:55Z

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 · 2018-10-19T20:42:42Z

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

Adamant36 · 2018-12-02T08:31:11Z

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 · 2018-12-02T09:02:48Z

@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 · 2018-12-02T09:08:29Z

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

Adamant36 · 2018-12-02T09:10:38Z

@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 · 2018-12-02T09:41:15Z

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 · 2018-12-02T09:49:39Z

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 · 2018-12-02T12:34:39Z

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 · 2018-12-02T23:32:37Z

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 · 2018-12-03T00:11:16Z

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 ***@***.***> 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 <#2616 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AoxshNboFMoU6KGEKE4cgv3Yguchn-Hmks5u1GMXgaJpZM4ND8zO> .

Adamant36 · 2018-12-03T00:25:51Z

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 · 2018-12-03T00:38:37Z

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 ***@***.***> 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 <#2616 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AoxshKYyVG39v4kUyh-1ZEZpMOJ1sACGks5u1G-RgaJpZM4ND8zO> .

Adamant36 · 2018-12-08T17:32:45Z

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 · 2018-12-08T18:00:02Z

@Adamant36 I would go with #2616 (comment) or a little bit lighter shade + icon for rock nodes

kocio-pl · 2018-12-08T18:32:58Z

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 · 2018-12-08T19:21:15Z

@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 · 2018-12-08T19:54:48Z

@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.

jeisenbe · 2018-12-10T05:20:00Z

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.

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

Zip with the 6 original svg files:
rock.zip

Tomasz-W · 2018-12-10T08:11:11Z

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

jeisenbe · 2018-12-10T08:37:07Z

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 · 2018-12-10T08:44:32Z

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

kocio-pl · 2018-12-10T11:44:43Z

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

jeisenbe · 2018-12-11T04:43:04Z

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.

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;
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;
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 · 2018-12-11T08:34:44Z

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

Adamant36 · 2018-12-12T19:19:21Z

@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 · 2018-12-12T21:40:41Z

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 ***@***.***> 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 <#2616 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AoxshD29U_zR4MpIq6ssan7lrSA3Xq38ks5u4Va9gaJpZM4ND8zO> .

Adamant36 · 2018-12-12T21:48:36Z

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 · 2019-01-27T07:10:39Z

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 · 2019-01-27T12:49:46Z

I’ve been using http://cloudconvert.com

…

On Sun, Jan 27, 2019 at 4:10 PM Adamant36 ***@***.***> 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 <#2616 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AoxshN7liT_IGZJ44y-b5-IVlAsfG9pSks5vHVDxgaJpZM4ND8zO> .

jeisenbe · 2019-01-27T12:58:25Z

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

Or this should work:
rock.zip

Sjord · 2019-07-31T15:39:30Z

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:

[email protected]:

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

Fixes gravitystorm#2616. The used overlay is rock 8 as mentioned in gravitystorm#2616. Rock is rendered differently than bare_rock, especially for cases when a notable rock feature is surrounded by bare rock.

jragusa · 2020-03-20T19:53:38Z

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 · 2020-06-24T09:34:14Z

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 · 2020-06-24T10:02:49Z

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

Adamant36 · 2020-06-24T10:04:29Z

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

PontiacCZ · 2020-06-24T10:13:29Z

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 · 2020-06-24T10:46:16Z

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.

Pecita · 2020-09-24T10:47:37Z

An area of bare rock is sparsely vegetated or not vegetated at all.
A rock, although significant, can be covered by trees.
For this reason I prefer a rock to be represented by a dark gray ovoid icon so that it can be inserted into a natural=wood or a landuse=forest as a single point.

Mahabarata · 2023-07-02T17:33:12Z

With more 226000 elements with the tag natural=rock, maybe this issue now is more relevant ?

The icon on iD seems great, no ? https://www.openstreetmap.org/edit?node=3183806161#map=19/53.05846/15.17789

Why not to use it on nodes and use the bare_rock rendering on areas ?

PontiacCZ · 2023-11-20T16:54:26Z

I wonder how many is enough... ;-)

I also like the iD icon.

Nekzuris · 2024-03-20T18:44:12Z

I've seen many rock areas changed to bare_rock only for the render, but according to the wiki, rock was the right tag.
I don't really understand why it's still not rendered yet.

nebulon42 added the landcover label Apr 23, 2017

nebulon42 added this to the New features milestone Apr 23, 2017

Tomasz-W mentioned this issue Oct 20, 2018

Good first issues [meta-ticket] #3298

Closed

26 tasks

jragusa mentioned this issue Dec 13, 2018

historic=memorial and tourism=artwork conflicts #3565

Open

Tomasz-W mentioned this issue Jan 1, 2019

Good first issues [meta-ticket] #3617

Closed

19 tasks

polarbearing mentioned this issue Jan 9, 2019

Render natural=stone #3628

Open

Sjord mentioned this issue Aug 2, 2019

Render rock #3832

Closed

jeisenbe mentioned this issue Aug 28, 2019

Render bare_rock pattern in landcover-area-symbols #3851

Closed

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

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

Comments

mkyral commented Apr 21, 2017

imagico commented Apr 21, 2017

HolgerJeromin commented Apr 21, 2017

mboeringa commented Apr 21, 2017 • edited Loading

mboeringa commented Apr 21, 2017 • edited Loading

mkyral commented Apr 21, 2017

imagico commented Apr 21, 2017

aaronstar commented Aug 24, 2017 • edited Loading

Tomasz-W commented Jul 15, 2018

PontiacCZ commented Oct 18, 2018

Tomasz-W commented Oct 19, 2018

PontiacCZ commented Oct 19, 2018

Adamant36 commented Dec 2, 2018

Tomasz-W commented Dec 2, 2018

jeisenbe commented Dec 2, 2018 via email • edited Loading

Adamant36 commented Dec 2, 2018

jeisenbe commented Dec 2, 2018 • edited Loading

Adamant36 commented Dec 2, 2018

jeisenbe commented Dec 2, 2018

Adamant36 commented Dec 2, 2018

jeisenbe commented Dec 3, 2018 via email

Adamant36 commented Dec 3, 2018

jeisenbe commented Dec 3, 2018 via email

Adamant36 commented Dec 8, 2018

Tomasz-W commented Dec 8, 2018

kocio-pl commented Dec 8, 2018 • edited Loading

Adamant36 commented Dec 8, 2018

Tomasz-W commented Dec 8, 2018

jeisenbe commented Dec 10, 2018 • edited Loading

Tomasz-W commented Dec 10, 2018

jeisenbe commented Dec 10, 2018

Adamant36 commented Dec 10, 2018

kocio-pl commented Dec 10, 2018

jeisenbe commented Dec 11, 2018

Adamant36 commented Dec 11, 2018

Adamant36 commented Dec 12, 2018

jeisenbe commented Dec 12, 2018 via email

Adamant36 commented Dec 12, 2018

Adamant36 commented Jan 27, 2019

jeisenbe commented Jan 27, 2019 via email

jeisenbe commented Jan 27, 2019

Sjord commented Jul 31, 2019

jragusa commented Mar 20, 2020

PontiacCZ commented Jun 24, 2020

imagico commented Jun 24, 2020

Adamant36 commented Jun 24, 2020 • edited Loading

PontiacCZ commented Jun 24, 2020 • edited Loading

Adamant36 commented Jun 24, 2020

Pecita commented Sep 24, 2020

Mahabarata commented Jul 2, 2023

PontiacCZ commented Nov 20, 2023

Nekzuris commented Mar 20, 2024

mboeringa commented Apr 21, 2017 •

edited

Loading

mboeringa commented Apr 21, 2017 •

edited

Loading

aaronstar commented Aug 24, 2017 •

edited

Loading

jeisenbe commented Dec 2, 2018 via email •

edited

Loading

jeisenbe commented Dec 2, 2018 •

edited

Loading

kocio-pl commented Dec 8, 2018 •

edited

Loading

jeisenbe commented Dec 10, 2018 •

edited

Loading

Adamant36 commented Jun 24, 2020 •

edited

Loading

PontiacCZ commented Jun 24, 2020 •

edited

Loading