I mostly know the tag “colour” in my 3D renderers for building walls and roofs, but it is mostly used for material amenity and many others.
The tagging page in the wiki describes absolute values and name strings as W3C colour names. There are libraries to convert W3C strings to an absolute value. But many tagged colours are not included in W3C. A renderer can only ignore it and assume there is no tag and use a default colour.
Often it is just a light… or dark… prefix, not supported. We could handle that in the renderer by detecting the prefix and darken or lighten the base color. If “all” 2D/3D renderer do this, we could add it to the wiki page.
Some colours are so famous, we may add them to an exceptional allowed list (in the wiki)
Which editors check the values before uploading?
There are OSM tools (…), we could add a “challenge” to find and correct not supported colour values.
As a side output of renderer codes, we could have a checker to find, and even to correct values. Some are obvious like spelling errors, capital letters and even “wrong” languages. Others should be humanly checked.
We could do an automated edit for the obvious errors.
That’s based on the assumption that you’ll take OSM data and pass it directly to the renderer. In this case it make sense to look at taginfo to see what people have used for e.g. colour and between OSM and your renderer, change some of those to colours that your renderer can understand. This script (for an entirely different purpose) is something that does that - it uses “osm-tags-transform” (which takes the transformation definitions in lua).
Are there other renderer, really using some colour tagging?
All 3D rendere will do. So this may mostly be a question the maintainers of 3D code.
This topic should be relevant vor all this renderers, indirectly: The tag value string has to be checked somewhere on the way from the osm data base to the screen. It may happen, when vector tiles are generated.
A clean tagging base is always good. So this question is also for the editor groups.
And for all being interested: Do you agree with the points for the Wiki page?
Not really** - it doesn’t really engage with the use of these tags in OSM beyond 3d buildings. What colour would you say this was?
That’s not to say that a tidy-up of errant values wouldn’t be (a) possible and (b) a good idea, but there will be lots of ones that don’t fit the wiki page description.
I think the page has been cobbled together by mappers who use the key for a variety of purposes, not just buildings. For one thing, I vaguely recall that this guidance:
generic names should be preferred for non-specific colours, e.g. red instead of firebrick
comes from the world of public transportation route tagging, where there has been disagreement about how precisely to tag colors on color-coded routes. For example, a light rail operator may designate one line as Blue and the other Red, but on maps and displays they standardize on a more muted navy blue and Tuscan red, respectively. In 2021, I used Sophox to make this bubble chart of transit system colors demonstrating that the microcolorimetrists have definitively won that debate despite the wiki:
Fortunately, ref:colour=* still exists for those who want to record more consumer-friendly color names for guidance purposes.
Another niggling issue has been common color patterns, especially rainbows. After crossing:markings=* was approved, some mappers started tagging rainbow crosswalks as crossing:markings=rainbow (presuming that a rainbow can only appear as a series of straight parallel bars, unlike in nature), while others tagged colour=rainbow or crossing:markings:colour=rainbow. Some application graphics frameworks have built-in affordances for pattern colors, and CSS sort of does with extra syntaxes for gradients and the like, but none of this is part of the documented colour=* tagging scheme. Plenty of mappers now use a semicolon-delimited list for multicolored things, especially flag:colour=*, but there’s no clarity on how to interpret that.
[quote="SomeoneElse, post:4, topic:129467”] These are the documented uses of the tag in taginfo.
[/quote]
Thank you for the list. Mostly its tagging help, not an interpretation of the value. For the other, it will be an interesting investigation, how the tool reacts to odd values.
[quote] it doesn’t really engage[/quote] So it even more should be improved.
Yes. And: "There is an App for it” to scann the color and get a name and the value. If it is an odd color, I would use the numeric value.
If you look into 3D renderings, the colours are often too bright, because users just write “red” for a roof if it is dark red tiles. An On-The-Field Editor would measure the value and auto-insert it.
That does minimise wrong values. I like the ref:colour=* as it is just a string and will not interpreted to render something. I also like “rainbow”. It should be in the wiki in "list of exceptions”. (The “disagreement about how precisely” is not my topic, but a different one. )
Yes, the wiki is for ALL usage of colours, as it should be. And bad values will trouble all usage to. Also the transit map renderer. The wiki page does not need to offer a source code for converting ti RGB, but the mental tools for it, the known codes, and as I would like to append: the extension points / the exceptions (prefix, list)
[quote]A semicolon-delimited list[/quote] is common for OSM tagging, rendere should be prepared. A flag, tagged “green; white; red” would be rendered as an Italian one.
I like the OSM concept to be free to invent new tags and values. We should not block or force any colour values in editors. But give hints, if the value is not known, i. E. to use the English language. Otherwise, the colour could even be displayed in the edit dialogue. The rainbow crossings need to be hard-coded in the renderer. I would do it with pleasure.
skimming through the list on taginfo shows that serveral thousand possibly even reaching fife digits of entries can be corrected simply by translating the current german entry to ist english counterpart. I assume that you ignore the upper and lower case of the source language and output lower case only in the target language.
rot → red
weiß; weiss → white
braun → brown
regenbogen → rainbow
etc.
I would also support an automated edit for such a simple search and replace. And of course a lookup table like this should be made for other languages as well. Other cases that a bot can not or should not handle could be outsourced to Map Roulette.
As I understand it, it’s more nuanced than that. ref:colour=* is machine-readable too.
Each route network color-codes its routes independently, so the specific colors are relative to each other and can be counterintuitive when you compare across networks. For example, according to this interactive color palette, the Delhi Metro’s Green Line is branded with a teal color that’s distinct from the colors it uses for the Blue Line, but it’s almost identical to the color that BART uses for its Blue Line in the San Francisco area. In Grand Rapids, Michigan, the Silver Line is marked on maps by a green line with a white-on-green pictogram.
Of course, the name=* tags will clarify this situation to some extent, but applications also need something machine-readable to distinguish the intended color categories, for example to ensure proper contrast in dark mode. We actually have multiple color keys in use, which I tend to think of as:
name=* – This is called the Silver Line.
material=* – This line is so expensive because it runs silver-plated cars!
colour=* – Livery, station signage, and everything else that serves this line in the real world is painted green.
ref:colour=* – You wouldn’t recognize this as the Silver Line unless it has a green icon.
colour:ref=* – A railfan once brought a colorimeter onboard and thought it would be cute if Organic Maps would tell passengers to board the #43ad49 Line, but really it’s the Silver Line.
But in reality, each of these keys has gotten muddled in various ways, from name=* containing ASCII art to colour:ref=* containing Pantone numbers.
Do we need a tool for simple replaces? Just edit Overpass output and upload?
We should write a wiki page for automated edit.
And the final question: Who has got time and energy to do it?
Of course it is. But it may be only used organisational. Is there any place, it is used to really render that color on drawing or map?
Anyway, ALL colour taggings should have a valid value. So some automated/manual edit is the goal (after discussion and editing the Wiki page).
There is a general page that discusses what needs to happen for automated edits in general. That’s surely not needed for some of these - taginfo shows 100k “green” and 1.5k “Green”. Changing the latter into the former is just fixing an obvious typo.
Some suggested changes absolutely will need more discussion, as the wiki page suggests - if you were to suggest changing darkseagreen to dark_green you;d need to discuss it.
As for “technically how to change these”, if it’s “one obviously wrong value” I tend to use iD to look at the wider area, as often there are other things that need fixing there too (very much a manual process).
However, where it’s “just fixing an obvious typo” like (Green → green) on a number of them I tend to use taginfo to create an overpass query, divide that into small areas to avoid “world spanning changesets”, and use those overpass queries in JOSM to fetch in the data, edit it there (change only one tag value, making sure that what I have selected does not have “many” values) and write it out again.
The sRGB color profile doesn’t represent all of the perceptible color range, and translating real-world physical colors to screen colors is fraught, but your examples point to a more straightforward issue. transparent isn’t part of the colour=* tagging scheme since it isn’t a valid CSS named color, only part of the much broader color value syntax. If something is transparent, it’s more helpful to describe the material than merely its opacity.
If you’re referring to the tables on the colour=* page, these are just the most basic named colors for convenience. The full list is 147 colors long, but renderer support is uneven, so the advice is to use a more specific hexadecimal RGB triplet if visual precision is important enough for you to venture beyond the basic colors.
I like this “XKCD colour set”.
We could add it compatible as 2nd alternative if the “csscolorparser” returns a None. So I need a “xkcdcolorparser” in Rust; find it or do it, it’s a table more or less.
You may start a discussion in the Wiki page. I am curious, how the render maintainer and all users will response.
Taginfo and Overpass was easy. In Germany it found 64 Green. But what is the limit of a NOT world spanning changeset? Germany? Yes, in JOSM download help is that overpass import, for expert mode only. But no help how to activate expert mode. There is a hidden Help link in the start dialog to a web site were I found an almost hidden link to an Index, containing the expert mode help. View menu > Expert Mode was disabled! After some more odyssey in the Wiki, I went back and it was enabled.
Just easy
64 small blue dots got visible. I edited a small group of 3, uploaded and got:
The OSM server ‘https://api.openstreetmap.org/api/0.6/’ reported a bad request.
Error message(untranslated): Version is required when updating Node 11895050495 at line 3, column 81. May be because I don’t use the latest version? "You should update! Active version ‘19369’ should be updated! Stable version: 19396 Development version: 19396” What? Those are all the same! And there is no newer for macOS.
Anyway, such a manual edit of 1.5k “Green” is not, what I will do. Either there is a tool for it, or I may write one. Something like Street Complete or that other forgot. At last it is not only colours. My rendere struggles at many points, like a building with a not closed way or ways with the same node twice side by side. It is not a problem to scann all OSM for errors, and things like Green to green could be edited automatically.
I made few initial edits with exactly such tool that I made
CONTENT WARNING: it is a Python script. Not useful, unless you are a programmer. Or you want to check what I am editing.
If someone can supply me list of other such obvious replacements (Green → green level, not rot → red or darkseagreen → dark_green) I can run it for all of them.
If someone would get bot approval for trickier ones I can also run it, but I already have long queue for values to test, propose and write wiki pages for. So here someone else would need to spend time on everything else except moving list of tags to change into script and running bot edit.
After that happens I can run bot edit.
I reserve right to skip some values that I consider dubious or do not understand.
Black (~1800) vs black (64k)
Red (~1900) & RED (215) vs red (159k)
Brown (972) vs brown (217k)
Blue (933) vs blue (47k)
Yellow (906) vs yellow (130k)
DeepSkyBlue (545) vs deepskyblue (63)
Grey (553) vs grey (35k) & Gray (255) vs gray (96k)
White (508) vs white (80k)
Silver (279) vs silver (16k)
Orange (176) vs orange (30k)
DeepPink (2) vs deeppink (26)
Also spotted
red;white (4k), red/white (3k), red_and_white (2800), red-white (921), white;red (574), & white-red (356) which should probably all be one option only?
