Talk:Key:colour

darkbrown challenge

Darkbrown is NOT a valid value according to this page, but often used, as some others are. Most renderers will not mind because they don't use the tag, not render the colour, do not need to translate all colour strings to RGB values. But the 3D renderer do! Editors don't check for valid values? I think OSM should have its own file with colour strings and RGB values. It could be used by editors and renderers. Could it be a Wiki page with a template? Validators could check the existing values in the OSM data, replace spell errors or odd alternatives like "dark_brown", either by a bot or as a challenge for the users. —Preceding unsigned comment added by -karlos- (talk • contribs) 19:23, 1 November 2018

Though I think darkbrown is not used that much (only 6 times), you have a very valid point. The selected W3C basic colour set is very limited and generally too dark to be used for identifying real-world colours. (RGB in itself is already unusable to identify real-world colours, but that's another point.) By the way, if you're looking for challenging colour values used in OSM, I suggest all combinations of red and white: "red/white" (769x), "red-white" (427x) "red;white" (350x), "brown-red-white" (255x), ... --Pbb (talk) 11:57, 16 May 2019 (UTC)

Any Colour system you like

Why limit this to CSS and rgb? IMHO mappers should be encouraged to use the official colour like it is defined for the object (otherwise you would add a colour anyway), and should be encouraged to add the system as well ( IMHO on the value side of the tag) --Dieterdreist (talk) 13:49, 29 May 2013 (UTC)

Do you have some examples and use cases? --goldfndr (talk) 15:19, 29 May 2013 (UTC)

In my experience working with branding guidelines, official spot colours for things like transportation lines and logos, and more generally palettes for use by designers, are typically specified using the proprietary Pantone Colour Matching System. This might be problematic data to store in OpenStreetMap due to Pantone Inc.'s stance on intellectual property: not because they forbid you to write down the reference number, but because free/libre software cannot convert that reference number to an on-screen representation. It may be the case for some colour schemes that only Pantone CMS references are given, but this is somewhat rare. When using a designer's idea of which RGB triple to use, note that RGB is device dependent. Unless the guidelines say "sRGB" or "for the web" - unless you know the device a triple is specified for - assume that it will appear wrongly.

Example: the colours of transportation lines are commonly specified in this way first, for example Transport for London's Color Standard (official url), which also specifies each corporate colour using RGB triples, "for the web", in CMYK, and in the equally proprietary NCS.

Bottom line: if official colours are to be rendered on screen using tagged information, the OSM database must provide a suitable screen rendering colour, ideally as an sRGB hex triple.

(Outside OSM, I'm one of the development ream for the open source art package MyPaint. I very occasionally touch upon these sorts of branding guidelines as part of my job, although I am not a card-carrying web or print designer by any means.) --achadwick (talk) 13:04, 1 July 2013 (UTC)

Device profile

The main article should specify that RGB triples are to be interpreted in the sRGB colour space. I think that's the existing intent, given that web specs are used already, and that sRGB is the assumed default for the World Wide Web. --achadwick (talk) 13:34, 1 July 2013 (UTC)

Inconsistent usage of BE and AE on this wiki-page

Since there is in some cases color (AE) used instead of colour (BE) and the colour gray instead of grey this wikipage seems to be very inconsistend. I am not a BE-speaker and therefor I am unsure whether gray is actually non-BE.

The Table which is summing up the main colours from HTML/CSS should have an extra column to clearly state what the right osm-taggs are. —Preceding unsigned comment added by Cracklinrain (talk • contribs)

I believe both variants should be accepted, and changed the wiki page accordingly. Current suggested values are highly inspired in the CSS standard, and it indeed accepts both variants, though gray is described as a basic color value while grey is described as an extended color value. See CSS3's specification for more details. --Jgpacker (talk) 12:11, 17 February 2015 (UTC)

Colour not color. Colour is BE, color is AE. So too grey is BE, gray is AE (unless your thinking of the SI unit for absorbe does of ionising radiation which is Gray, note the capital letter). Warin61 (talk) 21:54, 4 October 2017 (UTC)

The meaning of AE or BE is not clear for everyone and in fact this distinction is not even needed. "gray" is the American English standard used in CSS, and "grey" is the British English alias (not recognized by all agents). "gray" remains recommended. This also explains why you think there are inconsistancies. This is not caused by the OSM preference for British English, but comes from another standard (which was later updated in CSS3 to include also British aliases for shades of "gray", the normal form; so "slategray" is recognized but not "slategrey" everywhere)! — Verdy_p ^(talk) 03:20, 5 October 2017 (UTC)

Look at the CSS reference links to the W3C just above the list: the aliases are in the "extended color set", not the base color set. This is independant of the fact that we name the tag colour=* in OSM, while the W3C defines the color: property for CSS, and the color="" attribute for HTML. — Verdy_p ^(talk) 03:25, 5 October 2017 (UTC)

Ok, the abbreviations AE = American English and BE = British English (you will note these were not introduced by me). I think you will find that British English came before American English therefore "gray" is historically secondary. Further OSM should 'prefer' British English and this can be done by placing British English terms before others. Can 'we' at least remove the brackets that suggest "grey" is secondary to "gray"??? I do note the Americanization of computer nomenclature as you have referenced. But if it is listed here as a 'color' then it should not be regarded as secondary in OSM. Warin61 (talk) 04:48, 5 October 2017 (UTC)

Tag names are from OSM, values have always been intended to use the W3C standard as it is! It is a technical reference, they are identifiers intended to be clear. The standard itself defines "colors", not "colours". We just opted in OSM to use "colour" in tag names. But valrues have been intended to be directly usable in HTML/CSS/SVG as is without any transform needed. — Verdy_p ^(talk) 11:18, 5 October 2017 (UTC)

As using RGB/Hex/HTML/CSS/SVG/whatever-you-want-to-call-it colors in OpenStreetMap is complete nonsense, I suggest scrapping this whole standard and replacing it with a proper standard using CMYK and spot colors written in British English. For those who don't know why RGB doesn't work, how are you going to define the color used to paint a fence in RGB? From a photo you took? Take a photo of the same fence a day later, and you will get different RGB values. RGB doesn't define real-life colors, it defines screen colors. CMYK, Pantone and several other systems are for real-life colors. ---Pbb (talk) 20:44, 27 March 2019 (UTC)

Displaying

Is there already a transportation map that use the colour tag and displayed the lines in their respective colour? --Männedorf (talk) 12:40, 8 February 2015 (UTC)

http://demo.3liz.com/osmtransport/ does this for a selected number of cities. See https://help.openstreetmap.org/questions/12944/transport-colours/29493 for an explanation why it's not normally done. (One of the main reasons: you can't have overlapping lines.) --Pbb (talk) 15:19, 28 April 2018 (UTC)

RGB = Tagging for the renderer

Defining colour values in RGB is a typical example of Tagging for the renderer, because RGB does not exist in real life! RGB is a method of defining colours on displays (computer monitors, TV screens, etc) where red, green and blue light is emitted. In real life, colours are not emitted but they are reflected, and need to be defined in a different colour model, for example spot colours.

The colour a house is painted in, can not be defined in red, green and blue. If you mix red, green and blue paint, you will get totally different colours than you will get when mixing them in RGB colours. In RGB you can mix 25% red, 25% green and 25% blue (rgb(63,63,63) or #3F3F3f). With paint, that doesn't even make sense! --Pbb (talk) 15:09, 28 April 2018 (UTC)

Most of what 3D renderers accept is basically tagging for the renderer. In a way that's one place in OSM where that's the only option. As for colours, yes, real-world colours (apart from light colours) are reflections, but you can still approximate their shade with RGB values, assuming reflected sunlight. And since's it's RGB no one will attempt to mix those colours with pigments, anyway. I'd still argue it's a useful approximation, even though many spot colours in the real world will likely be Pantone/RAL-based. But that's a can of worms no one really wants to tackle, I guess. --Ygramul (talk) 20:39, 13 July 2022 (UTC)

There are well-defined ways to convert sRGB to colors based on absorption ("subtractive"): printers exist and they, to an extent, work. Experience from the gaming industry will also tell you that a lot of physically correct things can be done in sRGB channels before you go to the route of modeling the whole visible spectrum, i.e. spectral rendering. Even then, there are algorithms that "guess" a very reasonable absorption spectrum for a material from just an sRGB color. --Artoria2e5 (talk) 12:06, 13 May 2024 (UTC)

Too dark colour palette

While working on an enhancement for the colour tag, I see another problem. The W3C basic color set is too dark to be used as a general set for real-world colours. There are 6 colours with a lightness of 25% (maroon, olive, green, teal, navy, purple), 7 with 50% (gray, red, yellow, lime, aqua, blue, fuchsia), and only 1 (which isn't a colour really) with lightness 75% (silver). Real-world colours are often lighter than on-screen (RGB) colours, since they don't radiate light the way a display screen does. --Pbb (talk) 12:04, 16 May 2019 (UTC)

You are correct -- the basic 16 colors are ancient and in no way reflects any modern consideration for legibility or aesthetics. They were really based on an idea that appeared before the web, i.e. the 16-color RGBI palettes of CGA and friends. (CGA is actually brighter.) They might be "compatible", but they definitely are not good for reading or looks.

PS: "lightness" is a lie. You can't average together RGB numbers to get how bright something is. See https://en.wikipedia.org/wiki/HSL_and_HSV#Disadvantages --Artoria2e5 (talk) 11:58, 13 May 2024 (UTC)

Multiple values

How do we tag an object with multiple values? In this case specifically power towers painted red and white for aviation safety. For many years there was a red/white value in JOSM preset, but it is gone. I assume for a reason. Gazer75 (talk) 11:43, 25 October 2021 (UTC)

You'll have to ask the JOSM devs what happened to the red/white value in the preset, but in Taginfo I can see 1,607 instances of it, along with 713 red-white and 712 red;white. Looking through Taginfo I'd say that semicolon-separated values are the most common for multiple colours. --501ghost (talk) 13:16, 25 October 2021 (UTC)

@Gazer75 and 501ghost: The semicolon syntax sounds pretty reasonable. (flag:colour=* often holds multiple colors separated by semicolons too, but that's sometimes because there are multiple flags on the same flagpole.)

Another common case is a rainbow-colored surface. Some have been tagged colour=rainbow, but there's also a competing tag for pedestrian crossings specifically.

 – Minh Nguyễn ^💬 21:01, 6 August 2022 (UTC)

I'd say defining some common gradients outside of CSS might be a good idea. We can't exactly expect renderers to support the whole CSS gradient thing and expect people to write a 100-character gradient every time they bring up a rainbow. (But on the other hand, if those renderers can't even get their acts together enough to understand the whole CSS 3 vocabulary, will they ever agree on a custom extension?) --Artoria2e5 (talk) 12:00, 13 May 2024 (UTC)

I'm thinking maybe using colour:1=* and colour:2=* would be a way to go. Any thoughts on this? Something needs to be done to fix the current mess of values at least. We got red/white, red-white, red;white, red; white and red and white. Must be a nightmare for data consumers to account for all this, Gazer75 (talk) 10:47, 11 July 2023 (UTC)

Trail colors

Mention how to tag the red trail, blue trail, often seen in parks. Jidanni (talk) 20:45, 30 November 2022 (UTC)

colour/color

100 years from now, mappers will still accidentally use color instead of colour. Therefore the computer should intervene somehow. Emitting warnings, or changing it behind the users' backs. Jidanni (talk) 21:21, 30 November 2022 (UTC)

colour names should be case-insensitive

The CSS specification is very clear: "The list of basic color keywords is: aqua, black, blue, fuchsia, gray, green, lime, maroon, navy, olive, purple, red, silver, teal, white, and yellow. The color names are ASCII case-insensitive." The definition of ASCII case-insensitive is: "A string A is an ASCII case-insensitive match for a string B, if the ASCII lowercase of A is the ASCII lowercase of B."

OSM should respect this definition and should not require lower case.

OSM tagging generally prefers lowercase keys and values, and there are benefits to having a single canonical representation of a value, e.g. for more meaningful Taginfo statistics, better compression in typical OSM file formats, to make work easier for developers of editor presets and so on. So while data consumers are obviously free to process these values in a case insensitive manner, I believe it is a good thing if mappers consistently use lowercase spelling. --Tordanik 12:47, 19 March 2023 (UTC)