-
Notifications
You must be signed in to change notification settings - Fork 819
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Strange rendering of toilets in 4.18.0 #3589
Comments
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. |
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? |
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. |
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 |
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 https://www.openstreetmap.org/node/4078433504 |
Hm, differences in my case: 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". |
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). |
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. |
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. |
@jragusa Can you provide more test renderings with private POIs with 0.5 opacity? |
Yes, I suppose with different background. If someone has some suggestions for locations, please feel free. |
Can we test fixed, light colour values as well, to compare that with opacity? |
@polarbearing what do you mean by light colour value ? I can made comparisons with 0.33 and 0.5 opacity. |
When I measure the leisure-green icon I get I propose to test fixed values, i.e. non-private -> The brighter value could also be derived from the regular one with a function, e.g. the current leisure green is calculated: |
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 ***@***.***> 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:
***@***.***, 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
<#3589 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AoxshA8tvUE3S1sRvNg2KroyhX9fak_Qks5vBSwGgaJpZM4Zfmtd>
.
|
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. |
Shouldn't it be something like:
for all private icons then? |
Yes. |
And the mixing is exactly what we should avoid, to prevent the effect in the top post. @amenity-brown: (Probably the lightened amenity brown just thinned the coffee, while I was putting more milk in it) |
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 ***@***.***> 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
<#3589 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AoxshMFpiqGBpW-LwtDuUrRioQAwBTKzks5vBmN1gaJpZM4Zfmtd>
.
|
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? |
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 ***@***.***> wrote:
Thanks. Would be interesting to see what happens if the icon is on the
edge of two landfills.
|
Definetely 'mix' version works better. I wouldn't worry about major buildings, because private POIs inside stations/ churches are propably very rare thing. |
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. |
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? |
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 |
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. |
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.
|
Please note that |
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. |
Fyi |
Interesting. I wasn't aware of that. My bad. |
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.
The text was updated successfully, but these errors were encountered: