Admin boundaries color is too prominent and conflicts with other potential uses

[kocio-pl]

Related to #3526.

Current colors of admin borders are too bright, especially on low zoom levels. On low zoom they were gray once, but they were changed to violet for consistency with the color on all the other zoom levels.

Possible solutions of this problem include using gray this way or another, which results in darker colors:

1. German fork uses gray with a green tint (#50705a)
2. @imagico fork uses very similar mix of gray with a green tint (#51785e) on the land
3. I was testing plain gray (#555555) in #2695

Probably all of them are better than current color, but I think the best solution is to use gray with violet tint (probably 50% mix of #555555 and current bright violet #ac46ac). It works quite nice - looks grayish on low zoom and more like violet on high zoom levels without any tuning. It allows to shift road colors like in Christoph fork (effectively adding one more - starting with reddish violet for motorways), while not using any green for the admin borders.

This is the final effect of violet tint for country borders, including road colors shift:

This is the road colors shift alone (described in this blog post: http://blog.imagico.de/more-new-colors/ ) - the relevant part is only color shift from motorway to tertiary, the rest of the tuning is outside the scope of this issue:

Of course we can also use green tint for admin borders, but green is better associated with (semi-)natural objects, in particular it's close to the natural reserve rendering with green labels along the boundary:

German green tint

current bright violet

violet tint

Violet tint works good on all the zoom levels, even with roads color shift and expanded natural areas to z5+ (see #3458):

high

medium

low

[Tomasz-W]

@kocio-pl Thanks of raising this issue again! Bright violet borders are one of the most 'design-outdated' things in OSM-Carto for me.

Can you try with:

• 75% mix of plain grey + current violet -> #6B516B
• 75% mix of plain gray + leisure-green -> #436145

?

[jeisenbe]

If we use gray-violet for borders and violet for motorways, this may look strange on the lower zoom levels where only motorways and boundaries are now shown, so if that is the plan I would recommend testing the new motorway color and border color together.

If we keep the current motorway color or another shade of red, then there will be no problem. But I believe these changes are meant to go together.

[Tomasz-W]

I don't like violet motorways idea at all, I think we should stick with yellow-orange-red palette for higher class roads.

[kocio-pl]

Could you tell more what problem do you see with violet motorways? For me it is a proper solution of old issue with tertiary being less visible - see #1974, we gave up because we lacked the colors, but violet extends this scheme nicely IMO.

These problems are hard because they depend on each other to some extent. I try to test borders with possible changes like showing natural areas on z5+ and violet motorways to avoid clashes, as @jeisenbe just said, but first one is still waiting for merging and the second one is not even ported from the fork into OSM Carto PR yet.

[jeisenbe]

If the motorways are violet and the borders are gray-violet, then only violet lines will be shown at low zoom levels. Blue water plus violet lines makes for an odd-looking map.

Now that some landcover will be rendered this problem will be less severe, but it's still worth considering. If the border are green-gray instead of violet then this would be less of a problem.

I'm also not sure that tertiary roads need to be stronger.

From what I've seen, Germany maps tend to show these roads with a color, but in the USA it's unusual to use more than 3 colors for all roads from motorways to residential on paper maps (and online). Perhaps this is because our road classification system is not nearly so detailed. This is also an issue in many developing countries, which tend to lack detailed road classification levels.

[Tomasz-W]

I don't like idea of violet highways because:

• it may cause visual conflicts with borders, even after changing their colour to a mix of violet + grey
• we should avoid adding new colours to a road palette to keep it simple, I would stay with white-yellow-oragne-red range, as it works for most of other maps
• as for graphic designer, in my opinion it would make map more crappy-design-like (examples here)

Anyway, I'm waiting for further border colour change tests (see https://github.com/gravitystorm/openstreetmap-carto/issues/3489#issuecomment-435298756), espessialy after recent adding landcoverage to mid-zooms :)

[kocio-pl]

• 75% mix of plain grey + current violet -> #6B516B

With bold country names

https://www.openstreetmap.org/#map=6/51.849/20.116

https://www.openstreetmap.org/#map=16/49.5738/22.6873

https://www.openstreetmap.org/#map=11/54.3842/19.7208

https://www.openstreetmap.org/#map=12/52.2356/20.8412

https://www.openstreetmap.org/#map=19/52.25929/20.99742

https://www.openstreetmap.org/#map=18/52.23921/21.03554

[kocio-pl]

• 75% mix of plain gray + leisure-green -> #436145

With bold country names

https://www.openstreetmap.org/#map=6/51.849/20.116

https://www.openstreetmap.org/#map=17/49.57435/22.68591

https://www.openstreetmap.org/#map=11/54.3842/19.7208

https://www.openstreetmap.org/#map=12/52.2356/20.8412

https://www.openstreetmap.org/#map=19/52.25929/20.99742

https://www.openstreetmap.org/#map=18/52.23921/21.03554

[kocio-pl]

It looks to me that every shade of green can be sometimes mistaken for a natural reserve or some other green. On low zoom the lines look not too nice on the water and everywhere they look like blurred, on the highest zoom the lines are OK, but labels get ugly.

Violet tint is crisp, looks good on the water, it is distinct from all the natural greens and on high zoom it's easy to get that labels are violet, even when the line looks like gray. On low zoom the lines look gray (OK), but state labels (maybe country labels too? I'm not sure) might be a bit more violet to make them more distinct from cities.

Europe on z4 with 25% violet tint and bold country labels looks more or less like gray was used for admins:

[jeisenbe]

One other option to try would be a mix of dark red with gray. This is used on classroom maps in the USA, and also here in Indonesia for national maps, to show provincial borders. It would look similar to the purple-gray mix, but maybe it would be better on rivers and forests?

Eg #72323f - Lch(30,30,11)

[kocio-pl]

#72323f with bold country names - I would take the labels from it (except country labels), but country borders are too strong on low zoom and don't look nice on the water

https://www.openstreetmap.org/#map=6/51.849/20.116

https://www.openstreetmap.org/#map=17/49.57435/22.68591

https://www.openstreetmap.org/#map=11/54.3842/19.7208

https://www.openstreetmap.org/#map=12/52.2356/20.8412

https://www.openstreetmap.org/#map=19/52.25929/20.99742

https://www.openstreetmap.org/#map=18/52.23921/21.03554

[sommerluk]

About typography: Currently all country and city, town, village... labeld are “regular” fonts. Making country labels heavier (like bold here) seems a good idea.

Note than the current Noto version (the font face we are using) has not only “regular” and “bold” (almost all living scripts) but now also more font weights like “semi bold”, “black” and “light” for most scripts.

[kocio-pl]

How do you think we could use them? Maybe semi bold would be good for capitals?

[kocio-pl]

Also, how would you improve rendering country labels? I just reused this commit in my tests: https://github.com/vholten/openstreetmap-carto/commit/aeda57ea5caf608b7df247affcbf081837533134

[Tomasz-W]

BTW. I think that high-zoom admin labels should be set darker, e.g. names of certain neighbouhoods inside this disctrict are lost in this well-mapped-area jungle: https://www.openstreetmap.org//#map=15/52.3867/16.9535

[kocio-pl]

Do you have any proposition? I suspect that in such a dense place it will be hard to make everything visible.

[sommerluk]

Yes, semi-bold might work for capitals.

In the comit you mentioned, the unique occurence of text-character-spacing in our style is removed. This is a good idea anyway, because it does not work consistently anyway https://blog.mapbox.com/letter-spacing-in-a-multilingual-world-ceeed5067beb

[kocio-pl]

Is there some straight way to create list of semi bold fonts, similar to:

https://github.com/gravitystorm/openstreetmap-carto/blob/999fad8d99d4da0da866a7f2890a276d4246c859/fonts.mss#L140-L146

(etc.) ?

[Tomasz-W]

Do you have any proposition? I suspect that in such a dense place it will be hard to make everything visible.

Just setting @placenames-light colour in placenames.mss (currently #777777) to some darker shade, e.g. #555555

[kocio-pl]

Placenames are about rendering cities, not borders. Borders are defined in https://github.com/gravitystorm/openstreetmap-carto/blob/master/admin.mss and I test "75% mix of plain grey + current violet -> #6B516B" there.

[kocio-pl]

Sorry, wrong button...

[kocio-pl]

@sommerluk I just made a clone of bold-fonts definition and Mapnik gave me warnings that it can't find these font faces:

"Noto Sans SemiBold", "Noto Sans CJK JP SemiBold", "Noto Sans Gujarati UI SemiBold", "Noto Sans Gurmukhi UI SemiBold", "Noto Sans Kannada UI SemiBold", "Noto Sans Malayalam UI SemiBold", "Noto Sans Oriya UI SemiBold", "Noto Sans Telugu UI SemiBold", "Noto Sans Thaana SemiBold", "Noto Sans Tibetan SemiBold", "Noto Naskh Arabic UI SemiBold", "DejaVu Sans SemiBold",

but no warning has been given about the rest, namely:

"Noto Sans Armenian SemiBold", "Noto Sans Bengali UI SemiBold", "Noto Sans Cham SemiBold", "Noto Sans Cherokee SemiBold", "Noto Sans Devanagari UI SemiBold", "Noto Sans Ethiopic SemiBold", "Noto Sans Georgian SemiBold", "Noto Sans Hebrew SemiBold", "Noto Sans Khmer UI SemiBold", "Noto Sans Lao UI SemiBold", "Noto Sans Myanmar UI SemiBold", "Noto Sans Sinhala UI SemiBold", "Noto Sans Sinhala SemiBold", "Noto Sans Symbols SemiBold", "Noto Sans Tamil UI SemiBold", "Noto Sans Thai UI SemiBold", "Noto Sans Arabic UI SemiBold",

It's a bit weird for me, because at the Noto website ( https://www.google.com/get/noto/#sans-lgc ) it's written that SemiBold exists. Another strange thing is that even if I have used book-fonts fallback, the capital is heavier (however I don't know if it's bold or semi-bold):

Could you help me with that? Respective code branch is here:

https://github.com/kocio-pl/openstreetmap-carto/tree/borders-violet-tint

[kocio-pl]

Here is the sample text showing visual difference between Noto Sans SemiBold and Bold (simple screenshot from the web page with SemiBold Italic between them):

[sommerluk]

I do not know what makes Warszawa bold either.

The Noto website does not claim to provide semibold for all scripts it supports, but only for most of them. So where you see an error message, there is simply a lack of a corresponding font file.

At Noto’s Github repository you can find a more up-to-date version of the font with more semibold support. (Folder phaseIII_only) I’m using openSuse which has good font support. But as far as I know, Ubuntu does not package the complete Noto font, but only part of it.

[jeisenbe]

Are you considering doing some more tests with #6B516B or a similar color?

[jeisenbe]

I've updated the title to more clearly define the problem:

The current color for @admin-boundaries, #ac46ac is Lch(47,69,327). This is a high-chroma color, and the hue 327 is bright violet or purple, which is a visually strong hue. While admin_level=2 boundaries are real, on-the-ground features with high importance for the general map users, this color is also used for admin_level=3 to 6 features which are only moderately useful, to define the name of the area, but also admin_level=7 to 10 features with have quite low importance.

It would be better to emphasize admin_level=2 boundaries (and to some extent admin_level=3 and 4) in other ways, while using a less saturated (lower chroma) color for the other boundaries.

This hue is also blocking the use of purple, violet, magenta and blue-purple for other linear features, such as paths, cycleways, or motorways.

Changing the hue to a low-saturated red, green, blue-green or blue-purple, or perhaps orange-brown, would allow us to use violet or purple or magenta for motorways and cycleways, which prevents using blue in a way that could be confused with waterways (The current cycleway color is "blue").

Using green or blue-green or red would also mix better with most type of landcover colors: the admin boundaries are semi-transparent, which leads to mixing the violet color with underlying landcover colors. Purple does not mix well with green, yellow or orange.

In the past we have been limited in admin boundaries color selection by the need to look non-terrible when rendered over water, but now that we are using water poygons, it will be possible to use a different color over water (e.g. a mix of @admin-boundaries + @water-color) only, so this is no longer a constraint.

[jeisenbe]

I've been re-designing the patterns for admin_level=2 to 10, and it makes sense to reconsider the color as well.

The simplest change is to keep the same hue but reduce the saturation. However, this only solves part of this issue, and would not make it easier to use magenta for motorways or violet for cycleways:

Current z9 (#ac46ac - Lch(47,65,327))

Desaturated violet z9 (#8d618b; -- Lch(47,30,327))

• Also showing admin_level=5 now

Current z10

Desaturated violet z10

Current z12

Desaturated violet z12

Current z14

Desaturated violet z14

Current z15

Desaturated violet z15

Actually, it's possible that this is low chroma enough that we could use higher-chroma violet/purple/mageneta for cycleways and motorways, but it would need testing.

[jeisenbe]

These borders are magenta #ac5271 Lch(47,40,360) - the hue is close to the current motorway color, so using this option might require adjusting the roadway colors too.

z9 #ac5271

z10 #ac5271

z13 #ac5271

z14 #ac5271

z15 #ac5271

Would admin_level=3 at z9 to z8 be confused with motorways? I don't think so, but it should be considered.

[jeisenbe]

This desaturated green-gray color (#51785e - Lch(47,22,153)) was used by @imagico for the alt-colors style. It is just a bit darker and higher chroma than the color #50705a used for borders in the openstreetmap.de style.

The main concern would be how it looks with protected_area / national_park borders - but those might be changed if needed.

z9 #51785e

z10 #51785e

z13 #51785e

z14 #51785e

z15 #51785e

The access=no paths and bridleways are somewhat similar, but not too much of a problem

[jeisenbe]

This color, #666ba6 // Lch(47,35,292), has a hue close to violet, but it looks more like navy blue when saturated, but grayish when desaturated. However, it can be distinguished from gray, yet does not look similar to waterways or other water features (which have a hue closer to 225).

z9 #666ba6

z10 #666ba6

z13 #666ba6

z14 #666ba6

z15 #666ba6

Changing cycleways to purple or another color would help here.

I also tested a less saturated version, #6b6c95 // Lch(47,24,292) - but that was too gray.

And #4372a8 // Lch(47,30,272) blue-gray is too close to water color.

[jeisenbe]

Another option is a green with some blue, for example #037d79 - Lch(47,30,192)

z9 #037d79

z10 #037d79

z13 #037d79

z14 #037d79

z15 #037d79

This color won't be confused with water, and it's farther from the natural greens or park green than #51785e (above).

[jeisenbe]

Finally, here's a less saturated and less blue version of the previous: #3c7a72 // Lch(47,22,185)

z9 #3c7a72

z10 #3c7a72

z13 #3c7a72

z14 #3c7a72

z15 #3c7a72

This is again close to the alt-colors and german styles, though with more blue hue.

[imagico]

The darker centerline looks fairly good - but it would make most sense in combination with weakening the broader background line. And it would also be worth trying to reduce the number of background line signatures then, i.e. differentiate admin_level 3 and 4 only by centerline.

I think #666ba6 will probably collide with the runway/taxiway color.

[jeisenbe]

The darker centerline looks fairly good - but it would make most sense in combination with weakening the broader background line.

I thought so too, but when I tried using line-opacity: 0.3 for the outer line and 0.8 for the inner, this led to the outer line disappearing over dark surfaces. Apparently the comp-op: darken opperation is affected by the opacity if it is not applied to the whole layer.

This could probably be solved by rendering the centerline in an entirely separate layer, which would also allow using a dark color instead of black. But I'm not sure if the small improvement is worth the worse performance and complexity related to increasing the number of rendering layers.

(Rendering this in 2x or 3x resolution looks much better, and would provide more options for improvements. I would have made the minor boundaries thinner, but it doesn't work at a standard resolution)

It would also be worth trying to reduce the number of background line signatures then, i.e. differentiate admin_level 3 and 4 only by centerline.

The centerline is not as easy to see, due to the issues mentioned above, so I would be relucant to rely on it entirely. That's why I made the segments longer for admin_level=4 compared to 3. If the centerline pattern for admin_level=3 is too busy, I could simplify this to just dashes. But I like how the mixed "dots" and "dashes" suggest this is an administrative boundary rather than a real feature, and how they help tie admin_level=4 to admin_level=5, 6 etc.

#666ba6 will probably collide with the runway/taxiway color

Hmm, runways and taxiways almost never are configured in a way which could be confused with admin boundaries, but it's worth checking. I don't like the current runway/taxiway rendering, but that would need to be considered separately. (If the borders are changed, it could be made a bit more violet, perhaps? Also a casing or centerline would be helpful).

More significantly, #666ba6 is still a little too similar to a water feature at low zoom levels where all the lines are thin. Again, this would not be such a problem with a high-resolution rendering, but when using 1 pixel or thinner lines, it takes a second to distinguish the borders from the rivers at z8 to z10:

z8 #666ba6

z10 #666ba6

z13 - here's a admin_level=6 border along the runway

This is also something of a problem with the blue-green color, #037d79:

z8 #037d79

z10 #037d79

z13 #037d79

Also #3c7a72 z8

z10

z13

Of course, making the admin-boundaries less visually prominent is bound to make them harder to distinguish, but a clear difference from rivers and major roads is important.

[jeisenbe]

The magenta color above, #ac5271 - Lch(47,40,360), is still quite prominent. I tried reducing the chroma to 22 to get #936270 // Lch(47,22,360):

z15 #936270

z14

z13

z12

z10

z9

z8 #936270

[imagico]

I would not expect global comp-op to work together with line-opacity. But you should be able to use different attachments for the different line types.

#666ba6 admin unit labels would definitely collide with airport labels at z11+:

https://www.openstreetmap.org/#map=11/62.0764/-7.2297

[jeisenbe]

Since #666ba6 is too blue, here's #7d6696 -- Lch(47,30,310) - that's a little less red than the current bright violet boundaries, but not as blue.

z8 #7d6696Lch(47,30,310)

z9 #7d6696

z12 #7d6696

z13 #7d6696

z14 #7d6696

z15 #7d6696

Compare to water features at z8: z8 #7d6696 - Papua, Indonesia

z10 #7d6696

z13 #7d6696

[MattBlissett]

I tried some changes in #1248 a while back, but abandoned my effort.

I like the ·—·—· patterns, but how about increasing the spaces? A line pattern like——   ——   —— seems more appropriate for an "imaginary" feature like a boundary, adding dots but keeping plenty of space for less-important boundaries.

This would allow either reducing the thickness and/or increasing the saturation at low zooms.

[jragusa]

Have you tried a more saturated colour for the centerline instead of black ? Here in Swiss map :

[imagico]

Some remarks on the swisstopo maps - they only recently started using purple boundaries - previously they were green and they used to use those primarily at the small scales while moving to black line patterns at the larger scales - see for example https://s.geo.admin.ch/885b8c6174.

[jeisenbe]

But you should be able to use different attachments for the different line types.

Thank you, this worked, though it took some testing. The opacity and comp-op have to be in the right order.

How about increasing the spaces? A line pattern like —— —— —— seems more appropriate for an "imaginary" feature like a boundary, adding dots but keeping plenty of space for less-important boundaries. ...

See the test images from Luxembourg in the PR #4100 - the borders in many countries are very curvy, so if the gaps are too long it becomes difficult to visualy follow the line. Wide gaps only work at very high zoom levels.

... This would allow either reducing the thickness and/or increasing the saturation at low zooms.

Have you tried a more saturated colour for the centerline instead of black ?

As you guys suggested, the new rendering in the PR uses a higher-saturated centerline for the admin_level2, 3 and 4 features from z8 and higher. This looks more saturated and darker

Previously I didn't know how to do this - it requires using separate attachments for the wider and narrow lines (and I also used a third attachement for the other minor boundaries, so that they can be rendered behind the major ones).

It will still not be as nice as the Swiss map, which appears to be made by hand: that map renders the boundaries behind roads, which only works at zoom scales, and it is high resolution, while this rendering style needs to work at standard resolution, and at many different zoom levels.

[jeisenbe]

In PR #4100 there are new line widths, patterns and zoom levels, with a less saturated (lower chroma) version of the current boundaries color.

The other option, which is a bigger change, would be to switch to green, similar to the alt-colors styles and openstreetmap.de.

Here are tests with green-gray #4c795c Lch(47,25,154) as the main color

    @admin-boundaries: #4c795c; // Lch(47,25,154)
    @admin-boundaries-narrow: #366e4d; // Lch(42,30,154)
    @admin-boundaries-wide: #6c9179; // Lch(57,20,154)

This is similar to the alt-colors style, but chroma is 3 higher

z9 Luxembourg

z10 Luxembourg

z11 Luxembourg

z12 Luxembourg

z13 Luxembourg

z14 Luxembourg

Compared to the darker purple in PR #4100, the green boundaries are easier to see on orange, red and violet backgrounds (primary, trunk and motorway roads, commerical, industrial and retail landuse), but less obvious in woodland and other green, vegetated areas.

[jeisenbe]

I think that a green with a slightly higher chroma, similar to that used for the violet admin-boundaires in PR #4100, would work a little better:

    @admin-boundaries: #427b58; // Lch(47,30,154)
    @admin-boundaries-narrow: #2f6f4a; // Lch(42,35,154)
    @admin-boundaries-wide: #649375; // Lch(57,25,154)

Those are all 5 higher chroma than the previous test images.

My main concern is how gray-green admin boundaries will work with green protected_area (national_park, nature_reserve) boundaries, so I'm working on updating those as well, possibly using hues like @protected-area: #65870f - Lch(52,60,118) and @aboriginal: #a76f56 Lch(52,30,50) - both shifted to a lower hue number.

Test of @admin-boundaries #427b58 Lch(47,30,154) with current protected-areas

Luxembourg z11

z12a

z13a

z13b

z14b

z14c

So with the current wide, high chroma, low opacity protected-area lines there is not too much of a problem, but ideally I would like to use less opacity to reduce the color mixing, so that means using less chroma as well, and that could make the colors too close.

But if the protected-areas color is changed to yellow-green (#65870f - Lch(52,60,118)), then we can use thinner lines and less opacity without risk of confusion (though the aboriginal_lands color will also need to be shifted):

z11 - new green-yellow protected-area and gray-green admin

z12

z13

z14 - green-yellow protected-area and gray-green admin

[Tomasz-W]

From the ones proposed above, I'm considering #7d6696 as the best one.

I don't like current viotet because I was always considering it as one of the elements which lowers osm-carto design level in comparsion to other maps (it's making it more colorful than it's needed). Analyzing another options, too much blue admin boudaries can be mistaken as something refered to transport or water, and too much green admin boundaries can be mistaken as something refered to protection of green areas or recreation etc.

I hope that admin boundaries color will be changed soon :)

[jeisenbe]

See merged PR #4100

[kocio-pl]

It looks interesting to test more this new proposition. Could you compare yellow-green admin borders with light-brown aboriginal areas (especially when they are rendered without the filling)?

[pnorman]

I do not consider green a good colour for admin boundaries. We have to consider cartographic expectations and what people are used to. There are various colours used for admin boundaries, but green is not one I see commonly. In fact, I'm not sure I've ever seen it.

Green also has a well-established meaning in maps: some kind of natural area (e.g. forest) or a park which is a natural area.

[imagico]

A number of suggestions

• don't let yourself be guided too much by certain cultural expectations which are largely based on specific cartographic traditions which again often originate from certain technical constraints (limited set of colors in printing) or are based on a specific sparse color scheme used otherwise.
• avoid thinking of the problem in terms of what does not work but in terms of what works. This is a hard problem. Every decision - even the one to keep the status quo - will come with a number of drawbacks. The hope for a solution that will just fit with everything else is an illusion.
• formulate your priorities. Is showing nature reserves more significant than admin boundaries or is it the other way round? Do not adjust the high priority features to work well together with the low priority features.
• keep in mind that color is not the only means to differentiate different line types. #4100 has introduced a more distinct line style for most of the admin borders which means it will be more clearly readable without a color allowing identification as such. This idea could even be further emphasized if necessary.
• don't try to find a compromise between showing something and not showing something, between differentiating things and not differentiating things.