render cave symbols less opaque when access is restricted

[tilmanb]

natural=cave_entrance is rendered less opaque when access is restricted. This is a partial fix for #1012 .

Visual comparison:
left: old, right: opaque 0.55
|
|

More opacity values (0.1 to 0.8):

[matkoniecz]

I admit that I am not sure is it a good idea - as tagging in that case is not clear. [natural=cave_entrance, access=no] may be interpreted as lack of access to the cave tunnels or as cave entrance that may not be reached.

Can you provide before/after comparison?

Also, please squash this two commits into one.

[HolgerJeromin]

thanks for your pull request!
i too would interprete access no as collapsed or something like that and private as reachable but not allowed to enter.
I am not sure if a non reachable cave should be opaque or not :-)

[tilmanb]

As far as I understand, the tag natural=cave_entrance says ( on http://wiki.openstreetmap.org/wiki/Tag:natural%3Dcave_entrance ) on the access tag:
"no" if bricked, locked or forbidden
"private" if locked and you can get the key

and on using barrier

gate/wall/etc.

So it is unclear, whether acces means physical access or legal access. I think the topic of reachability is another one, and does not need to be encoded in the rendering of the cave entrance, but on the tracks/paths (if any) leading towards the cave entrance.

For the technical part: I will provide visual comparisons this evening. To squash those two commits into one I should open a new branch and re-perform the changes there, and then open another pull request?

[pnorman]

You can use this pull request - just push more commits to the branch

[tilmanb]

Can't get the table to show correctly when editing the first post, so here in table style:

Old	New (Opaque 0.55)

[HolgerJeromin]

oh, i did not checked the wiki page for special access definition. So rendering no and private with opacity seems ok for me. In both cases you need preparation before entering.

could you try rendering with 0.3? on my phone 0.5 is not very different if you have nothing to compare.

[tilmanb]

see updated first post for comparison of opacity values (text and marker) from 0.1 to 0.8 on forest.

[HolgerJeromin]

Thank you.
If the feature has no name 0.55 is not very clear (on my mobile and desktop). I would propose 0.4 for opacity. Other opinions?

[tilmanb]

Yes, on closer inspection I am in favor of using 0.4. amenity=parking uses 0.33, but as caves are often drawn on darker backgrounds compared to parkings, I propose using something more visible. So 0.4 seems good to me.

[tilmanb]

@mkoniecz have you had a chance to look at the before and after comparisons? Note that 0.4 seems to be the best opacity value (as seen in the opacity row in the updated first post).
Also, the wiki page is now updated and further clarified regarding access and barrier.
I can also provide renderings with 0.4 opacity (or the complete opacity range) on different backgrounds, if needed.

[tilmanb]

Here are more opacity values on different backgrounds. Again, I propose 0.4.

[pnorman]

.4 looks good, as would .3 on the icon and and .4 or higher on the text.

[tilmanb]

Is there anything left to do on my part? I am unsure on how to "squash two commits into one" as requested by mkoniecz without using another branch.

[matthijsmelissen]

As far as I'm concerned, this is too specialistic for the main map. Before going into a cave, you'd need to check if you need specialistic equipment etc. anyway. So I don't think showing the access restrictions of caves is very useful.

[HolgerJeromin]

we had a goverment in germany deleting cave entrance osm points. Thats why i proposed this change on the main map.

[matthijsmelissen]

Thanks for the additional information, I wasn't aware of that.

[pnorman]

I'm not sure why, but I'm not finding that the opacity indicates access as clearly as it does for parking icons.

[matthijsmelissen]

I don't think a cave icon on a map intuitively implies that you can (legally and/or safely) enter the cave.

I also agree with @pnorman that the opacity does not make its meaning very clear in this case.

So I'd propose to not merge this.

[matkoniecz]

@tilmanb Thanks for your work, but unfortunately this pull request will not be merged.