Openstreetmap-carto: Strange rendering of toilets in 4.18.0

[giggls]

Expected behavior

Rendering toilets as in 4.17.0

Actual behavior

Rendering of toilets is instead very light in 4.18.0

Links and screenshots illustrating the problem

https://tile.openstreetmap.org/19/274268/181238.png

I have no Idea which causes this. Maybe some opacity setting.

[Adamant36]

I assume it has something to do with issue #3528 and it being a private POI. Maybe it needs some slight adjusting. It would help if you provided a link to the exact location of the issue though so people can how its tagged or whatever.

[Tomasz-W]

In OSM-Carto, half-transparency of some objects symbolises limeted access to them.

@giggls Did you open this issue because you didn't know about it at all, you consider it as a bad solution or maybe you think that transaparency is set too light?

[giggls]

The latter. I think this is too light.

I am also not convinced that such a special thing as access=private should be rendered at all.

[Tomasz-W]

I propose to change issue name to "Make private POIs more visible". If there will be more examples of bad visibility of them we could change opacity from 0.33 to 0.5

[polarbearing]

We might considering to change the opacity into a fixed colour value, to avoid the underlying stuff shining through. Similarly, in some issue gravitystorm gave a hint how to paint an underlying colour before applying the transparent feature.

[jragusa]

We might considering to change the opacity into a fixed colour value, to avoid the underlying stuff shining through. Similarly, in some issue gravitystorm gave a hint how to paint an underlying colour before applying the transparent feature.

I thought about using an alias for opacity for a moment. It's a rapid fix. You will find below a comparison between current opacity and 0.5 as provided in the former issue:

https://www.openstreetmap.org/way/343862313
marker-opacity: 0.33;

marker-opacity: 0.5;

https://www.openstreetmap.org/node/4078433504
marker-opacity: 0.33;

marker-opacity: 0.5;

[giggls]

Hm, differences in my case:
marker-opacity: 0.5;

marker-opacity: 0.33;

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

I am a bit surprised about double standards here. My pull request about rendering different types of campsites in a different way got rejected as beeing "too specific for a general purpose map".
But what else is this one then?

https://github.com/gravitystorm/openstreetmap-carto/pull/2770

[kocio-pl]

This one is about more consistent rendering of private objects (we already did it for parking and playground). Different campsites are also acceptable for me, but IIRC icons were not aligned to our guidelines (bigger than 14 px).

[giggls]

OT: I consider it impossible to squeeze a caravan and tent icon into recognizable 14x14 size icons. Thus I might have misinterpreted the reason my patch got rejected.

[kocio-pl]

I remember different reasons, it was not only me expressing my view and I don't remember who closed it eventually, so you might be right.

[Tomasz-W]

@jragusa Can you provide more test renderings with private POIs with 0.5 opacity?

[jragusa]

Yes, I suppose with different background.

If someone has some suggestions for locations, please feel free.

[polarbearing]

Can we test fixed, light colour values as well, to compare that with opacity?

[jragusa]

@polarbearing what do you mean by light colour value ? I can made comparisons with 0.33 and 0.5 opacity.

[polarbearing]

When I measure the leisure-green icon I get #0C8416, then with private-opaque 0.5 on the typical background, I get #99D49E, i.e. a very bright green.

I propose to test fixed values, i.e. non-private ->#0C8416 and private -> #99D49E, instead of opacity. This would avoid any colour-changing of the transparent icon at the boundary of an object.

The brighter value could also be derived from the regular one with a function, e.g. the current leisure green is calculated: @leisure-green: darken(@park, 60%);, if there is a darken function there probably is a brighten function.

[jeisenbe]

It’s lighten(@park, 5%) for example.

The percentages are based on 0 to 100%, not relative to the original color,
so you’ll need to use a different percentage for darker and lighter colors
unfortunately. You can lighten a dark color like man-made-icon by 50%, but
not a light one like park - it will end up white.

On Wed, Jan 9, 2019 at 8:38 AM polarbearing [e-mail]
wrote:

When I measure the leisure-green I get #0C8416, then with private-opaque
0.5 on the typical background, I get #99D49E, i.e. a very bright green.

I propose to test fixed values, i.e. non-privat -> #0C8416 and private ->

99D49E, instead of opacity. This would avoid any colour-changing of the

transparent icon at the boundary of an object.

The brighter value could also be derived from the regular one with a
function, e.g. the current leisure green is calculated: @leisure-green:
darken(@park, 60%);, if there is a darken function there probably is a
brighten function.

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

[polarbearing]

Thanks for investigating the lighten function. As fine tuning per value would be required anyway, we could used the fixed ones. I wonder if it really helps us to have calculated colours in the definition block like the 60% darker park. It might be easier to have numeric ones there as well.

[Tomasz-W]

Shouldn't it be something like:

marker-fill: lighten(@<icon key name>, 50%);

for all private icons then?

[polarbearing]

Yes.
Though as I understand @jeisenbe we might need different percentages for different colours.
Thus it might be easier to maintain just two numeric hex values, each.

[meased]

Here is park background with amenity brown text and amenity brown text lightened 50%:

If you lighten brown you just get orange. Dimming is mixing the foreground color with the background color, you have to have knowledge of the background, or you have to use opacity.

[polarbearing]

And the mixing is exactly what we should _avoid_, to prevent the effect in the top post.
If algorithmic lightening does not work, we'd need handpicked values, e.g.

@amenity-brown: #734a08 -> private #B7A38A
@leisure-green: #0C8416 -> private #99D49E
@transportation-icon: #0092da -> private #9FCFE7

(Probably the lightened amenity brown just thinned the coffee, while I was putting more milk in it)

[jeisenbe]

An option that might work for all colors would be to use mix(@color-name, @land-color, 50%);
On Thu, Jan 10, 2019 at 8:21 AM polarbearing [e-mail]
wrote:

And the mixing is exactly what we should avoid, to prevent the effect
in the top post.
If algorithmic lightening does not work, we'd need handpicked values, e.g.

@amenity-brown: #734a08 -> private #B7A38A
@leisure-green: #0C8416 -> private #99D49E
@transportation-icon: #0092da -> private #9FCFE7

(Probably the lightened amenity brown just thinned the coffee, while I was
putting more milk in 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/3589#issuecomment-452880520,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AoxshMFpiqGBpW-LwtDuUrRioQAwBTKzks5vBmN1gaJpZM4Zfmtd
.

[jeisenbe]

Here's an examples where I've changed opacity to mix(@color-name,@land-color, 50%);

Current master (uses opacity)

Mix

EG changes:

-      marker-opacity: 0.33;
+      marker-fill: mix(@leisure-green, @land-color, 50%);

and

-          text-opacity: 0.33;
+          text-fill: mix(@leisure-green, @land-color, 50%);

[polarbearing]

Thanks. Would be interesting to see what happens if the icon is on the edge of two landfills.

As for the mix, the result is a solid colour, so what is the advantage over having the colour defined numerically? Would it have a performance impact?

[jeisenbe]

As for the mix, the result is a solid colour, so what is the advantage over having the colour defined numerically

Easier to adapt the style to use different colors, and to modify the style
in the future. I suppose this is the same reason we often use
darken(@color, 10%) for text and outline colors, rather than defining
each subsidiary color independently.
On Thu, Jan 10, 2019 at 8:29 PM polarbearing [e-mail]
wrote:

Thanks. Would be interesting to see what happens if the icon is on the
edge of two landfills.

[jeisenbe]

Here's another test with the icons straddling two different background colors:

Current rendering

With change to mix(@<color-name>, @land-color, 50%)

The 50% mix doesn't work for amenity-brown on major buildings (the dark brown background), but the opacity version isn't very visible either. Probably it could be adjusted.

[Tomasz-W]

Definetely 'mix' version works better. I wouldn't worry about major buildings, because private POIs inside stations/ churches are propably very rare thing.

[jragusa]

I was trying to find candidate areas for rendering but the method of @jeisenbe saves time. We should book a planet (or create a new one...) just to test renderings ;)

Otherwise I'm following @Tomasz-W about mix color.

@jeisenbe are you sure about the rendering of the private label of playground and picnic table ? They look very strong.

[jeisenbe]

are you sure about the rendering of the private label of playground and picnic table ? They look very strong.

No, I'm not sure about those. I just used the same code for all of these examples. As with the brown icons, it would need tuning. Perhaps 40% or 60% would work better?

I hope that it can be improved and perhaps you could do a PR?

[jeisenbe]

I've come back to this issue.

The main problem is that major buildings are very dark. Even some of the standard icons are rather low contrast with the major-building color (eg gastronomy orange, amenity-brown), which limits how much lighter the private icons can become. This has also been mentioned as an issue in #3071 "A main entrance does not stand out well if the building is major" and perhaps somewhere else.

So I'm submitting a PR to adjust the major building color first:

65% mix with land-color, with current major buildings color (and several other landcover examples):

65% mix with land-color, after major-buildings color lightened (to 10% darker than @building rather than 20% darker; outlineline is 15% rather than 25%)

[Adamant36]

It will also shade out toilets tagged with random access tags, not just private. There was one I came across last night that was tagged as access=public and was shaded out. So that needs to be looked into.
https://www.openstreetmap.org/#map=19/39.94783/-122.20094

[jeisenbe]

Good point. I agree that it would be better to only change those marked
access=no or =private etc.

It will also shade out toilets tagged with random access tags, not just

private. There was one I came across last-night that was tagged as
access=public and was shaded out. So that needs to be looked into.

[jragusa]

Please note that access=public is not listed on the wiki page. According to the wiki, access=yes is the correct scheme.
Otherwise, restricting to access=no or access=private is the better option to avoid weird behaviour.

[Adamant36]

Please note that access=public is not listed on the wiki page. According to the wiki, access=yes is the correct scheme.

I'm aware that its not a "proper" tag, but either way there shouldn't be conditional rendering that's suppose to be for a specific thing being shown on random tags. It could access=elephant. Its still not in the range of access=private. Which is the what the lightened rendering is suppose to show.

[HolgerJeromin]

Fyi
access=public is/was a special tag which is defined "toilet only" to make the access clear. It was (is?) included in josm preset, so it should probably supported.

[Adamant36]

Interesting. I wasn't aware of that. My bad.