added, will run probably earlier today after I finish things I am supposed to be doing today
I skipped DeepSkyBlue (545) vs deepskyblue (63) and DeepPink (2) vs deeppink (26)
DeepSkyBlue seems way more readable than deepskyblue AND is more popular.
if something has white and red stripes it seems reasonable
I would not mind for capital letters and ignore them while rendering. No big automated edifs are needed. We could even add that to zhe Wiki page. And yes, it makes komplex values more readable.
Semicolon lists are fine. This is valide for flags i.e. but not to define a mixed coloure value.
The other syntaxi shoul be corrected.
I recoment to alowe prefixes like light- or dark- and now also deep- (and high- ?).
It can still be coloured beside being transparent, or semi-transparent. Many canopies are transparent and only a subset is also colourless.
I am a programmer 
but never used Python. May be I could read it and make small adaptions. I will write you privately.
So you got the “license to edit” 007. Your example extends about some area. What are the accepted limits in OSM, for extended and number of objects changed?
Many ideas rise, but that must wait until my 3D render project is “ready”.
Just looking into the large usage of Green - I expected to see a localised import but didn’t. The map shows fairly broad usage, although usage by country varies. Looking at an example local to me, https://www.openstreetmap.org/relation/3190485/history started out as just the name “Dalby Forest Green Route”, to which was added ref=Green and then colour=Green (and the osm site interprets “Green” the same as “green”, so there’s no prompt from there to change).
I would be careful with the ;-seperated ones, as that could mean both white and red. For the others I would say white-red as in the marking for a GR footpath.
Where I live we are currently mapping a walking network. It consists of coloured routes and choice points. We map the whole routes as a roundtrips as well as the single segments between choice points (as you should in a network). For those segments it gets the colour value for all routes that follow that segment (and all colours are signed in between choice points). Using a single colour or not tagging colour at all does not seem correct to me.
It is the colour of the markers of the path. It is human habit to name it “white-red”. At last it is a list of colours, the marker is made of. So “white;red” would not be wrong as a value in this case.
There is a Wiki page for trail markers with other tagging:
https://wiki.openstreetmap.org/wiki/Trail_markings#Two-part
It uses “yellow + red” for the “foreground”-tag.
For your choice points, the colour of the column is blue
But the symbols are a list(!) of routes. That could be numbers or colours, a list of. But it is not the colour tag, is it? More a “ref” ist.
As a programmer, I can easily replace / or - by ; in the 3D renderer. For a trail map, the colours are important. The list members should be valid, so the 2D rendere can draw the segments in the correct colour.
I just checked a case of red/white, a bollard. You may guess how it is painted, in horizontal stripes proppaply. A renderer needs phantasy here 
Perhaps (in a hypothetical case) “older waymarks are white, but newer waymarks are red”.
In many of these cases a bit of digging may help (perhaps some of the objects tagged has image tags).
Edit: and none of these “unusual” cases are appropriate ones for an automated edit (unless individually discussed).
Agree, but that colour is not relevant for the routes.
Yes and no. The GR are semi-incorporated into the network as well. Take for example this one:
colour=orange;black;white-red.colour=orange;black as the stacks of signs on the route itself don’t have the GR plate, that is a sticker or paint instead. I only tag colour=white-red if it is the only signage on the route]
ref=N54-N83 is already used. A list of colours is reasonable and should be interpreted as follows:
these are often different between users
looking at my code (in already linked repo) and osm_bot_abstraction_layer/osm_bot_abstraction_layer/split_into_packages.py at master · matkoniecz/osm_bot_abstraction_layer · GitHub it looks like I ago with 500 elements in changeset and 0.3 degree span (yeah, I know that actual size of such bbox increases as you go further away from equator)
I got few complaints for some edits that were doing one element per changeset, but not many.
Note: The Dutch community have adopted this way of tagging colour of node@node routes of the Node Network (foot), in subregions where the adjacent Node numbers were not indicated on the Node poles. This meant that the user had to use the coloured arrow shields, so the itinerary output of node network routing apps also had to indicate the colours.
Boring details: these regions traditionaly have coloured roundtrip walks centered around the villages. The roundtrips often crossed each other and a particular path was often part of multiple coloured roundtrips and possibly one or more linear hiking routes.
Then Node Networks came along and they had to comply with the national standard to convert the network of local walking routes to Node Networks. Which they did by putting poles with a letter+number code at all the crossings of more than one roundtrip. Thus fulfilling the requirement: you have to have numbered poles, but ignoring the fact that the Nodes are only useful if they refer the user on the road to the adjacent Nodes.
Some of these regions have now come to their senses and implemented some form of referral by number or code, on top of the colour system. Only one region still resists… Other regions have since adopted the coloured roundtrip system in addition to the Node Network system, i.e. they have created coloured roundtrips over the existing Node Network system.
All in all, there is still the need to add the route colours to the Node2Node routes, to be used in (the output of) route planner software.
For flags, it’s especially ambiguous: for example, flag:colour=blue;white;red could refer to a single tricolor or a blue flag atop a bicolor on the same man_made=flagpole. Comparing the number of values in flag:type=* could help resolve this ambiguity in some cases but not all.
flag:colour=* was originally used for recording the field of a flag, especially one that is too obscure to have a flag:wikidata=* or country=* that a renderer could model graphically. But eventually someone contributed a comprehensive set of colors to name-suggestion-index, which entailed accounting for tricolors and even more complex designs that don’t have a single primary color.
This topic spreader out into a battlefield. Traffic- and Hiking-Maps defended their claim and habits to mark their routs. So I changed the headline slightly and set the focus on buildings firstly. I just have not the time/priority to dig in all applications of “colour” now.
May be later! Meanwhile I feel, there is a dissonance between the Wiki text and reality (“ground truth of tagging”). It is a good thing about OSM, you can extend tagging, outside the Wiki definition. But as now are really “confirmed” habits, they should be added to the Wiki. Even if someone like me thinks, it is a kind of “miss use” of the colour tag to describe way markings in the field.
About the (automated) building correction: Firstly, the wiki needs some additions
The tagging:
There may exist tools we could manage the human checks (… to do) and fully automated changes of limited areas and object count). If not, my render code may, just may also extend in this direction.
Today OSMgo found a bad colour value “verde”. Overpass Turbo shows 53 worldwide and 150 “Verde”. Changing them all in ONE changes would be easy but bad, won’t it? What’s the maximal appropriate bbox? And part count?
Let’s say 1x1 degree would be fine. 360x180=64800 change sets? Maximum if there are many wrong values. In reality about 700, I guess. And many with only one changed object. Not efficient.
So we should collect more bad values and mix them in one automated change action. The Taginfo should show the most common wrong values. A, wow, we have 806 tag names containing “colour”!
And we have 41 bad names “color” at 9615 objects.
https://taginfo.openstreetmap.org/search?q=color#keys
Would anyone have doubts to automatically replace them?
Funny: gtfs_route_colour is used exactly once, gtfs_route_color is used only in relations 85 times.
May be this exists, but It wouldn’t be a big thing, to write a tool for this:
@ Mateusz_Konieczny Is your Phyton codę able to to this (after some extensions)?
“color” may not the only “wrong” tag name. We could collect some more, to make the effort more useful. We should discus and agree about the string lists before executing the tool of course.
Would anyone have doubts to automatically replace errors this way? I bet on it.
Not necessarily - if the changeset description made it completely clear what it was changing and why, and not just “fixed tags” or similar (and perhaps even linked here!), then people should be able to figure out what is going on.
No, not for 53 objects 
Practically, if you look at the distribution via taginfo / overpass you may be able to do it in 2 or 3 much smaller ones.
For 9615 objects. And I assume, as they are concentrated on regions, it may be about 100 of them?
But yes, IF a world wide change-set is fine, I would do >41, one set per type 1/x-name(s).
road_shield_color would change 3282 objects at once. What is the API limit?
Just split them of the list? Or better split them by degree-regions?
We can balance this by the algorithm of the “automated changes tool”. First let it count, set limits.
I assume, I? the tool needs an edit-id. And the OSM API supports login, read(not needed?), upload changeset. Manageable. I would prefer to do it in a team, as this is mostly new to me. Either with @ Mateusz_Konieczny code or I could write something new (Rust) No promises, my time is limited.
For this, it’d be just Josm, surely? Why make things complicated?
main benefits for me is that it avoids missclicks and accidental bad edits.
Sometimes in my regular mapping I missclicked, cleaning it up if it applies to 200 000 objects would be extremely obnxoious and damage annoying to others. Far worse than breaking few objects in a small area. I seen automated edit in JOSM where someone accidentally squared all historic aircrafts - or some similar objects - mapped as areas in Poland.
(obviously bot edit can also break things - (someone in Czechia wanted to mass edit tags, they duplicated nodes instead - I just reverted it, fortunately rate limiting kicked in after 100 000 edits) - but it is less likely to be result of fat fingering button and problems are usually easier to prevent)
It is also easier to review edit (including posting planned edit plan which can be generated from the same config that will be used to run edits). It also reduces risk that you describe one edit and perform a different one.
Also, rerunning edits becomes easier (see say Changeset: 165522518 | OpenStreetMap )
And splitting edit into chunks is far less annoying if it splits itself according to preset maximum bbox size and number of objects in one edit.
(all this benefits apply when editing Python script is not harder than using JOSM, benefits disappear entirely if you need to learn programming to do so)
sounds like something that I did in my edits already
(note: you should ask people before running bot edit, you also should babysit edits and first edits should be reviewed one by one - also, not sure how usable is my code for others, feel free to ping me)
but of Python code does not work well, it can be done in JOSM anyway. And probably 50% of effort is checking whether edit makes sense and 30% effort is getting an approval.
I did not know Josm can du such complex things. May be a plugin?
The same questions as above.
But please could you do/try it. It is hard and dangerous to use some one others “raw” tool.
If you are not sure, what I would like to be done, please ask. (All tag names color to colour)
