buildings on amenity=school not distinguishable at zoom <= 17

[joshinils]

on zoomleel <=17: https://www.cyclosm.org/#map=17/52.63799/13.28903/cyclosm
the buildings on the school grounds are not distinguishable.

at zoom >=18: https://www.cyclosm.org/#map=18/52.63839/13.28812/cyclosm
they are, because of the outline.

seems the colours are too close for my monitors without the building outlines:

landuse=education uses another colour from amenity=school;
building: #e4dfdb
landuse=education: #ece3da
amenity=school: #e0e0e0

I can distinguish buildings on landuse=education

[Phyks]

Same for industrial areas https://www.cyclosm.org/#map=16/48.5913/2.3021/cyclosm

[quasart]

We talked about adding contour in #411

Otherwise we could change these areas colors (to something more yellow ?)

[Florimondable]

May be lighter grey ?
Yellow will attrack the eye for something minor.

[rkflx]

From Contributing.md:

We are currently lacking expertise on (among many subjects) icon designs and color choices to enhance the readability of the map.

Let's hope this offer is still valid, so I'll try to give it a shot.

I've been using CyclOSM for a while (even before it was as widely integrated in websites as it is now), and it has been a great experience so far. Still, I'm regularly stumbling over the exact issue mentioned here (not only for schools, but many other categories too), i.e. large areas of seemingly indistinguishable colors, where only after zooming in it becomes clear due to the outlines appearing that there are indeed buildings I am looking at.

This is caused by insufficient contrast between colors (ref. contrast checking website used in the webdesign and graphics communities). In short, contrasting colors can have different functions and come in differing shapes: From too much contrast (e.g. beaming white text on pure black background almost hurts) over various functional levels of color contrasts employed in color palette definitions (e.g. GNOME's Tango palette, Bootstrap's palette, branding palette of companies) to unusable contrasts (where users cannot quite tell if there is something or not, and get irritated – note this is about contrasts, not about continuous color gradients). Unfortunately, I would categorize the issue at hand as belonging to the latter one.

To solve this by changing visuals, we must first define the functional role of the color contrast in question. Relevant quote:

I mean, building is not very important for a cycling map.

It is true that buildings are not really needed while cycling, however they are somewhat important when orienting oneself on the map while planning a ride. They should be visible (which they are clearly not in some cases currently), but should not take away too much attention from road infrastructure and cycling networks. Fortunately, buildings and roads are almost always separated on the map, which gives us a huge head start.

As far as I can tell the balancing of area colors (including buildings) with other colors (e.g. roads) is already quite good, so there are no big changes needed there. The only problem is contrast between areas of same importance, e.g. buildings and school yards. If we increased contrast between buildings and school yards, we would immediately risk throwing off the balancing vs. the more important features. Also, it is almost impossible to solve this for all possible combinations at the same time, because there are many more examples beyond buildings and school yards.

Luckily for us, the human brain can be tricked: By using an additional third color with enough contrast to both the first and the second original color, we can create a situation which seems to have pleasant contrasts overall. To give you an example, here is a patch sitting in my list of commits scheduled for upstreaming to BRouter-Web (final look will be different with more changes implemented but not shown in the screenshot):

Before:

After:

As you can see, the contrast problem is solved by simply adding a very thin and light gray line. The look is more refined, without changing the overall balance of importance vs. the map.

Another example can be seen right here on GitHub, where the tab bar at the top uses a duo-tone color scheme, but needs a little help from a tiny contrasting border. Try removing the border in your browser's dev tools to see what difference it makes.

I would like to see something similar implemented in CyclOSM too (with the actual width and color/opacity up for discussion), as proposed here:

• Added very thin contour around building polygons in zooms 16/17

Will using outlines for buildings have any side effects? Certainly it might look a bit different at first (every change does, until we get used to it), but I would not expect any negative outcome. This strategy seems to work perfectly fine for other map styles on https://osm.org over a wide range of zoom levels.

I'm aware this proposal has been dismissed before, but I would suggest to look at it again to reconsider if you would be willing to change your mind.

Not ok, what issue does it solve ?

Hopefully, this has become more clear now. It does address (widespread, at least in my area) issues, while not creating new ones. I'm happy to look into any further doubts and concerns to see how they might be solvable. Just let me know.

With that, thanks for reading and happy hacking.

[Florimondable]

Thank you for very much for this feedback.
My main concern about adding countour line of buildings at Z16-17 is that we used to have it at the begining, but I removed it in order to make the map more simple.
That’s why I tend to think it’s better to work more on the landuse colors than on the contour lines. There are not that much of landuse colors in CyclOSM, so I think the work can be done quickly.

[quasart]

If I understand Rkflx well, the added contour should be lighter than the one you removed: it’s a trick to make low contrast visible without overloading general aspect

[joshinils]

the contour colour could be dependent on the background colour, meaning, if the building is atop a problematic colour then it could get an outline tailored for that background.
this could mean a lot of manual testing, or rather with a suite of test buildings and areas as a test for the renderer with all possible combinations (and partial overlaps).

[Phyks]

Thanks a lot for the much detailed feebdack @rkflx. Such inputs on design is indeed more than welcome!

the contour colour could be dependent on the background colour, meaning, if the building is atop a problematic colour then it could get an outline tailored for that background.

This is sadly not possible with Mapnik styles, even more when we are thinking in serving tiles globally and in near realtime :/

[rkflx]

Such inputs on design is indeed more than welcome!

Thanks! I wish I had more time to actually play around and provide more concrete proposals. So far I'm only adding lots of ideas to my ever-growing list of nice-to-have things...

Maybe as a general hint (which I'm sure you are already somewhat following): Good design is not so much about re-inventing the wheel, but having an overall vision and then copying the best ideas from everywhere to reach it. For example the standard style on https://osm.org has become quite good nowadays. When comparing it side-by-side with CyclOSM in specific situations (e.g. the random topic of the day might by "big city on low zoom", "small village surrounded by nature on high zoom", or "buildings vs. landuse") I often find inspirational solutions regarding color palette choice, contrast, feature balance, typography, labeling etc. I wish CyclOSM had too.

Anyway, I mainly took the plunge to comment here because this topic came up again after #411 last year, still unresolved. IMO the PR looked good enough, so I wanted to provide some encouragement to just go ahead with it for now and maybe iterate on it later.

My main concern about adding countour line of buildings at Z16-17 is that we used to have it at the begining, but I removed it in order to make the map more simple.

With very subtle contrasting borders I suspect it might even be possible to reduce direct contrast between colors used for areas compared to the current state, which might be a net win. Why limit the choice of tools at your disposal...

should be lighter than the one you removed

Exactly. Maybe splitting that out into a separate PR would allow comparing old and new outlines, tweaking them to alleviate any remaining concerns?

the contour colour could be dependent on the background colour

This is sadly not possible with Mapnik styles

If using opacity was possible for areas or lines, this would also be a kind of context-dependent color, but alas not that easy to handle either.

That’s why I tend to think it’s better to work more on the landuse colors

One more thought: It would be easier to find help if there was an example to play around with, e.g. an SVG file with renderings of all possible combinations of buildings and landuse, including some of the surroundings for visual context. (While you and I can just run projects in a container, other potential contributors might be more comfortable in Inkscape.)

You could then take this file (or an appropriately tagged GitHub issue) and ask for ideas where actual experts (which I am clearly not) meet. Maybe there is a graphics design related StackExchange community (there is ;) or a subreddit, or publish a call for contributors in OSM Weekly News?

than on the contour lines.

You probably meant the building outlines? FWIW, I like how the approach in #567 solves the issues the new (mountain) contour lines introduced for me as well.

---

I'll now have to go back working on my BRouter-Web PR, but I'll continue following closely for sure...