Talk:BSicon/Colors

From Wikimedia Commons, the free media repository
Jump to: navigation, search


Discussions moved from Talk:BSicon/Icon geometry and SVG code neatness.

Some (somewhat outdated) suggestions at Category talk:Icons for railway descriptions/other colors.

Matters to be adressed concerning colors in our icons are outlied below, with links to their dicussion, when it exists:

Lets discuss each matter under a separate heading, to make it easier to wrap it up. -- Tuválkin 11:18, 20 February 2013 (UTC)

moved to Category talk:Icons for railway descriptions#Color Sets (Now on this page.)

I understand that the red set is for standard rail and the blue set is for rapid transit, but what are these new color sets for? (black, green, orange, purple, the multicolored Tokyo Set) Samhuddy (talk) 02:49, 13 December 2008 (UTC)

Using only red or blue colors in templates of metro lines in cities, where lines are always marked with color, isn't good - users say, that such templates are bad. For example, in Saint Petersburg they always mark 1st line with red color, 2nd - with blue color, 3d - with green color, 4th - with orange color, 5th - with violet color and so on. Passengers know, which color corresponds to appopriate line. So we have to make a sets of different colors to solve this problem, because common template doesn't allow to choose a color of line. Dinamik (talk) 19:25, 16 December 2008 (UTC)
In the first place, these icons have been created for a different reason. Their purpose was to symbolize stations, junctions and other structure of "heavy" railway tracks (later set blue was created for light rail and metro). But the usage of these icons widened up (much more then the initial intention) and by the time there are very complex track fields etc. made of railway line icons. A new kind of usage are varicolored metro line descriptions or even metro maps. --$traight-$hoota (talk) 16:53, 17 December 2008 (UTC)

I think that, a couple years later, we can summarize it like this: While the two regular sets, with their huge number of icons, ready to illustrate any concievable need, are used to build detailed diagrams of railways, the other color icons, while sharing naming conventions, are used only in much simpler diagrams of services (which coincide with lines only in the simplest systems), needing typically only icons for stations and a few straights, with any additional icon being an oddity. (Examples of this contrasting diagram building: MTS lines vs. MTS network) The system however allows such oddities to be created and offers a simple way to name them (adding the color name to the equivalent red or blue icon). This approach seems to working well, and it is only its details that need to be worked out. -- Tuválkin 05:40, 22 February 2013 (UTC)

Naming special color variants:[edit]

Note that perception of color is not only very subjective, but also varies from monitor to monitor. Useddenim (talk) 12:37, 22 September 2012 (UTC)

Either way, this whole thing’s a mess, namewise, and a major revamp should be made. --Tuvalkin (talk) 13:52, 4 September 2011 (UTC)

I think, large-scale renaming or merging two or more different colors in one technically not justified at all. Conflicts of participants from different countries in this case are inevitable, and if the icon is widely used there will problems with updating pages cache, decor will be violated. The game is not worth the candle. Let it be as it is. --Туча (talk) 21:39, 28 February 2013 (UTC)

The fact that you apparently didn’t notice that FOO_green and fFOO has been renamed back and forth for the last year shows that said renaming (even of the 3rd most used color of BSicons) doesn’t affect the projects in any noticeable way. The thinly veiled threat about «conflicts of participants from different countries» is also moot, as people active in this discussion come each from a different home wikipedia. -- Tuválkin 00:25, 1 March 2013 (UTC)
I know whereof i speak. The situation with f and green is familiar to me, i took part in this, and i know what problems it creates in the articles. It does not need work. It will cause inconvenience to readers, it will load servers, it will take time of people, and it shall be useless. --Туча (talk) 09:06, 1 March 2013 (UTC)
No, it shall be (or already it is being) very useful. Bear in mind that the usage of all these icons, including the normal red and blue ones, is, for now, really small, comparing to what it could be: Many articles about railways without diagrams, even in bigger wikipedias. That means that changing what is already done is a lesser inconvenience compared with the advantages of improving the system to be more logical and easy to use for its future users.
There is no way we can say to a newcomer who needs to work with green icons that they can be named "fFOO" or "FOO_green" and there’s no logic behind it, we’re stuck with it just because. Fixing that now is the best thing we could do.
-- Tuválkin 04:45, 4 March 2013 (UTC)
(A really good quintessence of the whole underlying philosophy! YLSS (talk) 13:27, 4 March 2013 (UTC))
It is interesting logic. If you believe in it, then the flag is in your hands, but it will be very bad if after half a year on the same scale changes occur again under the same slogans, and it will become a habit. --Туча (talk) 18:55, 4 March 2013 (UTC)

HexRGB value vs. generic name[edit]

Let’s cast our vote on this?
RGB name User
Symbol oppose vote.svg  Symbol support vote.svg  -- Tuválkin 10:31, 27 February 2013 (UTC)
Symbol neutral vote.svg  Symbol support vote.svg  YLSS (talk) 20:03, 28 February 2013 (UTC)
Symbol oppose vote.svg  Symbol oppose vote.svg  --Туча (talk) 18:55, 4 March 2013 (UTC)
Symbol oppose vote.svg  Symbol support vote.svg  -- Useddenim (talk) 23:20, 4 March 2013 (UTC)
−3 +2 (tally up)

It has been suggested that the BS icon hex value color sets be replaced with ones using "natural" names. (talk) 12:37, 22 September 2012 (UTC)

Personally, I would prefer a named set vs. RGB code, although I've seen opposite opinions here. (I guess I'd better drop a note at ru:wp as well.) YLSS (talk) 14:55, 17 February 2013 (UTC)
I for one prefer a generic color name than a strict RGB value, and I have been indending on discussing that. Concerning the browns, it is much simpler to keep the name "brown" and just edit and/or move all icons to either of the chosen RGB value. -- Tuválkin 15:15, 17 February 2013 (UTC)

Tuválkin, are you sure you want to rename all those sets? I mean, "robin", "tangerine", "cadet" etc. would be no more clear to general users than RGB codes - and at the same time they are not so precise. I would say that common colour names would be enough, that is (green,) orange, yellow, violet, brown & black; possibly also teal, grey and red (for EF161E), if you are really ready to rename them. Others I would've let alone. YLSS (talk) 20:59, 21 February 2013 (UTC)

I agree that cryptic names are not a good idea, and I want us to adopt the best choices, however even the weirdest are still better than RGBs. Because:
  • Almost no-one can recognize in their heads a color shade by looking at an RGB (actually I can), and also because these suggested names are all actual English color names in use, however specialized, and and can be thus looked up (and memorized — which is important, as these icons are to be used by Wikipedia editors, not readers).
  • RGBs are a bad idea also because they lock each named icon set to a specific color shade. If we ever want to change the exact shade of, say, yellow, we can go around just uploading slightly modified SVGs and that's that — if the filenames indicate a specific color shade, that can be done, but the name becomes misleading. Besides, that’s what happens already with the exRGB icons — while the icon   (KBHFa 029B52) does show indded the color 029B52, the icon   (exKBHFa 029B52) does not and that’s confusing. On the other hand, having two icons   (KBHFa(seagreen)) and   (exKBHFa(seagreen)), the latter with a more lighter and unsaturated shade, is perfectly acceptable. (Specific names for each color should be discussed under the respective headings.)
So, yes, I’d go for generic color names for all icon sets, even those with really few icons and scarce use. -- Tuválkin 07:46, 22 February 2013 (UTC)

So what, under what name should I upload new icons now, "XXX 999999" or "XXX grey"? I know Tuválkin's answer, but would like to hear others' opinions. YLSS (talk) 16:01, 23 February 2013 (UTC)

meanwhile decided by voting that should be name, not RGB

I think we should either have sets called with all three of "green", "blue" and "red", or none of the three (and it doesn't look like we'll have a green-named set. What's slated for "red" could easily become "crimson" instead.). I think "cerulean" is a fine name for any of the sets (after all, we used "vert"). Could "sky" be a reasonably simple name? Circeus (talk) 06:37, 27 March 2013 (UTC)

I agree that all simple color names should be used (as not using any isn’t a practical option). Indeed, the name "green", as soon as it made free by renaming and recategorization of set "f", will be used for 2DBE2C. The name "red" was free and fits EF161E as well or better than any other — of course BE2D2C is our main color, but it doesn’t need a name (set "") and it is also an atypical shade of red. (Other replies q.v..) -- Tuválkin 23:24, 27 March 2013 (UTC)
Ah, alright. I was under the vague impression (I'm following this discussion only from afar) "green" wouldn't be used, hence my slight confusion. Circeus (talk) 05:55, 29 March 2013 (UTC)


Determining generic name from RGB[edit]

RGB used in… # current name name of best match [q.v.] rename? ⨇? final RGB comment
003399 set blue
(many)
u IKBlue u no 003399 standard "u" blue
0256A4 set 0256A4
17
0256A4 cobalt blue denim yes 00619F
00619F Berlin U-Bahn
15
uBlnU8 cerulean
0079C2 Tokyo
3
TokyoMita true blue blue yes 0078BE
0078BE set 0078BE
10
0078BE
1A8BB9 set 1A8BB9
41
1A8BB9 bondi blue cerulean no 1A8BB9
069DD3 Berlin U-Bahn
10
uBlnU7 robin egg blue sky yes 069DD3
00A7DB Tokyo
4
TokyoTozai
029EE0 set 029EE0
16
029EE0 All usage replaced by azure
00A0DD other colors
1
00A0DD azure yes 3399FF merged into azure
3399FF set azure
53
3399FF dodger blue ex339999 = 3399FF, ex3399FF = 99CCFF
67F8FF RizhMZD
13+
RizhMZD electric blue cyan yes 40E0D0
00FFFF set cyan
5
cyan aqua
99CCFF set 99CCFF
23
99CCFF baby blue exazure no 99CCFF merged as "ex" into azure
99CCFF set BUTOVO
13
BUTOVO white; baby blue steel no A1B3D4 Relevant ru:Бутовская линия changed (type &) colour
339999 set teal
31
339999 jungle green teal yes 339999
14A796 Berlin U-Bahn
10
uBlnU3
00ADA9 Tokyo
1
TokyoNamboku persian green
009090 SMT
4
uSMT
009944 Tokyo
1
TokyoChiyoda pigment green g yes 2CA05A
029B52 set 029B52
22
029B52
2CA05A set 2CA05A
57
2CA05A sea green Also categorized under canal; see also the "g / ug / mg / umg / 2CA05A" naming discussion.
canal
175
g… & ug
008000 set green
237
f office green f no 008000 Also categorized as footpath, partly common sets; see also "f / green" naming discussion.
footpath
49
f
B4EEB4 set B4EEB4
6
B4EEB4 magic mint exgreen? no 7FD67E Recolored: see discussion.
53B147 Berlin U-Bahn
15
uBlnU1 asparagus jade no 53B147
6CBB5A Tokyo
1
TokyoShinjuku mantis fex no 64B164
2DBE2C set vert
13
vert lime green green? no 2DBE2C
99CC00 set lime
34
99CC00 apple green lime yes 99CC00
B3D52E set B3D52E
9
B3D52E yellow-green All usage replaced by lime
D7C447 Tokyo
2
TokyoYurakucho old gold golden no D7C447 See discussion.
FFD403 Berlin U-Bahn
8
uBlnU4 gold yellow yes FFD702
FFD702 set yellow
86
yellow
FFAB2E set FFAB2E
19
FFAB2E saffron saffron yes FFAB2E Moved to set saffron.
FFA500 RizhMZD
3
RizhMZD
MosMetro5
Orange (web) See discussion.
F39700 Tokyo
1
TokyoGinza princeton orange
F09E36 other colors
22
moscow6 carrot orange
EB851C Berlin U-Bahn
9
uBlnU9
FF6600 set black-orange
7
black-orange safety orange black-orange yes FF6600 See discussion.
FF6600 set orange
123
orange orange =exCC6600
F25821 Berlin U-Bahn
14
uBlnU2 See discussion.
E60012 Tokyo
1
TokyoMarunouchi red red yes EF161E
FF0000 RizhMZD
7
RizhMZD_1
RizhMZD
MosMetro1
See discussion.
EF161E set EF161E
15
EF161E lust
BE2D2C (all)
(lotsa)
fire brick no BE2D2C main standard color
E85298 Tokyo
1
TokyoAsakusa french rose exruby yes DE64A1
CC0066 RizhMZD
8
MO MZD Ruby ruby yes CC0066
B5198D set B5198D
9
B5198D red-violet fuchsia yes B5198D
B6007A Tokyo
1
TokyoOedo
800080 set violet
83
violet purple violet no 800080
8171AC Berlin U-Bahn
25
uBlnU6 cool grey purple yes 8171AC
9B7CB6 Tokyo
1
TokyoHanzomon
9999FF set 9999FF
8
9999FF lavander lavender no 9999FF
C0C0C0 set C0C0C0
44
C0C0C0 silver exgrey yes C0C0C0 All usage replaced, partly merged as "ex" to 999999
9CAEB7 Tokyo
1
TokyoHibiya cadet grey grey 999999
A9A9AA set A9A9AA
7
A9A9AA rose quartz All usage replaced by 999999
999999 set grey
40
999999
000000 set black
61
black black black no 000000
71592E set 71592E
17
71592E coffee brown yes 8D5B2D Non-duplicate moved & reloaded as brown, all usage replaced
825A42 Berlin U-Bahn
4
uBlnU5 raw umber
8D5B2D set brown
9
brown chestnut
BB641D Tokyo
1
TokyoFukutoshin ochre ochre yes CC6600
CC6600 set CC6600
44
CC6600 tawny
RGB used in… # current name name of best match [q.v.] rename? ⨇? final RGB comment

Space vs. brackets[edit]

Let’s cast our vote on this?
space brackets User
Symbol oppose vote.svg  Symbol support vote.svg  -- Tuválkin 10:31, 27 February 2013 (UTC)
Symbol support vote.svg  Symbol oppose vote.svg  -- Useddenim (talk) 11:44, 27 February 2013 (UTC)
Symbol support vote.svg  Symbol oppose vote.svg  YLSS (talk) 20:05, 28 February 2013 (UTC)
Symbol support vote.svg  Symbol oppose vote.svg  Circeus (talk) 18:56, 6 March 2013 (UTC)
Symbol support vote.svg  Symbol oppose vote.svg  --Туча (talk) 19:55, 6 March 2013 (UTC)
+3 −3 (tally up)

I started (experimentally) using brackets instead of a space (or an "_") to integrate the color name in “other color” icons. This solution could also be used in other icon names, as needed. -- Tuválkin 11:14, 15 February 2013 (UTC)

Whether with or without brackets, well, I think we shouldn't use too many special chars in our names ... a×pdeHello! 12:03, 15 February 2013 (UTC)
Concerning “special characters” — well, space is the trickiest of them all (thankfully Mediawiki defangs it into a "_" in most ocasions), and we rushed to get rid of them in the KRW icons, for instance. How “special” are brackets? They are A-OK for filenames even in old computer systems, and surely they are not missing in any keyboard that includes the Latin script letters and indo-arabic digits we already use. Any other opinions? -- Tuválkin 04:06, 16 February 2013 (UTC)

And brackets - purely aesthetically I would prefer "XXX grey", and the desire to lessen renamings etc. for existing sets thus named backs it. ? YLSS (talk) 16:01, 23 February 2013 (UTC)

The desire to lessen renamings, note, is not important when it comes to these “other color” icons, as their usage is minimal. We should strive for the best possible nomenclature now, disregarding any weight from the statu quo, because there’s not much around. Anyone with filemover rights (me, Useddenim, Axpde — who else?) could renamed all these “other color” icons and fix their usage in a week or two. -- Tuválkin 03:24, 4 March 2013 (UTC)

Another reason for my favouring of brackets over space is that in a diagram with BS templates a space can be called as either a "_" or a " ", and that may cause problems when trying find an icon in the article’s source code. That was on of the reasons to drop the space as part of the icon IDs in ABZs, KRWs, and the "_legende" business. -- Tuválkin 10:31, 27 February 2013 (UTC)

I suggest that people who favor spaces instead of brackets should volonteer to help in the renaming of some current usage of green icons to "fFOO" — because it doubles the work, as you have to look up for both "FOO_green" and "FOO green". -- Tuválkin 17:29, 1 March 2013 (UTC)
One year later, and we know how well this went over… -- Tuválkin 16:45, 4 May 2014 (UTC)


Special sets[edit]

One of the results of the standartization we aim for is that disappears the need for special icons, as they are integrated in a larger common pool, even if their special specific use is atypical. For instance, Tokyo mass transit lines are maked with what is normally an overlay/legend depiction of a depot or cargo/goods station. Do we need to keep those special sets nominally current by means of specially named redirects, gathered in specific categories? I think not, but what do the rest think? -- Tuválkin 02:19, 9 March 2013 (UTC)

Tokyo[edit]

The specific Tokyo diagram usage is no obstacle for ex-colors being used as main, as these are only overlay or legend roundels, added to regular RDT blue or red icons… -- Tuválkin 04:06, 8 March 2013 (UTC)

Summary of color changes:
Line old rgb new rgb old icon (redir.) new icon Remarks
Mita 0079C2 0079C2   (TokyoMita)   (lDST_blue) discussed; Symbol neutral vote.svg no change
Tozai 00A7DB 069DD3   (TokyoTozai)   (lDST_sky) discussed; ✓ Done
Namboku 00ADA9 339999   (TokyoNamboku)   (lDST_teal) discussed; ✓ Done
Chiyoda 009944 2CA05A   (TokyoChiyoda)   (glDST) discussed; ✓ Done
Shinjuku 6CBB5A 64B164   (TokyoShinjuku)   (fexlDST) discussed; ✓ Done
Yurakucho D7C447 D7C447   (TokyoYurakucho)   (lDST_golden) discussed; Symbol neutral vote.svg no change
Ginza F39700 FFAB2E   (TokyoGinza)   (lDST_saffron) discussed; ✓ Done
Marunouchi E60012 EF161E   (TokyoMarunouchi)   (lDST_red) discussed; ✓ Done
Asakusa E85298 DE64A1   (TokyoAsakusa)   (exlDST_ruby) discussed; ✓ Done
Oedo B6007A B5198D   (TokyoOedo)   (lDST_fuchsia) discussed; ✓ Done
Hanzomon 9B7CB6 8171AC   (TokyoHanzomon)   (lDST_purple) discussed; ✓ Done
Hibiya 9CAEB7 A1B3D4   (TokyoHibiya)   (lDST_steel) discussed; ✓ Done
Fukutoshin BB641D CC6600   (TokyoFukutoshin)   (lDST_ochre) discussed; ✓ Done
I edited your proposal a bit in respect of prefix order. YLSS (talk) 16:32, 18 March 2013 (UTC) Discussion moved to Talk:BSicon/Renaming#Prefix position.
Redirects[edit]

While I don’t defend a set of named redirects for these whithin the BSicon system (i.e. named BSiconSOMETHING and as such usable, in that renamed form, from within a diagram), I presume that said set of redirects could be created to allow better semantics when calling these icons from within inline text or other non-BSicon uses. -- Tuválkin 02:19, 9 March 2013 (UTC)

Meanwhile I noticed that these icons, named "BSicon_TokyoSomething.svg", are called by a few templates, and there is a family of other icons (not filenamed "BSicon…") akin to these but showing letters inside the ring, and consistently named (these other icons however need to be RBG-changed to in order to match the now-changed whole). This calls for exceptional permanent redirects to the   (DST_legende)-style names. -- Tuválkin 09:30, 16 March 2013 (UTC)

I created   (lDST_red) by renaming   (TokyoMarunouchi) — a redirect was created. Right now its uses are redlinked, even in Commons. I wonder how long and what takes (if anything) for the redirect to show up, even in BS diagrams? -- Tuválkin 06:19, 2 April 2013 (UTC))

Because of the redirect File:BSicon TokyoMarunouchi.svg: Hi, It is working very disadvantageous to the forwarding with our de:Template:Japan-Bahnsteig Knochen ﱢﻝﱢ‎  17:33, 2 April 2013 (UTC)
Yes, that’s what I was saying above. And wondering, how long does it take for the redirect to work in all projects, or what is necessary to be done. -- Tuválkin 19:26, 2 April 2013 (UTC)
Why did you have to move the file? Would not suffice the new file with the changed colors to load it? --Knochen ﱢﻝﱢ‎  21:19, 2 April 2013 (UTC)
As to why, you can read what’s on this section, or consider general guidelines for icon naming. That is not specifically a Marunouchi roundel, that’s just a generic red trackless DST. We’re striving for unification here, and these redirects not working properly (yet, I hope) are one of the growing pains of that trend. (Maybe the templates calling for these now-redirectings could be changed to call directly the icons by their new names?) -- Tuválkin 23:32, 2 April 2013 (UTC)
Yay, the redirect is showing up as of today, in Commons and wp:de (at least). We can say it takes around 48 h for a redirect to show up, then? -- Tuválkin 14:15, 3 April 2013 (UTC)
Now it was the turn for   (TokyoYurakucho) to be replaced with   (lDST_golden), and (not) to show up after two days; next up:   (TokyoNamboku)  (lDST_teal). -- Tuválkin 18:40, 4 April 2013 (UTC)
Maybe it would be better to rename them en masse? Less editing, less time in disrupted state. YLSS (talk) 19:19, 4 April 2013 (UTC)
I thought of that, and really there’s both advantages and disadvantages in both approaches: Either a lot of disruption in a shorter period, or less disruption in a longer period (no editing is involved, note, only moving). Maybe the 1st approach is superior if it is understood that any disruption, big or small, is (almost) equally unacceptable and therefore the sooner it is all done, the better. Maybe Knochen could chime in? -- Tuválkin 23:44, 4 April 2013 (UTC)
(Some use [of   (lDST_red)], namely in wp:bg, is not semantically Tokyo Marunousi, so that was renamed to the new name. -- Tuválkin 06:19, 2 April 2013 (UTC))

Berlin[edit]

Summary of color changes:
U old rgb new rgb Remarks
U1 53B147 53B147 No change.
U2 F25821 FF6600 But its use changed to red. See discussion.
U3 14A796 339999 See discussion.
U4 FFD403 FFD702 Trivial change; see discussion.
U5 825A42 8D5B2D Trivial change; see discussion.
U6 8171AC 8171AC No change.
U7 069DD3 069DD3 No change.
U8 00619F 00619F No change.
U9 EB851C FFAB2E But its use changed to orange. See discussion.

Up so far this was a very neat set, although some of its icons has been used for other diagrams, too, both in the native English Wikipedia (e.g. Bucharest Metro) and abroad (e.g. Oporto metro and subrurban railways, in the Portuguese Wikipedia), which added to the set new icons, not used in the Berlin diagram. I asked the original uploader about his views. -- Tuválkin 02:19, 9 March 2013 (UTC)

Moved from User_talk:Tuvalkin#Re:_Berlin_U-Bahn_colours
Hi! Coincidentally I have noticed that discussion a few days ago and in general I think that unifying the colours and names is a very good idea, especially since—as you've pointed out—icons named BlnUx are used for diagrams for Bucharest, Porto and other cities. So a priori I don't care if the icon is named BlnU3 or teal, as long as its colour is sufficiently close to the "original" Berlin U3.svg and, even more importantly, different from another shade of green for Berlin U1.svg. I just imagine a possible issue if the diagram is indeed composed from, say, teal and lightgreen icons and someone decides to change the shade of teal and unintentionally makes the colour too similar to light green. But this is not really that likely, I assume.
Also, I don't care about the category. It was meant to be yet another "color set" category, only containing nine colours and not one, due to my laziness (or to avoid clobbering, choose one).
µzdzisław⟩ 10:40, 9 March 2013 (UTC)
Sounds great — this special set can therefore be fully integrated with the existing system, setting the example for any other such special use of oddly colored BSicons. -- Tuválkin 18:42, 10 March 2013 (UTC)
As for the expressed concern over some future change that might render hitherto distinct icon sets indistinguishable, I can only say that I share it, but that having a centralized and streamlined icon set with colored subsets and a body of practices and procedures about its usage is the best way tyo ensure that will never happen. -- Tuválkin 19:03, 10 March 2013 (UTC)
So maybe introduce later a policy of listing all templates/pages/projects that use a particular colour set on that colour set's category page, akin to "(Global) file usage" on file pages, so that people attempting to modify the colours would know what caution to take? Sadly it could not be automated, like the latter - or could it? Anyway, an idea to think about. — ⟨µzdzisław⟩ 10:53, 11 March 2013 (UTC)

Hi there, awesome work going on I see! I'd personally replace U2 by red, also because it's definitely redder on the operator site (I mean the red bullet boxes in the station list). If there's a consensus on that, I'll rather see U9 to be orange than saffron, although it's also a matter of opinion. Also, once either U1 or U2 gets finally dealt with, something should be done with the double-coloured BlnU12 icons presently sitting in Category:Icons for railway descriptions/set mixed/other colors/parallel lines. I still think currently these are unnecessary altogether, but in any case at least the naming will need to be harmonized. — ⟨µzdzisław⟩ 23:44, 23 March 2013 (UTC)

U2 was replaced by red, but it could have been kept orange (just a tad lighter), as there are icons for either option, ditto for moving U9 from orange to saffron. That is a matter of wp:en’s editorial policies concerning its en:Template:Berlin U-Bahn route diagram — here in Commons we must just consider the names and colors of the icons to enable them to cover best the widest possible range of applications (of course we also use these icons in the projects; it is more a matter of swapping hats worn on the same head). -- Tuválkin 22:32, 31 March 2013 (UTC)
Thanks! You are a super diligent editor and also a regexp ninja. I think that at this point the BlnU12 icons should finally be deleted—it's either that or reupload them with some non-deprecated shade of orange/red, and it seems pointless as they are unused altogether. — ⟨µzdzisław⟩ 16:27, 3 April 2013 (UTC)
Hehe, thanks. They found a home at Category:Icons for railway descriptions/set mixed/other colors/parallel lines, after a little snip. -- Tuválkin 02:25, 4 April 2013 (UTC)

Moscow[edit]

Messy and abandoned; from the beggining the two diagrams using this set included also icons from other sets (black, green), so it can be fully integrated, keeping no distinct name redirects and losing the separate category. (See discussion.) -- Tuválkin 02:19, 9 March 2013 (UTC)

(This is about this particular set), not other icons's use for Moscow diagrams, nor other custom made Moscow icon sets. -- Tuválkin 11:46, 11 March 2013 (UTC)

Kuala Lumpur[edit]

Its whole integration (not only color shades, but filenames, geometry, and topology) is being discussed somewhere else. Seems trivial. -- Tuválkin 02:19, 9 March 2013 (UTC)

Deriving the ex-shade given an RGB[edit]

moved and redacted from here: Talk:BSicon/Renaming#Fish or fowl.3F

I just noticed   (exSTR 66CC00). Is it a member of   set 66CC00 , in which case there should be no ex prefix, or on the other hand is it part of   set 34C924  and therefore has the wrong color suffix? Useddenim (talk) 19:58, 20 August 2012 (UTC)

The thing is that we dont have a generic way of derive the "ex" color from any main color of the track — I mean, if   (STR) then   (exSTR), if   (uSTR) then   (uexSTR), if STR foobar-color then… what? We should probably analyze this and develop some formula to aumaticly derive an "ex" shade from any RGB. -- Tuválkin 02:23, 21 August 2012 (UTC)
  #d77f7e  =   #be2d2c  opacity:0.5 and   #6281c0  =   #003399 , so that's how the ex colors are derived. Useddenim (talk) 03:44, 21 August 2012 (UTC)
Guy’s a phreakin’ genious! :-D Now, lets see of all those Category:Icons_for_railway_descriptions/other_colors oddball color icons which include an "ex" subset respect this or not — and lets make them respect it if not!… -- Tuválkin 09:55, 21 August 2012 (UTC)
Just to remind you guys. Do not reduce opacity of the SVG elements. It might cause unexpected result while overlaying over another icon. -- Sameboat - 同舟 (talk) 01:03, 1 March 2013 (UTC)
You’re right, but nobody's using partial opacity to create "ex" color icons, only to calculate the "ex" color RGB values, and then using that to modify (or create anew) "ex" color icons with fully solid elements thus colored, all with zero transparency. So, no problem. (However HUBs do have partial opacity and that does cause trouble. Something to be discussed and fixed, I guess.) -- Tuválkin 02:07, 1 March 2013 (UTC)
That’s why I created some half- and quarter-width HUBs–so we don’t end up with situations like BSicon .svgBSicon HUBq.svgBSicon dHUBq.svg . Useddenim (talk) 17:36, 1 March 2013 (UTC)

Testing half opacity with colors[edit]

I have been experimenting, by use of an RGB color picker and this SVG:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg xmlns="http://www.w3.org/2000/svg"
        width="500" height="500" viewBox="0 0 500 500">
<rect x="0" y="0" width="500" height="500" fill="#F9F9F9" />
<g stroke="#BE2D2C" stroke-width="125" fill="none">
        <circle cx="375" cy="250" r="100" />
        <circle cx="125" cy="250" r="100" style="opacity:0.5;" />
        </g>
</svg>
Firefox
color its ex op=0.6 op=0.5
BE2D2C D77F7E D67F7E DB9292
003399 6281C0 6482C0 7C95C8
Chrome
color its ex op=0.6 op=0.5
BE2D2C D77F7E D88180 DF9696
003399 6281C0 6684C2 8099CC

Results so far show that, while opacity:0.5 is a good approach, the best match with the "ex" value in use for both the red and the blue icons sets is opacity:0.6. I use this value in the tables below: -- Tuválkin 06:19, 18 February 2013 (UTC)

Amazing. I did the same tests at the same time (which even led to edit conflict), but got different results (with 339999 and fuchsia I got 84C2C2 & D275BA respectively at 0.6). For my part, I tested the result in Chrome. You? (Edit: Chrome, it seems, makes simple mathematics for opacity: e.g. (FF - (FF - BE) * 0.5) = DF etc.) YLSS (talk) 06:50, 18 February 2013 (UTC)
Firefox here. Should be identical, but the variation range is okay. -- Tuválkin 06:47, 18 February 2013 (UTC)
I made my original observations using Safari. Useddenim (talk) 11:58, 18 February 2013 (UTC)
Improved test SVG:
     <?xml version="1.0" encoding="UTF-8" standalone="no"?>
        <svg xmlns="http://www.w3.org/2000/svg" width="500" height="500">
        <rect x="0" y="0" width="500" height="500" fill="#d77f7e" />
        <path d="M 250,75 401.5,162.5 401.5,337.5 250,425 98.5,337.5 98.5,162.5 Z" fill="#f9f9f9" />
        <g fill="#be2d2c">
         <path d="M 250,75 401.5,162.5 250,250 Z" opacity ="0.55" />
         <path d="M 401.5,162.5 401.5,337.5 250,250 Z" opacity ="0.56" />
         <path d="M 401.5,337.5 250,425 250,250 Z" opacity ="0.57" />
         <path d="M 250,425 98.5,337.5 250,250 Z" opacity ="0.58" />
         <path d="M 98.5,337.5 98.5,162.5 250,250 Z" opacity ="0.59" />
         <path d="M 98.5,162.5 250,75 250,250 Z" opacity ="0.60" />
        </g>
        </svg>
Useddenim (talk) 23:40, 18 February 2013 (UTC)
(Apparently one needs 11 hours of studying to make one's brain work...) Why do both of you use F9F9F9 as background colour and not FFFFFF? The results I posted above were for plain white background. With F9F9F9, I also get D67F7E at 0.6 in Chrome, but DC9393 at 0.5. Magic. Or sleepy eyes. YLSS (talk) 20:57, 22 February 2013 (UTC)
Hehehe, the default background for BS diagrams is F9F9F9, not FFFFFF, I thought you knew. ;-) -- Tuválkin 21:19, 22 February 2013 (UTC)


Suggested new ex values[edit]

These values, to be discussed generally and specifically, are meant to guide the creation of "ex" variants of icons in any color — this doens’t mean that such variants are to be necessarily created, and indeed most of these will be probably never needed and the scarce need of those existing few might even decrease. -- Tuválkin 11:26, 18 February 2013 (UTC)

Icon sets without existing "ex" versions
color op=0.6 set comments
No change needed / done
00619F 649EC3 BlnU8 (added from 0256A4, as denim)
0078BE 64ACD6 set 0078BE ✓ Done as blue
0079C2 64ACD8 Mita (merged into blue)
069DD3 67C2E3 BlnU7 ✓ Done as sky
00A7DB 64C8E7 Tozai (merged into sky)
00A0DD 64C4E9 other colors (merged into azure)
99CCFF C0DEFD 99CCFF (merged as "ex" into azure)
009090 64BABA SMT (merged into teal)
00ADA9 64CCC9 Namboku (merged into teal)
14A796 70C8BE BlnU3 (merged into teal)
00FFFF 64FDFD RizhMZD (merged into cyan)
67F8FF A2F9FD cyan ✓ Done as 40E0D0 + 8AEAE1
009944 64C08C Chiyoda (merged with 2CA05A)
2CA05A 7EC49A 2CA05A (added from 029B52)
53B147 95CE8E BlnU1 ✓ Done as jade
6CBB5A A5D49A Shinjuku (merged as "ex" into f)
B4EEB4 D0F3D0 B4EEB4 (merged as "ex" into vert)
FFD403 FDE365 BlnU4 (merged with yellow)
D7C447 E5DA8E Yurakucho ✓ Done as golden
FFA500 FDC764 MosMetro6 See discussion
F39700 F6BE64 Ginza (merged into saffron)
EB851C F1B474 BlnU9 (replaced by saffron or orange)
F25821 F59977 BlnU2 (merged into orange and red)
FF0000 FD6464 Mos1 (merged with red)
E60012 EE646E Marunouchi (merged with red)
E85298 EF95BF Asakusa (merged as "ex" into ruby)
9999FF C0C0FF 9999FF ✓ Done as lavender
8171AC B1A8CB BlnU6 ✓ Done as purple
9B7CB6 C1AED1 Hanzomon (merged into purple)
B6007A D164AD Oedo (merged into fuchsia)
C0C0C0 D7D7D7 C0C0C0 (merged as "ex" into 999999)
9CAEB7 C1CCD2 Hibiya (merged into steel)
BB641D D4A075 Fukutoshin (merged into CC6600)
825A42 B29A8B BlnU5 (merged into brown)
8D5B2D B89A7F brown ✓ Done
Icon sets with existing "ex" versions
color op=0.6 set its ex comments
006E34 64A683 S-bahn 9AD7B6 not change?
000000 646464 legende AAAAAA change? exBLACK as used in   etc.
No change needed / done
003399 6482C0 ("u" blue) 6281C0
0256A4 6597C6 0256A4 0695FF ✓ changed, as denim
1A8BB9 73B7D3 cerulean 85BBE0 ✓ changed
3399FF 82C0FD azure 99CCFF pretty close: keep? (See discussion.)
029EE0 65C3EA 029EE0 A6FFF4 merged into sky or azure.
99CCFF C0DEFD BUTOVO CCEEFF recoloured as steel
339999 82C0C0 teal 3399FF ✓ changed
008000 64B164 green
footpath
00FF00 ✓ changed
029B52 65C195 029B52 0BFF79 ✓ changed, merged into 2CA05A
2DBE2C 7FD67E vert 7FD77E ✓ changed (Renamed "green"; see discussion.)
99CC00 C0DE64 lime D1E681 keep: almost match
B3D52E CFE47F B3D52E CFFF71 superseded by lime.
FFD702 FDE565 yellow FFEB81 poor contrast: keep
FFAB2E FDCB7F saffron FFC969 keep?
F09E36 F4C384 moscow6 F5BE79 (merged into saffron)
FF6600 FDA164 orange FF9955 keep?
EF161E F37176 EF161E D77F7E ✓ changed (See discussion.)
BE2D2C D67F7E (standard) D77F7E
CC0066 DE64A1 ruby FF00FF ✓ changed See discussion.
B5198D D173B8 fuchsia FF5AEF ✓ changed
800080 B164B1 violet FF00FF ✓ changed
999999 C0C0C0 grey B3B3B3 ✓ changed
71592E A8997F 71592E B2864D (merged into brown)
CC6600 DEA164 CC6600 FF6600 ✓ changed
000000 646464 black B3B3B3 ✓ changed (See also discussion.)
(several colors)
RizhMZD 000000 (Special case: see discussion)


Ex identical to another[edit]

Careful with 339999. As of now, it shares 3399FF as its "ex" with the separate set 3399FF, there are even categorized redirects here (cheers!). YLSS (talk) 07:00, 18 February 2013 (UTC)

(Cheers, too!) Current exCC6600 being identical to FF6600 is another such case. It needs to be addressed. -- Tuválkin 08:28, 18 February 2013 (UTC)

The whole succession seems to be like that: ex339999 = 3399FF, ex3399FF = 99CCFF, ex99CCFF = 99CC00. The last one is quite stunning, but see File:BSicon meKBHFxe azure+jade.svg & File:BSicon meKBHFxa azure+lime.svg. The resulting title/redirect pairs can be checked at User:YLSS/BSicon. YLSS (talk) 21:38, 23 February 2013 (UTC)
  1. 339999 should certainly be reassigned another "ex" colour.
  2. I suppose I'll merge 99CCFF properly into 3399FF - it is only used by itself for a proposed line of light blue colour - that is, an "ex".
  3. 99CCFF is also used for Moscow Butovo light-metro line, but apparently it will get a greyer shade, and this should be done by re-uploading current BUTOVO set. YLSS (talk) 22:45, 14 March 2013 (UTC)
Sounds good. -- Tuválkin 04:09, 15 March 2013 (UTC)
1 & 2 ✓ Done. YLSS (talk) 14:26, 18 March 2013 (UTC)
3 ✓ Done. YLSS (talk) 23:12, 28 May 2013 (UTC)

While using green as disused blue is simply silly (considering the precedent set by regular red and blue), I would say that cascades of successive ex-colors, like among the #Greys should also not be accepted, because it would wreak havoc in the naming. F.i. — if dark grey is the ex-version of black, all icons in that color will be named "exFOO_black", and that’s all good, but if then we assume that light grey is the ex-version of dark grey, we’d have two possible names for a dark grey icon — either "exFOO_black" or "exFOO_grey", as it would be simultaneaously a standalone color and an ex-derivative. There should (as actually there is) a separate grey on its own, different from black’s ex-version, with its own, lighter ex-version:

  •   (BHF black)
  •   (exBHF black) (see discussion)
  •   (BHF grey) (BHF gray)
  •   (exBHF grey) (exBHF gray)

The same goes for all other colors, even if they present a chromographically less “clean” gradient as greys do. In practice, this means that we can have an ex-version for any color, and also that, for those uses where use/disuse (or other such imaginable pairing) is not necessary, the set as a whole offers double the colors as it seems to at 1st. (And this may be the key for some Berlin and Tokyo integrations we have yet to do.) -- Tuválkin 23:46, 9 March 2013 (UTC)

Close colours[edit]

Moved from Talk:BSicon/Obsolete and deletions#Close colours.

I am aware that "the human eye can distinguish about 10 million different colors", but I really doubt that we need as many colour sets for BSicons. Consider light blues, greys and light greens below. There are other pairs of close colours (and even triplets), but more readily distinguishable, so I'll leave them to please the aesthetics of different users. Besides, the RGB codes may be possibly assigned officially in other countries, who knows... In case of 999999/A9A9AA, 3399FF/029EE0 and 99CC00/B3D52E, the first set in a pair is always more developed that the other, while the second is only used for Moscow Metro lines (Serpukhovsko-Timiryazevskaya, Filyovskaya and Lyublinskaya respectively) in non-Russian Wikipedias (French and Spanish generally). Ru:wp uses the former colour sets, and as far as I know there are no official RGB codes for Moscow Metro. So, unless anybody opposes, I will replace all uses of icons from A9A9AA, 029EE0 and 99CC00 sets and nominate them for deletion. YLSS (talk) 20:49, 14 February 2013 (UTC)

There are several sensible reasons against keeping and mantaining sets of close color icons — not only because they cannot be used in the same diagram (where contrast is paramount), but also that a less attentive editor might mix and match from these sets to create or edit diagrams which are “good enough” with almost identical color shades, instead of exact matches. This goes against the very modularity and clearness having diagrams made from standartized building blocks is all about, after all. (However, discussions about colors should be covered in Talk:BSicon/Icon geometry and SVG code neatness, not here.) -- Tuválkin 00:13, 15 February 2013 (UTC)

Greys[edit]

Tokyo Hibiya[edit]

BSicon KDSTa grey.svg BSicon lDST steel.svg BSicon TokyoHibiya.svg BSicon exlDST steel.svg BSicon exKDSTa purple.svg
grey
999999
steel
A1B3D4
Hibiya
9CAEB7
ex-steel
C6D1E5
ex-purple
B1A8CB

(Hm, another addition to was should have not be closed so soon…) The color of   (TokyoHibiya) is noticeably not desaturated (i.e., not a perfect shade of grey, with all three RGB components identical) — it is slightly bluish, or better — tealish, as 9C < AE < B7: it could be saturated up to      00AAFF (yes, really, do the numbers!). But, “purty” as that is, the contents of en:Tokyo Metro Hibiya Line and ja:東京地下鉄日比谷線 (espcially the photos and that bit about "silver"/"銀"), make me think that Hibiya could be perfectly depicted by grey BSicons, even in roundel form. The accepted standard grey 999999 is suitably close to 9CAEB7 (only 36.742, slight less than 41.243 from ex-grey C0C0C0). I therefore suggest   (TokyoHibiya) to be recolored to 999999 and renamed   (lDST_grey). -- Tuválkin 16:30, 11 March 2013 (UTC)

Hm, on the other hand, it kinda looks a bit like ex-purple…? Opinions? -- Tuválkin 02:17, 21 March 2013 (UTC)
BTW, Hibiya looks quite close to this one... YLSS (talk) 00:52, 28 May 2013 (UTC)

BUTOVO[edit]

Hooray hooray, the new scheme of Moscow Metro has finally appeared in trains, and now we can deal with BUTOVO set. The line colour has changed to something periwinklish, and although using that name would have been hilarious, I settled on "steel", since light steel blue is close, and the name seems OK. I reuploaded the icons with A1B3D4 (and ex = C6D1E5 so that there is at least some contrast between ex and non-ex, and to keep it distinct from lavender, grey & purple. If there is no outcry on ru.wp, I'll move these files to "steel" soon. BTW, Hibiya looks quite close to this one... YLSS (talk) 00:52, 28 May 2013 (UTC)

✓ Renamed. Seems that now only g/ug left, plus multi-coloured lines. YLSS (talk) 23:12, 28 May 2013 (UTC)

Black[edit]

(Hm, seems that this is not quite closed yet…) The ex-black icons are colored AAAAAA, but they should be changed to 646464, or at least to a shade darker than 999999, right? -- Tuválkin 23:50, 9 March 2013 (UTC)

A really peculiar set... In this case, the difference between "DST" and "INT" would only be in the thickness of the circle! However, currently available "INT"s (all uploaded by Laukatu) are actually "DST"s! Compare:
  (INT black) vs.   (INT legende) vs.   (INTl black) (the last one is OK). So what, should they be moved and proper "INT"s uploaded? Or just re-loaded with correct thickness? Or just to the hell with them? YLSS (talk) 21:24, 21 March 2013 (UTC)

Found this discussion. It seems that it's actually   (INT),   (INT legende) and the whole line-up of   (INTl) etc. that remain unpatched (though in the last case it may be undesirable). That aside, it appears that in case of "black"s we would have completely similar icons for INT's and DST's. So what, maybe employ redirects?   (INT black)  (DST black)? Or should we find a way to differentiate them in this special case, e.g. introduce a white border to separate INT circle from the stem, but no such one for DST? YLSS (talk) 07:10, 22 March 2013 (UTC)
I had this one set aside for later, but it’s late enough already… ;-) Yes, the size of INT and DST is (or should be) identical, as per that discussion, and the slight differences we can still find are not distinct enough, especially at typical display sizes. (I also disagree with having special versions of INT for use with black lines, although that should be discussed somewhere else.) The problem is not in the shapes or sizes of DST and INT, the problem is black itself. Because black, as also white, and, less so, F9F9F9, 80A080, and 007CC3, at least, are confusing colors when used for lines, as they are also the colors of diagram elements that (unlike, say,  ) are drawn o the line, or very close, and in a particular, unchanging color. INT being identical to black DST is the most egregious case; but things like black   or   look hardly good. I see two solutions for this:
  1. Assume that, more than any other color, black should be used for simple diagrams only, showing only stations and their interconnections, wich is the original idea, anyway (note e.g. this article, where the diagram showing services uses several colors, matching realworld use, but the diagram showing the line, with bridges, sidespurs, and detailed annotations, uses regular blue and red); in this approach, INT being black would not be confusing and only marginally of less than perfect symbology.
  2. Boldly go and change the color of the black lines to something like 444444. This is actually done in many print media, to avoid excessive contrast — often black in illustrations, namely in few-color diagrams, is not the same black as in text. That would leave for real black only things like   and  , offering contrast against the “black” line. (This color’s 60% opacity, now proposed for ex-black is 8C8C8C, still darker that grey.)
Opinions? -- Tuválkin 13:35, 22 March 2013 (UTC)
(Or we could ditch the 60% thing in the case, as black offers already maximum contrast to background-white, and go for something like 555555/777777.)
IMHO black should stay black. At the usual displayed size of those icons we need as much contrast as possible. Ok, INT might be a problem, but only if you insist on having black colored line icons. Grey colored icons should be darker than ex-black, ex-grey very light. There's only a problem, when black and grey colored line icons within the same RDT. But that's a problem of colors, and there are only limited solutions.
You know I didn't bother much about other colors as long as the original project isn't touched. And I don't think we really need dozens of different line colors. (Btw. is there by chance an option to pass a parameter to an svg? Just an idea ...) You're doing a hard job to standardize all those random colors, so I think best is "KISS" - keep it smart'n'simple! a×pdeHello! 17:09, 22 March 2013 (UTC)

Meanwhile, Tuválkin has re-uploaded all ex_blacks with #646464. If that is settled, what with DST/INT issue? Should we assume them the same (and use redirects, or not), or some other solution? Still no support for   (DST black) vs.   (INT! black) ? I have also experimented with having INT circle painted #444444, but it does not perceptibly differ from the line. YLSS (talk) 23:39, 29 April 2013 (UTC)

Purples[edit]

BSicon lENDEa mask.svg BSicon DST ruby.svg BSicon BHF fuchsia.svg BSicon lENDEa mask.svg BSicon DST violet.svg BSicon BHF purple.svg BSicon lENDEa mask.svg BSicon KDSTa lavender.svg
Asakusa
1 icon
set ruby
12 icons
set B5198D
9 icons
Oedo
1 icon
set violet
85 icons
Berlin U6
25 icons
Hanzomon
1 icon
set 9999FF
8 icons
RUBY FUCHSIA VIOLET PURPLE LAVENDER
CC0066 B5198D 800080 8171AC 9999FF
ex: DE64A1 ex: D173B8 ex: B164B1 ex: B1A8CB ex: C0C0FD

All shades between red and blue. An important area, as (darker shades of) those two are our main “normal” colors:      and     . There are nofew clearly close shades to be merged, though, while on the other hand we seem to have more variety than it is advisable. -- Tuválkin 02:49, 8 March 2013 (UTC)

The needs of the Tokyo usage demand that we have three distinct shades among these, though. Maybe Oedo could have its RGB changed to integrate the violet set, and Hanzomon changed to match Berlin U6? As for Asakusa — maybe its E85298 is close enough to ex-ruby’s DE64A1? — the specific Tokyo diagram usage is no obstacle for ex-colors being used as main, as these are only overlay or legend roundels, added to regular RDT blue or red icons… -- Tuválkin 04:06, 8 March 2013 (UTC)
I’m adding my suggestion to the table above, complete with names and final RGBs. -- Tuválkin 15:23, 11 March 2013 (UTC)
Okay, I’m going ahead with fuchsia and lavander, since nobody hates the idea. -- Tuválkin 01:14, 16 March 2013 (UTC)
✓ Done -- Tuválkin 02:26, 16 March 2013 (UTC)
Purple also ✓ Done. -- Tuválkin 01:05, 21 March 2013 (UTC)
I guess I'm a bit of late... Since both purple & lavander presently lack "ex"-icons... Maybe repaint the latter as the former's ex? Just a silly thought... BTW, why "lavander", not "lavender"? YLSS (talk) 14:33, 18 March 2013 (UTC)
It is (still) “lavander” because I’m an illiterate fool, like the other guy said. I’ll fix it. Having it changed to ex-purple, though, seems too much of a change. This is a light/pale blueish purple, and a need for it is concievable. (We’ll have the need for a darker, deeper bluish purple inp the future, too, to be named indigo or some such — several metro lines use something like it.) -- Tuválkin 01:59, 21 March 2013 (UTC)
The color violet
the color purple

From en:Purple:

In the traditional color wheel used by painters, violet and purple are both placed between red and blue. Purple occupies the space closer to red, between crimson and violet. Violet is closer to blue, and is usually less intense and bright than purple.

WTF? YLSS (talk) 21:51, 21 March 2013 (UTC)

Well, yeah, but we calling violet what is more close to purple and vice versa, I think, is not as if we’re swapping green and red. The stated convention stems more from etymology (the violet flower color and the hue of murex shell dye) than from actual usage, wich is remarkably fuzzy. Note however that in the table above, what was already called violet before is shown to be closest to purple — but since our purple turns out to be closest to some kind of grey, and there’s something, redder, named violet-red, not purple-red, the whole thing feels arbitrary and thus merely indicative. So I guess we’re good -- Tuválkin 02:14, 22 March 2013 (UTC)
Well, OK; the original question for me was how to translate these names (in file descriptions). In Russian, "фиолетовый" & "сиреневый" (for "violet" and that shade we have as purple) would suit quite good; in German I guess "Violett" & "Lila"? YLSS (talk) 05:55, 22 March 2013 (UTC)

Ex-violet certainly should be changed, but to something lighter than B164B1. Maybe Chrome-0.6 B366B3 or even Chrome-0.5 C080C0? YLSS (talk) 07:00, 18 February 2013 (UTC)

I’m not convinced that B164B1 is too dark. Maybe some experimentation? -- Tuválkin 08:28, 18 February 2013 (UTC)
YLSS, I’m being bold and changing the dreaded FF00FF to B164B1 — if you still think it is too dark, lets change it again later. Truth is that many of these icons need to be redrawn (from their normalred or normalblue counterparts) as they have more or less serious design flaws, color notwithstanding. -- Tuválkin 17:16, 14 March 2013 (UTC)
✓ Done -- Tuválkin 18:57, 14 March 2013 (UTC)
(I’m aware that ex-violet is being used in the Basque wp for a line in use in the diagrams for Bilbao metro, L3. I warned the main contributer. It could be either kept or changed to fuchsia. -- Tuválkin 18:23, 14 March 2013 (UTC))
I got a reply and it is a go-ahead. Actually L3 is being built, so the "ex" was on the spot, but he says that wp:eu is going for ruby instead. -- Tuválkin 19:31, 14 March 2013 (UTC)

Something strange goes on with Category...purple... All icons that were renamed from BlnU6 are sorted after those newly uploaded by me, even though alphabetically they should follow them. TokyoHanzomon also appears before them. Character codes seem to be OK... Magic & mystery. YLSS (talk) 13:39, 2 April 2013 (UTC)

Ruby[edit]

BSicon lENDEa mask.svg BSicon exDST ruby.svg
Asakusa exDST_ruby

Strangely enough we almost lack a reddish shade of purple (grenate, bordeaux, etc.). Only 8 icons salvaged from the atypical Moscow set. Now reworked and gathered at Category:Icons for railway descriptions/set ruby. -- Tuválkin 02:49, 8 March 2013 (UTC)

I added a few station icons this set was missing, in case they are needed, and maybe   (TokyoAsakusa) will join the set as   (lexDST_ruby). -- Tuválkin 04:06, 8 March 2013 (UTC)
Well? Close enough? (For what’s worth, the RGB vectorial distance is 22.472; the closest named shade for the ex-ruby shade is Thulian pink.) -- Tuválkin 23:50, 10 March 2013 (UTC)
✓ Done -- Tuválkin 01:07, 12 March 2013 (UTC)

Greens[edit]

We are stuck with two greens — 2CA05A ("g") and 008000 ("f"); not as clearly different as one would wish, but more or less “forced” on the system from two sister projects: canals and footpaths, respectively. They both have these special prefix names, like "u" for 003399, so no need to come up with any witty color name for the filenames, unlike all other colors. -- Tuválkin 14:31, 4 March 2013 (UTC)

(There’s also two or three more shades, to be sorted out under #Light greens -- Tuválkin 14:31, 4 March 2013 (UTC))

f-Green[edit]

Icons with line color as 008000 are categorized as both Category:Icons for railway descriptions/set green and Category:Icons for footpath descriptions, but not fully overlapping. There’s no issue about the specific shade. Filenames were recently started to be standartized as "fICON", some still remaining "ICON_green" (some heavily used) are being slowly renamed and relinked. Some SVG and naming fixing is necessary for two-color and "ex" variants of these icons. -- Tuválkin 14:31, 4 March 2013 (UTC)

I’d say that changing the "ex" shade to 64B164 is prioritary, and would not affect the diagrams — things like   (exCONTl green) are an ophtalmological health hazard! -- Tuválkin 14:46, 4 March 2013 (UTC)
Uff, done! There should be a law against 00FF00, really. -- Tuválkin 02:17, 11 March 2013 (UTC)

While transferring icons from ru.wp to Commons, I renamed several as "fexXXX". First step, right? YLSS (talk) 21:05, 11 March 2013 (UTC)

The moving from wp:ru and further replacing of eyesearing hues and craptastic SVG with sensible stuff is a great thing, but I think that, to make it simplest, "f" should go in the same exact place as "u" in the (dark) blue set — thus not f.i.   (fexCPICl) but   (exfCPICl). -- Tuválkin 15:17, 12 March 2013 (UTC)
Ahem, it is exactly in the same place!   (uexCPICl) =>   (fexCPICl) etc. Colour prefixes go in the first (outermost) place. YLSS (talk) 15:54, 12 March 2013 (UTC)
Please disregard my inexcusable stupidity. O.o -- Tuválkin 17:47, 12 March 2013 (UTC)

(A good example of why we should strive for consistency in naming: while   (fKBHFe) is heavily used by itself, three redirects to it are all used as well across Wikipedias: fKBFe, KBHFe green, KBFe green. YLSS (talk) 22:38, 12 March 2013 (UTC))

FYI: I created Category:Icons for railway descriptions/set f with subcats for gradual migration. See #Blues & #Vert & B4EEB4 above. YLSS (talk) 10:14, 19 March 2013 (UTC)

I've renamed the majority of icons to fXXX names and made sure no redirects from XXX green remain. These are at set f and subcats. Those that are still at set green are mostly half-width or for parallel railways; I'm really afraid of them, so I yield the honours of properly renaming/moving them to others. YLSS (talk) 22:16, 19 March 2013 (UTC)

And thanks to Cirt, everything is in mess. Greens in f. Why only do people rush to do what they don't know about? YLSS (talk) 22:26, 21 March 2013 (UTC)
Oh, bummer. (I did start typing a more, ahem, passionate assessment of the situation, but deleted it all in favour of “being constructive” and “assuming good faith”. Hmmm…) Well, looks like we’ll have to go around in the subcats of set_f picking up "green"s and renaming them "f", one by one…the same as in all other (smaller!) categories, but sadly so, as, in this one, it was toil we could avoid. -- Tuválkin 01:28, 22 March 2013 (UTC)

g-Green[edit]

BSicon uxgTRANSg.svg BSicon lENDEa mask.svg BSicon lENDEa mask.svg BSicon lENDEa mask.svg
uxgTRANSg
(2CA05A)
175 icons
KDSTe
2CA05A
57 icons
KDSTr
029B52
22 icons
Chiyoda
(009944)
1 icon

The only other pair of sets that IMO could be merged is 2CA05A ("unwatered canals") and 029B52. YLSS (talk) 18:13, 15 February 2013 (UTC)

However, this would mean replacing a specifically-for-railways set with one actually-for-canals-but-possibly-also-for-railways, as well as introducing an "ex" to unwatered canals. So I won't proceed with this one unless I meet a stong support here... YLSS (talk) 18:13, 15 February 2013 (UTC)

I've never really liked the ug naming, so my 2¢ worth would be to change to Category:Icons for railway descriptions/set 029B52. Useddenim (talk) 21:54, 15 February 2013 (UTC)
I’ve never really liked the "ug" naming, either, but as the canal diagrams seem to make consistent use of it, it would be much better to have someone devise some solid rules about this preffix and how it compares to things like "u" or "f", and even "m". -- Tuválkin 03:23, 16 February 2013 (UTC)
I guess that we should assume that "g" works exactly in the same way as "u" and "f" and just go ahead with creating new icons as needed, renaming existing oddballs into this scheme, and even fixing existing canal icons so they meet the standards. (Icons with "ug" especially mystify me: Why the "u"?) -- Tuválkin 04:21, 4 March 2013 (UTC)

(Added 1 icon from the Tokyo set, with almost identical RGBs.) -- Tuválkin 04:21, 4 March 2013 (UTC)

  (TokyoChiyoda) changed to RGB:2CA05A. It can be later renamed as lgDST. -- Tuválkin 07:18, 8 March 2013 (UTC)
Have you noticed that Chiyoda is used in fr:Chemins de fer départementaux du Finistère in place of   (flDST)? YLSS (talk) 18:54, 19 March 2013 (UTC)
That shows two important things:
  • How much g-green and f-green are similar.
  • How special named sets will always be reused to serve the most inexpected ends.
(Needs to be fixed there, though: The exact color was off before and is off still now.) -- Tuválkin 21:31, 20 March 2013 (UTC)
✓ Done: Newly created   (feDST) now in use in the Britanny diagram. -- Tuválkin 21:37, 20 March 2013 (UTC)

All 22 icons from here recolored to 2CA05A; resulting duplicates marked and their usage change to "ug"; new additions to the "ug" set recatogorized as 2CA05A, to be renamed. -- Tuválkin 09:22, 8 March 2013 (UTC)


Renaming issues[edit]
This section is about the issues that have arisen in renaming icons

One of the first discussed, one of the last processed... I've renamed all "XXX 029B52"s and "XXX 2CA05A"s to "gXXX" or "gexXXX" (BTW,   (exgSTR),   (exgKBHFa) and   (exgBHF legende) actually exist/ed, but with #5abf89 and in weird categories), and at the same time moved several ugXXX to gXXX, plus created temporary redirects for others. Those that remain here (not much) and here (a lot) are mostly canal-specific, so I'm not really sure how they should be named. The same goes for the numerous "u" + "g" = "ug", and for these. If anybody feels more sure-footed, please bring this to closure. YLSS (talk) 15:18, 9 April 2013 (UTC)

It isn’t for no reason this one remained till last, as it is tricky. Concerning the 1st matter, I say that everything that works with the same templates (i.e., names start with "BSicon_") should be kept within the samae category tree (to be renamed to a more neutral "BSicons" in the future), regardless of refring to railways, canals, bus routes, Roman cobbleways, roller coasters, family trees, life cycles or whatever. As for the second, it should be simple, but so far nobody ventured an explanation for what is "g" and what is "ug" (I fear nobody realy knows) — sooner or later (say, by next week) this should be solved and, lacking a better idea, the "u" should be simply ditched for most, and kept only for mixed icons using both u-blue and g-green, such as   (ugTRANSg) (which, b.t.w., should be named   (ugENDE), cp.   (umENDE)). (And, again, congratulations to YLSS for all the hard work, and in the right direction.) -- Tuválkin 19:32, 9 April 2013 (UTC)
The only ones who can help us generalize -g are the canal people. -g has two issues at the moment that I can spot:
  • It was conceived as a step further than -x (canals as displayed by the canal project may be watered, but unused, or they may be derelict and without water), so not only has the colour no -ex version, but there are nonetheless -xg icons! This further leads to some very strange interactions with the -m prefix: looking at this, I cannot figure out if there is a combination for a vertical -g line crossing an horizontal regular line!
  • -xg was used on mixed icons, where the blue was light blue. There was a vertical -g line crossing a horizontal regular line, but one was named ugKRZo and the other gKRZo (following railway scheme). They both have become gKRZo on the Waterways Legend at the moment. See below for another 7 pairs so affected. Bob1960evens (talk) 13:42, 11 April 2013 (UTC)
  • Because all canal icons were supposed to us u-, it was originally intended to be always accompanied by -u.
I strongly suspect we will need the full support of the English wikipedia's canal project to effect a proper evolution of this set, or at least their (presumed) knowledge of how it's supposed to work. Circeus (talk) 06:31, 10 April 2013 (UTC)
Use of the ug prefix
The ug prefix was implemented around 2007 for the Canals project. Prior to that, icons such as STR were red railway icons. Icons such as uSTR were blue, where the u stood for underground, but Canals used most of the uXXX icons, so it also came to mean Canal. The icons were displayed using a Canalrow template on the Waterways Legend page, and as templates were still a bit of a mystery to me at the time, it was easier to extend the Canalrow to include extra icons which used the same basic naming scheme, than to introduce a new one. So ug came to mean canal-green. If I had known then what I know now, I might have done it differently. The green icons (ugSTR, etc) were introduced to distinguish between a canal which was no longer in use, but still contained water, from one which was no longer in existence. I note that whatever action has been taken has decimated the Waterways Legend page, with very few of the green icons now visible. By my count, 124 icons now just show "20px" instead of an image. (cy:Nodyn:Camlas_Arysgrifen is also decimated.)
I agree that some of the combinations are not very obvious, but struggled with how to rename some of the icons when User:Axpde and others introduced the -m prefix for mixed (ie red and blue). We needed red/blue for live rly/live canal, red/lightblue for live rly/dead canal, lightred/blue for dead rly/live canal, lightred/lightblue for dead rly/dead canal, red/green for live rly/no canal, lightred/green for dead rly/no canal, blue/green for live canal/no canal, and lightblue/green for dead canal/no canal. Again it was easier to think in terms of an extra g, than more letters like m for all the possible combinations. I hope that helps. I would be very happy to help if that can result in a more consistent naming scheme. Bob1960evens (talk) 15:38, 10 April 2013 (UTC)
Thanks for this summary, Bob. I'm going to guess the icons thing is because (IIRC) it takes about 48h for commons redirects to be taken into account on en: (possibly page purging might be involved too).
As for figuring out the names, here's an idea: we figure out how these icons would be named if the prefix was f-, and go from there?
Circeus (talk) 16:33, 10 April 2013 (UTC)
@Bob1960evens - The trouble you now see with the Waterways Legend is that the Canalrow template has been changed to accommodate the change from "ug" to "g" (and "uxg" to "xg") - however not all the "ug" and "uxg" files have been renamed - thus you are seeing "20px" red links. If we are going to use "g" for green, then we should rename all the "ug" and "uxg" files ASAP.  Ronhjones  (Talk) 18:58, 10 April 2013 (UTC)
My bad. I assumed that the matter of renaming "ug" -> "g" is settled and underestimated the complexity of the issue. Given the fact that I don't understand a thing in mixed-colour prefixes, that was too bold... However, I made sure no templates in the article namespace are disrupted. YLSS (talk) 15:21, 11 April 2013 (UTC)
The JUNC icons present a particular problem. So   (uJUNCa) is fine, and was followed by   (uxJUNCa) for an unnavigable junction. This was before the convention changed, so light blue icons became -ex variants, rather than -x variants. Considerably later,   (uexJUNCa) was added. These last two are clearly the wrong way round, compared to the present naming scheme, but redirects will not help, because each needs to be redirected to the other. I'm not convinced that   (umgABZlf),   (uxmgABZlf),   (uemgABZlf), and   (uexmgABZlf), etc, are named quite right either, but it was the best I could think of at the time. There are also several which use the -H prefix (for horizontal), which could use the -q suffix (although there was some considerable debate on en:Template_talk:Waterways_legend as to when the -q suffix should be used, which was never properly resolved). On second thoughts, maybe   (uexJUNCa) should really be ueJUNCa, since the "through" route is navigable and the side junction is not. Bob1960evens (talk) 08:45, 11 April 2013 (UTC)
I note that something has gone wrong with the green bridges, at least on the Waterways Legend. The new naming scheme has resulted in ugKRZo and gKRZo becoming the same. (and uxgKRZo/xgKRZo, ugKRZu/gKRZu, uxgKRZu/xgKRZu, ugmKRZo/gmKRZo, uxgmKRZo/xgmKRZo, ugmKRZu/gmKRZu, uxgmKRZu/xgmKRZu). ugKRZo was originally blue crossing green, and gKRZo was green crossing blue. Both now show as green crossing blue:
  (ugKRZo)   (uxgKRZo)   (ugKRZu)   (uxgKRZu)   (ugmKRZo)   (uxgmKRZo)   (ugmKRZu)   (uxgmKRZu)
  (gKRZo)   (xgKRZo)   (gKRZu)   (xgKRZu)   (gmKRZo)   (xgmKRZo)   (gmKRZu)   (xgmKRZu)
Bob1960evens (talk) 09:01, 11 April 2013 (UTC)
This is how they were. However, the naming scheme suggested changing -ug to -g, and User:YLSS has altered the Canalrow template used to display the icons on Waterways Legend in anticipation of this. Consequently, ugKRZo becomes gKRZo, although they are different. The simple changing of -ug to -g does not cope with the complexity of the issue. Bob1960evens (talk) 13:04, 13 April 2013 (UTC)
Well, en:Template:Canalrow & en:Template:Plainrow should be changed as well once all the renaming is done. Current "xg" should be changed to either "uxg" or "ueg" (which?! or both?) in one and to "gu" in other. YLSS (talk) 20:37, 13 April 2013 (UTC) Balderdash. That won't solve the issue. I suppose the "xg" column should just be dropped, as it is only used for multi-color icons, and such cases should be presented using additional rows in the table. Or additional tables, since various   (umgABZlf) &   (uxgJUNCa) should likewise be renamed. en:Template:Plainrow can then be just deleted. YLSS (talk) 20:48, 13 April 2013 (UTC)
You can only delete Plainrow if there are no icons with a railway root left, as they do not start with a -u. Bob1960evens (talk) 18:02, 14 April 2013 (UTC)
A solution might be to use two letters where the colours are mixed, like the -um variant for mixed railway bridges. So ugKRZo would be blue vertical and green horizontal, while guKRZo would be green vertical and blue horizontal. It would need a new row-type for the Waterways Legend. It is not quite as elegant, since -m means mixed, and not railway, but gmKRZo and mgKRZo could resolve the green/red mixup. The same logic could be applied to the   (umgABZlf) connumdrum, where ugABZlf would be blue vertical with green branch, and guABZlf would be green vertical with blue branch. Bob1960evens (talk) 10:06, 11 April 2013 (UTC)
Could we please keep each subject in its separate thread? This page is about colors, this secion is about “g-green”. Please go have discussions on naming in its proper place. -- Tuválkin 14:53, 11 April 2013 (UTC)
Well, the color thing is virtually settled (we're merging these), so it's almost all naming anyway (specifically how do we clean up the -g icons). The discussion should probably move to BSicon/Renaming since the only color-related issue besides the merging (which nobody argues against) I can see is the creation of an xg shade. Circeus (talk) 15:45, 11 April 2013 (UTC)
Sorry if I have misunderstood what this is about, but my comments were about prefixes for icons which include green but also have other colours in them. The process of replacing -ug with -g has already resulted in 8 pairs of icons which were different appearing the same, and no obvious place in the naming scheme to put the ones which are no longer available under this new scheme. Bob1960evens (talk) 16:04, 11 April 2013 (UTC)

<undent> Okay, adding sections, color-only issues can be kept here in the main discussion.

Bob, do you think you could compile a list of former icon pairs that have become the same for us? It's not possible for someone coming in after the fact to find them...

All of those affected were based on the KRZ root, with mixed colours. So in the railway world,   (mKRZo) had red vertical and blue horizontal, while   (umKRZo) had blue vertical and red horizontal. This approach was copied for the green icons, so we had   (gmKRZo) with red vertical and green horizontal and   (ugmKRZo) with green vertical and red horizontal. The Canalrow used on the Waterways Template has now removed the -u from ugmKRZo, so it becomes the same as gmKRZo.
As far as I can see, there are 8 pairs of icons that are affected by this. They are:
  (ugKRZo) and   (gKRZo)
  (uxgKRZo) and   (xgKRZo)
  (ugKRZu) and   (gKRZu)
  (uxgKRZu) and   (xgKRZu)
  (ugmKRZo) and   (gmKRZo)
  (uxgmKRZo) and   (xgmKRZo)
  (ugmKRZu) and   (gmKRZu)
  (uxgmKRZu) and   (xgmKRZu)
My suggestion above for resolving this was to use two letters, one for the vertical direction and the other for the horizontal. So for blue vertical over green horizontal it would be ugKRZo and for green vertical over blue horizontal it would be guKRZo. I am not sure where the -x would go for the green/light blue, since we currently have   (uKRZo) and   (uxKRZo) (that is, -x comes after the -u) and   (mKRZo) and   (xmKRZo) (that is, -x comes before the -m). If this scheme was accepted, it seemed that the naming of the mixed colour ABZ junction icons could also use it, to make the naming a lot more obvious. Bob1960evens (talk) 22:20, 12 April 2013 (UTC)
over & under[edit]

Here's what I've found so far:

over

o     ex   u   uex   f   fex   g   gex
    (KRZo)   (xKRZo)   (umKRZo)   (uxmKRZo)   (fmKRZo) BSicon STRq.svgBSicon BRIDGE.svgBSicon fexSTR.svg   (ugmKRZo) BSicon STRq.svgBSicon BRIDGE.svgBSicon gexSTR.svg
  ex   (eKRZo)   (exKRZo)   (uemKRZo)   (uexmKRZo) BSicon exSTRq.svgBSicon BRIDGE.svgBSicon fSTR.svg BSicon exSTRq.svgBSicon BRIDGE.svgBSicon fexSTR.svg   (uxgmKRZo) BSicon exSTRq.svgBSicon BRIDGE.svgBSicon gexSTR.svg
  u   (mKRZo)   (xmKRZo)   (uKRZo)   (uxKRZo) BSicon uSTRq.svgBSicon BRIDGE.svgBSicon fSTR.svg BSicon uSTRq.svgBSicon BRIDGE.svgBSicon fexSTR.svg   (gKRZo) BSicon uSTRq.svgBSicon BRIDGE.svgBSicon gexSTR.svg
  uex   (emKRZo)   (exmKRZo)   (ueKRZo)   (uexKRZo) BSicon uexSTRq.svgBSicon BRIDGE.svgBSicon fSTR.svg BSicon uexSTRq.svgBSicon BRIDGE.svgBSicon fexSTR.svg   (xgKRZo) BSicon uexSTRq.svgBSicon BRIDGE.svgBSicon gexSTR.svg
  f   (mfKRZo) BSicon fSTRq.svgBSicon BRIDGE.svgBSicon exSTR.svg   (ufKRZo) BSicon fSTRq.svgBSicon BRIDGE.svgBSicon uexSTR.svg   (fKRZo) (f) BSicon fSTRq.svgBSicon BRIDGE.svgBSicon fexSTR.svg (fx) BSicon fSTRq.svgBSicon BRIDGE.svgBSicon gSTR.svg BSicon fSTRq.svgBSicon BRIDGE.svgBSicon gexSTR.svg
  fex BSicon fexSTRq.svgBSicon BRIDGE.svgBSicon STR.svg BSicon fexSTRq.svgBSicon BRIDGE.svgBSicon exSTR.svg BSicon fexSTRq.svgBSicon BRIDGE.svgBSicon uSTR.svg BSicon fexSTRq.svgBSicon BRIDGE.svgBSicon uexSTR.svg BSicon fexSTRq.svgBSicon BRIDGE.svgBSicon fSTR.svg (fe) BSicon fexSTRq.svgBSicon BRIDGE.svgBSicon fexSTR.svg (fex) BSicon fexSTRq.svgBSicon BRIDGE.svgBSicon gSTR.svg BSicon fexSTRq.svgBSicon BRIDGE.svgBSicon gexSTR.svg
  g   (gmKRZo)   (xgmKRZo)   (ugKRZo)   (uxgKRZo) BSicon gSTRq.svgBSicon BRIDGE.svgBSicon fSTR.svg BSicon gSTRq.svgBSicon BRIDGE.svgBSicon fexSTR.svg BSicon gSTRq.svgBSicon BRIDGE.svgBSicon gSTR.svg (g) BSicon gSTRq.svgBSicon BRIDGE.svgBSicon gexSTR.svg (gx)
  gex BSicon gexSTRq.svgBSicon BRIDGE.svgBSicon STR.svg BSicon gexSTRq.svgBSicon BRIDGE.svgBSicon exSTR.svg BSicon gexSTRq.svgBSicon BRIDGE.svgBSicon uSTR.svg BSicon gexSTRq.svgBSicon BRIDGE.svgBSicon uexSTR.svg BSicon gexSTRq.svgBSicon BRIDGE.svgBSicon fSTR.svg BSicon gexSTRq.svgBSicon BRIDGE.svgBSicon fexSTR.svg BSicon gexSTRq.svgBSicon BRIDGE.svgBSicon gSTR.svg (ge) BSicon gexSTRq.svgBSicon BRIDGE.svgBSicon gexSTR.svg (gex)

under

u     ex   u   uex   f   fex   g   gex
    (KRZu)   (xKRZu)   (umKRZu)   (uxmKRZu)   (fmKRZu) BSicon fexSTR.svgBSicon BRIDGEq.svgBSicon STRq.svg   (ugmKRZu) BSicon gexSTR.svgBSicon BRIDGEq.svgBSicon STRq.svg
  ex   (eKRZu)   (exKRZu)   (uemKRZu)   (uexmKRZu) BSicon fSTR.svgBSicon BRIDGEq.svgBSicon exSTRq.svg BSicon fexSTR.svgBSicon BRIDGEq.svgBSicon exSTRq.svg   (uxgmKRZu) BSicon gexSTR.svgBSicon BRIDGEq.svgBSicon exSTRq.svg
  u   (mKRZu)   (xmKRZu)   (uKRZu)   (uxKRZu) BSicon fSTR.svgBSicon BRIDGEq.svgBSicon uSTRq.svg BSicon fexSTR.svgBSicon BRIDGEq.svgBSicon uSTRq.svg   (gKRZu) BSicon gexSTR.svgBSicon BRIDGEq.svgBSicon uSTRq.svg
  uex   (emKRZu)   (exmKRZu)   (ueKRZu)   (uexKRZu) BSicon fSTR.svgBSicon BRIDGEq.svgBSicon uexSTRq.svg BSicon fexSTR.svgBSicon BRIDGEq.svgBSicon uexSTRq.svg   (xgKRZu) BSicon gexSTR.svgBSicon BRIDGEq.svgBSicon uexSTRq.svg
  f   (mfKRZu) BSicon exSTR.svgBSicon BRIDGEq.svgBSicon fSTRq.svg BSicon uSTR.svgBSicon BRIDGEq.svgBSicon fSTRq.svg BSicon uexSTR.svgBSicon BRIDGEq.svgBSicon fSTRq.svg BSicon fSTR.svgBSicon BRIDGEq.svgBSicon fSTRq.svg BSicon fexSTR.svgBSicon BRIDGEq.svgBSicon fSTRq.svg BSicon gSTR.svgBSicon BRIDGEq.svgBSicon fSTRq.svg BSicon gexSTR.svgBSicon BRIDGEq.svgBSicon fSTRq.svg
  fex BSicon STR.svgBSicon BRIDGEq.svgBSicon fexSTRq.svg BSicon exSTR.svgBSicon BRIDGEq.svgBSicon fexSTRq.svg BSicon uSTR.svgBSicon BRIDGEq.svgBSicon fexSTRq.svg BSicon uexSTR.svgBSicon BRIDGEq.svgBSicon fexSTRq.svg BSicon fSTR.svgBSicon BRIDGEq.svgBSicon fexSTRq.svg BSicon fexSTR.svgBSicon BRIDGEq.svgBSicon fexSTRq.svg BSicon gSTR.svgBSicon BRIDGEq.svgBSicon fexSTRq.svg BSicon fexSTR.svgBSicon BRIDGEq.svgBSicon gexSTRq.svg
  g   (gmKRZu)   (xgmKRZu)   (ugKRZu)   (uxgKRZu) BSicon fSTR.svgBSicon BRIDGEq.svgBSicon gSTRq.svg BSicon fexSTR.svgBSicon BRIDGEq.svgBSicon gSTRq.svg BSicon gSTR.svgBSicon BRIDGEq.svgBSicon gSTRq.svg BSicon gexSTR.svgBSicon BRIDGEq.svgBSicon gSTRq.svg
  gex BSicon STR.svgBSicon BRIDGEq.svgBSicon gexSTRq.svg BSicon exSTR.svgBSicon BRIDGEq.svgBSicon gexSTRq.svg BSicon uSTR.svgBSicon BRIDGEq.svgBSicon gexSTRq.svg BSicon uexSTR.svgBSicon BRIDGEq.svgBSicon gexSTRq.svg BSicon fSTR.svgBSicon BRIDGEq.svgBSicon gexSTRq.svg BSicon gexSTR.svgBSicon BRIDGEq.svgBSicon fexSTRq.svg BSicon gSTR.svgBSicon BRIDGEq.svgBSicon gexSTRq.svg BSicon gexSTR.svgBSicon BRIDGEq.svgBSicon gexSTRq.svg

Useddenim (talk) 00:21, 13 April 2013 (UTC)

Well, I'm on record for saying I have issues with icons differentiated by order of prefix/suffix. Out of the front prefixes, 3 already appear as suffixes (x,t and h). If the project to generalise capital R/L for "continuations" (and possible dashed versions for "half features" like the mess that the {  (BHFrf)), then that frees the use of -m for distinguishing these icons (we could start it right now since there would be no overlap between KRZ and the various other icons using -m). Ideally we'd fix the m-/um- thing across the board, since it can clearly no longer be consistent once you start adding new off-color prefixes. Circeus (talk) 07:37, 13 April 2013 (UTC)
I note from the table below that others have already used the two letter solution, for   (fmKRZo) /   (mfKRZo) and   (fmKRZu) /   (mfKRZu). I don't mind what the solution is, so long as it is relatively easy to remember which icon is which, and personally, I think the two letters make it very easy. It could easily cope with all the gaps in the table below, if in due course, footpaths need to cross canals, for instance. Bob1960evens (talk) 09:55, 13 April 2013 (UTC)
My proposal amounts to splitting m-/um- into two: m-(+u/g/f) indicated mixed icons, and -m indicates reversed color priority (since this makes it clear what colors are intersecting, it will also fix the weirdness that   (gKRZo) vs.   (gmKRZo) is...):
  •   (mfKRZo) /   (fmKRZo)  (fmKRZo) /   (fmKRZom)
  •   (gmKRZo) /   (ugmKRZo)  (gmKRZo) /   (gmKRZom)
  •   (mKRZo) /   (umKRZo)  (umKRZo) /   (umKRZom)
  •   (ugKRZo) /   (gKRZo)  (ugmKRZo) /   (ugmKRZom)
Alternatively, making a m- variant with a plus or dash is an option (but still doesn't remove the need for always including a color prefix in a mixed icon):   (umKRZo) /   (um+KRZo). Whatever happens, the "elegant" m/um- system cannot, for long-term sanity's sake, be kept. Circeus (talk) 03:34, 14 April 2013 (UTC)

Two Three Four annotations:

  1. For downgrade compatibility (i.e. the "BS(u)e" templates) the order of prefixes has to be u-e-x-...<rest>.
  2. I marked some icons with light red background, they're named inconsistently:
    1. red/green has "(x)gm"-prefix, but ...
    2. green/red has "u(x)gm"-prefix - why the "u"? There is no blue line!
    3. blue/green has "u(x)g"-prefix, but ...
    4. green/blue has "(x)g"-prefix, why no "u"? There is a blue line
    Regards a×pdeHello! 08:29, 14 April 2013 (UTC)
  3. If "fm" indicates "footpath with heavy rail across" and "mf" indicates "heavy rail with footpath across", then for consistency reasons "mg" should be indicating "heavy rail with unwatered canal across" and vice versa. a×pdeHello! 08:41, 14 April 2013 (UTC)
  4. Do we really need four different shades of green? I proposed "unwatered canal" to be the ex color of "footpath". Then we'd save nearly 44% of the icons above (36 instead of 64 icons). a×pdeHello! 08:48, 14 April 2013 (UTC)
  1. The order of prefixes was, is and should remain [u|f|g] [ex|e|x]..., at least for single-colour icons. We do not establish colour hierarchy here.
  2. For multi-coloured icons, I could go any which way, although again I would prefer interchangeability between "u", "g" and "f". Templates can be rewritten or substituted with other templates if needed.
    1. (& 3.) I'm not sure what you mean...
    2. (& 4.) You're 100% right.
  3. Certainly.
  4. Well, they are certainly distinguishable colours, as well as jade/53B147 and green/2DBE2C below. I can assure you, some people (Туча for instance) would want their lines painted with precisely this shade of green and not another - and they have full right to do so. Let's hope no railway / subway in any country assigns official RGB to their lines.
  5. Maybe it would be better to drop ex/e/x distinction for multi-coloured icons? We could have "um", "uxm", "xum", "xuxm" (or "exum"), "mu", "mxu", "xmu", "xmxu" (or "exmu"), "ug", "uxg", "xug", "xuxg (or "exug"), "gu", "gxu", "xgu", "xgxu" (or "exgu"), plus 32 remaining combinations.
--YLSS (talk) 09:16, 14 April 2013 (UTC)
-x is already used as a "suffix" in combination with -l and -r. Using it on KRZ like -t and -h already are (cf.   (KRZh),   (KRZt) etc.) shouldn't cause much problems? Nonetheless I think multiplying x's here is not needed: the e/x/ex thing is very well established and not in need of messing with. Circeus (talk) 19:22, 14 April 2013 (UTC)
So, combining the last two points would give um- for blue/red, with eum- xum- and exum- covering the four combinations of used/disused; mu- for red/blue, again with emu- xmu- and exmu-; mg- and xmg- for red/green canal; gm- and egm- for green canal/red; fm- and efm- for green path/red; and mf- and xmf- for red/green path. This ignores the fex and gex columns above, as they are currently unpopulated, and certainly for the green canal set, I cannot see what gex would mean. g- already means the canal is unused because it is destroyed. The distinction between a destroyed canal and an unused destroyed canal is a bit esoteric. This scheme is extendible, as footpaths crossing canals would use uf- and fu-, and could be applied to the ABZ multi-coloured icons as well. Bob1960evens (talk) 22:49, 14 April 2013 (UTC)
Basically, g- becomes a normal color prefix, with the "meaning" g- getting grandfathered in. Canal icons will never use gex-, but anywhere else this end up being used, the option will exist. We COULD make the current g- shade an ex- color, but then all the canal icon using it would gain an extra -x, and I don't think people wish for that. I'm still on the book for opposing the whole "inverting prefix order" idea, but I'll not go unnecessarily against consensus. Circeus (talk) 04:07, 15 April 2013 (UTC)
@Bob: Ideed, we don't need ex-ex-canals, and yet noone asked for ex-footpaths, so it's a question of how much work do we want to do! We could save 44% of the icons in the matrix above, simply because they're not needed ... a propos ...
@Circeus: Just having an option that someday someone will make use of ex-ex-canals or ex-footpaths bears no reason to create dozens of extra icons not needed now (and probably never). With the sets of "f/g", "jade" and "green" we have six different shades of green, that should be enough for the moment! a×pdeHello! 20:39, 15 April 2013 (UTC)
Ahem, the "g"-set is used for Zamoskvoretskaya line of Moscow Metro at fr.wp (ru.wp uses the "f"-set, but it looks less like the colour on official maps), and that line is gonna have three new stations in two year's time, which is presently shown using "gex" icons. Plus it is used for Buffalo Metro Rail, which has a former station. "Green" set is used for Sofia metro, and AFAIK their system is presently breaking records in constructing new lines and stations; additionally it is used for a Helsinki bus line. The "jade" set is a new one and is only inherited by the Berlin metro, but likewise it has all the chances to spread far and wide. The main point is that it is not "ex-ex-canals", it is just "g"-set with #2CA05A as its RGB; it could have been called "emerald", but we're pretty content with leaving it as "g". YLSS (talk) 21:50, 15 April 2013 (UTC)

<undent> What about this naming format:

Through
line
Line
status
Mixed
type
Crossing
line
KRZ Separation
 /u/f/g  /e/x/ex m u/f/g KRZ /o/u

I realize this is somewhat similar to Circeus' proposal, but I think it's a little clearer (and can also be easily applied to ABZ icons). Current red/blue icon names need not be changed. Useddenim (talk) 21:38, 14 April 2013 (UTC)

Our problem "g" icons then become

current   (gmKRZo)   (xgmKRZo)   (ugKRZo)   (uxgKRZo)   (ugmKRZo)   (uxgmKRZo)   (gKRZo)   (xgKRZo)
proposed
Useddenim   (mgKRZo)   (xmgKRZo)   (umgKRZo)   (uxmgKRZo)   (gmKRZo)   (gemKRZo)   (gmuKRZo)   (gemuKRZo)
Bob1960evens   (mgKRZo)   (xmgKRZo)   (ugKRZo)   (xugKRZo)   (gmKRZo)   (egmKRZo)   (guKRZo)   (eguKRZo)
Circeus   (gmKRZo)   (?)   (ugmKRZo)   (?)   (gmKRZom)   (?)   (ugmKRZom)   (?)
axpde   (mgKRZo)   (xmgKRZo)   (ugKRZo)   (uxgKRZo)   (gmKRZo)   (egmKRZo)   (guKRZo)   (eguKRZo)
YLSS   (mgKRZo)   (mgxKRZo)   (ugKRZo)   (ugxKRZo)   (gmKRZo)   (gmeKRZo)   (guKRZo)   (gueKRZo)
Consensus?   (mgKRZo)
by 4:1
  (xmgKRZo)
by 3:1
  (ugKRZo)
by 3:1:1
    (gmKRZo)
by 4:1
  (egmKRZo)
by 2:1:1 ...
  (guKRZo)
by 3:1:1
  (eguKRZo)
by 2:1:1 ...
I have altered some of the names on the Bob1960evens row in line up with my proposals above. The first letter of the two would always be the primary vertical line, with the second for the secondary horizontal. The x- is used when the vertical line is an ex colour, and the e- is used when the horizontal line is an ex colour. If we go for ex greens as well, then ex- would also be used. Bob1960evens (talk) 14:44, 16 April 2013 (UTC)
I prefer Bob1960evens's proposal. It's the most elegant one. YLSS (talk) 15:56, 16 April 2013 (UTC)
Do we have a concensus yet? The Bob1960evens row and Axpde row are almost the same, apart from xugKRZo / uxgKRZo, where the x- appears between the two letters, rather than before them. I am happy with either, providing that the usage is consistent. I would prefer it if the m- was also used consistently. At the momemt, the Useddenim row mgKRZo uses m- to mean railway, but gmuKRZo uses m- to mean mixed. I think the second usage is superfluous, since the u- and g- already indicate that there are two colours. Bob1960evens (talk) 13:33, 20 April 2013 (UTC)
Added a row of my own. Rationale: if we do not drop the e/x/ex distinction for these, then there is little purpose inserting these prefixes between colour prefixes: everything is said by which prefix is used, not by where it is placed. It would also be inconsistent to place them at the front, since the already established practice is [u|f|g][e|x|ex]. So IMO we could have {vertical/main colour}{horizontal/side colour}[e|x|ex]ROOT. Opinions? (How are we to reach a consensus, now that nearly everyone has made a proposal of his own?) YLSS (talk) 00:13, 30 April 2013 (UTC)
I am happy for the [e|x|ex] to go between the two colour prefixes and the root, rather than at the start, providing the usage is consistent. I have not altered my row yet, as if I did, there would be two common names in column 4, but less common names in columns 2, 6, and 8. In view of YLSS's comment above, can we agree that the [e|x|ex] should come after the colour prefixes? If we could, I think there would almost be a concensus. Looking at the table above, axpde's uxgKRZo appears to be inconsistent, since the x has moved to between the colours, whereas rows 2, 6 and 8 have e|x at the beginning. Is this a typo? Bob1960evens (talk) 22:12, 4 May 2013 (UTC)
In german wikipedia we still make use of Template:BSu, Template:BSe and Template:BSue, therefore the prefixes "u" and "e" must come first. The standard prefix order has always been u-e-x-m-g-... a×pdeHello! 22:30, 5 May 2013 (UTC)
This makes the problem unsolvable, since most suggestions involve using u|g and g|u to distinguish which is the vertical line, and which is the horizontal, and we cannot maintain u-e-x-m-g- and reverse the orders of u|m|g as appropriate. I note that axpde's column 8 shows eguKRZo, where this order has not been followed, and the only way to achieve a solution is for some of the existing rules to bend. I still think we need to resolve whether the order should be [u|m|g]-[e|x|ex] or [e|x|ex]-[u|m|g]. We now seem to have suggestions that both are how it currently works. The only other possibility I can think of is to change the u- to some other letter, so that it is obvious that it is not being used in quite the same way as it was.
I am struggling to see exactly how the Template:BSu etc templates work, but unless they are going to be used with the green icons, does it matter that the order changes? Bob1960evens (talk) 16:40, 6 May 2013 (UTC)
Well, "g"-type icons are rather seldom used in dewiki, that's why I made an unordinary suggestion. The Template:BSe e.g. does not only add "e" at the beginning of the icon name, it sets italic and grey text color as well. a×pdeHello! 21:15, 6 May 2013 (UTC)
┌─────────────────────────────────┘
Summary
  • Because of icons like uexKRZo, some believe that [ex] is always after the colour prefix.
  • Because of icons like exmKRZo, some believe that [ex] is always before the colour prefix.
  • German wiki use BSe templates, which require the prefix order to be as it is.
  • German wiki does not use the g icons in BSe templates.
  • We cannot have a new naming scheme and keep the existing order of prefixes.
  • The muddle over prefixes is the reason this discussion is taking place.
If the order is fixed, then the only possibility that I can see is to use some new prefixes for these combinations, so use b[ahn] instead of m[ixed], or c[anal] instead of g[reen], or somesuch. (I have no idea if these prefixes are already used.) That would allow BSe templates to be reworked to cope with the new prefixes. In the meantime it is getting a bit tedious as the Canalrow and Plainrow templates have been reworked without the corresponding reworking of the names, so it is difficult to find the name of appropriate green icons when producing route maps. I can often guess, but newer editors may not know the history. Is it appropriate to ask Circeus how he might name the four missing icons in the table above? There seems to be more concensus on icons that do not use [ex] than on those that do. Bob1960evens (talk) 08:21, 2 June 2013 (UTC)
Both "b" and "c" are used currently, for double-width and quarter-width icons (although admittedly there are relatively few of each type and they are rarely used). I'm against introducing any new prefix for canals, especially since that won't solve the problem; and I don't think there would be any benefit in case of "m". The simplest solution with templates will be to create additional "BSum", "BSume" templates and/or add parameters to existing templates. The only thing that restrains me now, actually, is the mess with canal roots. This should be discussed at Talk:BSicon/Renaming, however, and any imput will be appreciated. YLSS (talk) 08:59, 2 June 2013 (UTC)
I am not keen on new prefixes either, but we cannot rename the icons and keep the existing order of the prefixes, and at the moment there seems to be no agreement as to whether the [ex] prefixes should be placed before of after the [gum] prefixes. The suggestion was to try and break the impasse. Bob1960evens (talk) 12:13, 2 June 2013 (UTC)
Icon review[edit]
This section is for discussion about improving the integration of canal icons in the broader BSicon system
moved to Talk:BSicon/Renaming#Canal & footpath roots

Lines with multiple colors[edit]

Argh, I just can't stand those multicolour icons... Really, that's what overlays were introduced for. I do understand multicolorness in such cases as set yellow-blue and set black-orange (though even they could possibly be replaced by parallel lines), but such instances as CC6600+smth should be purged. If they are really used only in ru:Шаблон:Линия U4 (Вена) & ru:Шаблон:Линия U6 (Вена), then we'd better rewrite those templates and delete these icons. YLSS (talk) 14:17, 4 March 2013 (UTC)

I agree with you that these icons should not be necessary, and that the projects and articles using them would be better edited to include standard icons instead, making use of overlays if necessary. However, that’s what we do as wikipedia editors — here now, as commons editors, our job, I think, should be more “conservative”. I want to be able to provide a solid and simple naming system for multiple color icons (since some do exist), even if it is scarcely used. Let nobody say (as some times it is said, even about normal-red icons) that such-and-such icon should not be created/uploaded/used because we cannot figure out how to name it! -- Tuválkin 15:10, 4 March 2013 (UTC)

Elsewhere, there are several singleton cases that can be readily deleted as unused:   (eABZlf 339999 and green),   (xKBFa orange violet),   (xKBFa 99CCFF),   (xKBFe 99CCFF),   (eKRZ vert exjaune). There is Category:Icons for railway descriptions/set green/mixed, which probably can stand, but I'm not happy with names... YLSS (talk) 14:17, 4 March 2013 (UTC)

I think it is better to analyze each case within their kin — most of those seem to be unfortunate attempts at "ex" variants, and they could be recolored as such, allowing them to enrigh the existing sets. -- Tuválkin 15:10, 4 March 2013 (UTC)
I’m going to have a try at renaming the icons at Category:Icons for railway descriptions/set green/mixed, using the ideas below. I expect it to be mostly trivial, with obvious analogy "f" to "u". -- Tuválkin 04:29, 14 March 2013 (UTC)

Bilbao’s black+orange[edit]

replace this …with this …or this
BSicon ABZlg black-orange.svg
BSicon BHF black-orange.svg
BSicon tSTR black-orange.svg
BSicon HST black-orange.svg
BSicon INT black-orange.svg
BSicon STR black-orange.svg
BSicon BHF black-halforange.svg
BSicon vSTRg+r orange+black.svg
BSicon mvBHF black+orange.svg
BSicon mvtSTR black+orange.svg
BSicon mvHST black+orange.svg
BSicon mvINT black+orange.svg
BSicon mvSTR black+orange.svg
BSicon mvBHF-BHFe black+orange.svg
BSicon STRlg black.svg
BSicon STR orange.svg
BSicon STR Lblack-orange.svg
BSicon BHF orange.svg
BSicon tSTR black-orange.svg
BSicon STR Lblack-orange.svg
BSicon HST orange.svg
BSicon lINT.svg
BSicon STR Lblack-orange.svg
BSicon STR Lblack-orange.svg
BSicon .svg
Green-gel-x.png axpde

Here’s → my suggestion to make these ususual longitudinally split bicolor icons conform to our usual practices: Using "v" icons (“close parallel lines”), which are often used in diagrams to show two separate services running on the same physical track, which is this case: I think these replacements, even if done blindly, would fit neatly the diagram in which they are use, with no need for further tweaks. Opinions? -- Tuválkin 05:42, 21 March 2013 (UTC)

I was going to propose the same, for this set and also for set yellow-blue (pending on which blue to use). Only, I think the icons to the right should've been rather uploaded above those to the left to preserve history, right? YLSS (talk) 07:33, 21 March 2013 (UTC)
Yes, uploaded, then renamed. That way the history is preserved (which is kinda bogus, as these are completely different vectrosets, but still), and the replacement of the icons in use is smoothed out. (Agreed about the blue+yellow set.) -- Tuválkin 11:43, 21 March 2013 (UTC)
Hm, strike that. I already uploaded them, so now’s better to propose deletion based on agreed-upon semantic equivalence, after replacement of the usage. Bummer. Oh, well, there is no actual historical connection from each to the other in “artistic” terms, anyway… -- Tuválkin 11:46, 21 March 2013 (UTC)
Useddenim uploaded 4 more icons to this peculiar set:
  •   (STR black-orange)  and   (tSTR black-orange) improves the looks of the Bilbao diagram at wp:en and wp:es (not used in the diagram of wp:eu, note), and are trivially adaptable (see new ones here →), but
  •   (STR black-Lorange) and   (STR Lblack-orange) are pretty baffling.
-- Tuválkin 22:29, 22 March 2013 (UTC)
It was part of an experiment. See en:Template:District Line RDT for an example of their intended usage. (And I thought their naming was clear enough.) Useddenim (talk) 01:10, 24 March 2013 (UTC)

The fact is that you want to change looks much better than what is proposed for replacement. --Туча (talk) 08:23, 24 March 2013 (UTC)

Unless I'm interpreting it wrongly,   &   imply both services on the same line, while   suggest adjacent lines. Useddenim (talk) 16:30, 7 April 2013 (UTC)

Water colors[edit]

By origin, as I understand it, water color is based upon a railtrack crossing:   (WASSER) 00 #007cc3 (light blue), and afterwards we use the "u" (underground) prefix & color to signify navigable water:   (uSTR) 00 #003399 (dark blue). All fine so far (except when one wants to show the New York underground after the Sandy water flow ;-) ). Now there enters a third shade of blue: the disused underground track:   (uexSTR) 00 #6281c0 (another light blue).
My question is: what (lighter blue) color do we use for non-navigable water?

  • 00 #007cc3 (light blue 1)   (WASSER)
  • 00 #6281c0 (light blue 2)   (uexSTR)

-DePiep (talk) 21:12, 25 November 2012 (UTC)

WASSER serves a different purpose than the uexSTR icons as used by canal projects. Obviously we need both available because uexSTR means "former light-rail track" in railway icons, which has nothing to do with water whatsoever. Circeus (talk) 16:03, 26 November 2012 (UTC)
Yes, is what I wrote. Still. uSTR has to do with water (by BSicon usage evolution). If uSTR is used for water, then uexSTR is in it too. Alternative: reproduce all uexXXX and uXXX for water (WASSER and NAVIGATABLEWASSER) in a full separate set. -DePiep (talk) 21:20, 26 November 2012 (UTC)
Whether we like it or not,   (WASSER) and   (uexSTR) are used for the same (unused/unnavigable water). What to do? -DePiep (talk) 23:25, 27 November 2012 (UTC)
Nothing. When they start being actually used in conflicting way (Which I don't see happening any time soon), someone will bother coming up with an actual proposal. And I say that as someone who worked for a couple month on an all-encompassing naming scheme and at no point whatsoever considered that this could possibly be an issue whatsoever. Circeus (talk) 01:13, 28 November 2012 (UTC)
They are. Seriously, I claim. See my note on the Panama Canal, below. -DePiep (talk) 23:04, 28 November 2012 (UTC)
As I understand,   (WASSER) and   (uexSTR) are not (or should not be) used to represent the same. The wavy icons of the   (WASSER) family stand for “natural” non-navigable streams (or any body of water in most railway diagrams), while the   (uexSTR) family is the disused/planned form of   (uSTR), which stands for navigable water: i.e., canals and river or sea routes and their facilities (including dregways, seamarks, etc.). -- Tuválkin 01:31, 28 November 2012 (UTC)
Good description. Problem left is that the shades of blue are too close to call the difference (and associate to a correct legend), while being too apart so that they give a difference (noticable to the eye). IOW: we cannot use them significantly in the same diagram. See also my conclusion below. -DePiep (talk) 12:18, 4 December 2012 (UTC)
Arguably uex icons CAN represent "nonnavigable water" but only because there is navigable or formerly navigable water involved in the diagram. Circeus (talk) 02:35, 28 November 2012 (UTC)
The colors for "non navigable" and "planned" waterways are too close to be used as two legend meanings. For the moment I forget about a difference between "planned navigable" and "planned nonnavigable" waterway ;-). -DePiep (talk) 16:35, 28 November 2012 (UTC)
What are you going about with "planned waterways"? Those are represented by L-/LUECKE icons! Circeus (talk) 18:15, 28 November 2012 (UTC)
Are they? Maybe in the canals projects, but in railways diagrams LUECKE usually indicates stretches and connections that are not detailed in “this” diagram (and may be so in others). Planned is "ex" in railways diagrams in most Wikipedias. -- Tuválkin 19:18, 28 November 2012 (UTC)
That would still allow for "planned waterway" needed, so {{{1}}} prefix. -DePiep (talk) 12:18, 4 December 2012 (UTC)
It is not a theoretical question. It all came together when I described the plumbing of the Panama Canal by BSicon [1]. navigable/nonnavigable, actual/planned. I decided to use green   (ugSTR) for the "planned" part. warning/friendly advise: I prefer the current solution. -DePiep (talk) 22:52, 28 November 2012 (UTC)
Are you aware that ug- icons (as far as I understand the Canal project's guidelines) mean not only nonnavigable but unwatered/destroyed sections of a canal? Ultimately, this sort of pointless argumentations can be dealt with easily using the same trick as used here if you REALLY thing the stuff is genuinely confusing. Circeus (talk) 15:29, 29 November 2012 (UTC)
I like the linked trick (add individual legend to the map), which allows for individual color usage. I do not like C. first saying "When they start being actually used in conflicting way", and then when I do provide an existing conflicting usage, changing to "this sort of pointless argumentations". Next argument being problem does not exist because planned waterways do not exist? -DePiep (talk) 12:18, 4 December 2012 (UTC)

┌─────────────────────────────────┘
I conclude, that there is no suitable parallel (that can be made) in the scheming & naming between tracks and waterways. Both color and prefix/suffix standards can differ. I'll have to go with that. -DePiep (talk) 12:18, 4 December 2012 (UTC)

Despite the comment:   (WASSER) and   (uexSTR) are not (or should not be) used to represent the same, they clearly are. I dislike the Wasser set, because they make the maps look so amateurish, but on maps like en:Template:Neath and Tennant Canal map, someone has changed most of the original uexSTR icons to xWasser icons, but not all, because there are several where an equivalent xWasser icon does not exist. In my opinion, it makes the map look really messy. Bob1960evens (talk) 22:42, 10 April 2013 (UTC)
Not really wanting to throw gasoline onto the fire, but what does   (WASSER) signify differently from   (xWASSER)?
P.S. en:Template:Neath and Tennant Canal map Pictogram voting keep.svg Fixed. Useddenim (talk) 00:46, 12 April 2013 (UTC)
IMHO   (WASSER) should only be used for natural watercourses,   (uexSTR) only for unnavigable artificial waterways. This raises the question what   (xWASSER) stands for ...
And yes, some WASSER icons are very poorly drawn, maybe I'll redraw some of them. a×pdeHello! 08:56, 12 April 2013 (UTC)
WASSER set redrawn and expanded;   (xWASSER) et. al. nominated for deletion. Useddenim (talk) 21:20, 13 May 2013 (UTC)

Proceedings[edit]

I created Category:Icons for railway descriptions/obsolete colors for those sets and individual icons whose usage has already been replaced by other sets/icons. At some later point they should be nominated for deletion en masse. YLSS (talk) 12:59, 6 March 2013 (UTC)

I don’t agree with that exact procedure (although I agree with the general idea): I think it is better to alter the RGB in the affected files and recategorize them if necessary, and then rename them (which is trivial for unused files). That would leave out needing to be deleted only actual duplicates.
An example:   (HBHF jaune) can be slightly recolored to RGB:FFEB81 and renamed   (exBHFq_yellow), adding to the yellow set an icon it currently lacks; on the other hand, things like   (STR A9A9AA) can be safely deleted (after usage replacement) as its equivalent   (STR grey) already existed. (This goes for almost all of the icons in/under obsolete colors, except for the weird yellow / add red‎ set, which is useless.)
But there’s the need to discuss (or at least document) several special cases. F.i., while Berlin’s U5 and the other #Browns were agreed to be merged and while   (uBHF BlnU5) and   (uKBHFe BlnU5) do have preexisting equivalents in the brown set, there is the question wheather the special Berlin names should be kept as redirects (ditto for Moscow, Kuala Lumpur, and Tokyo). That is a matter that should be addressed, and no Berlin or other such icons should be deleted untill we reach agreement.
-- Tuválkin 16:03, 6 March 2013 (UTC)
I do follow the procedure you describe - cf. Category:Icons for railway descriptions/set grey, - although somewhat retroactively (now that I've got myself filemover rights). On redirects from Tokyo etc. names - I must've misunderstood your proposals earlier. OK, nothing will be deleted. YLSS (talk) 16:37, 6 March 2013 (UTC)

Some colour names[edit]

Moscow metro legend

It seems that a new map that is planned to show up in Moscow Metro (but only planned as yet) will have all lines labelled with colour words in both Russian and English, to help visually impaired. (See [2].) So we'll officially have red, green, blue, light blue, (brown), orange, purple, yellow, grey, lime, teal and blue grey lines. What a crazy random happenstance, as one en.wp user used to call himself. YLSS (talk) 20:29, 14 March 2013 (UTC)

  • There were about the same colors on the diagrams of the Moscow metro twenty and thirty years ago. There are difference only in nuances. Lines are very often called by their colors, not their names. What is a crazy random happenstance?--Туча (talk) 05:15, 18 March 2013 (UTC)
    • He means that it's an incredible coincidence. i.e. that this official renaming be now discussed/mentioned right as we are discussing issues of naming colors of the Moscow metro. Circeus (talk) 05:37, 18 March 2013 (UTC)
  • But their orange is something between orange and saffron here. --Туча (talk) 09:20, 18 March 2013 (UTC)
    • Let's wait until any of this goes official before making any decisions. YLSS (talk) 09:59, 18 March 2013 (UTC)


"set blue" and "set green"[edit]

Moved to Talk:BSicon/Categorization.

Minimal sets[edit]

Set golden was so small it was useless, so I added a few icons to make it minimally functional:

BSicon BHF golden.svg BSicon KBHFa golden.svg BSicon KBHFe golden.svg BSicon INT golden.svg BSicon STRq golden.svg
BHF KBHFa KBHFe INT STRq

With these icons, diagrams like this can be easily built, mixing and overlaying with other such sets of different colors and with regular icons. -- Tuválkin 12:37, 2 April 2013 (UTC)

Layer 1: BHF, KBHFa, KBHFe (+ INT if is used customarily) - minimal
Layer 2: exBHF, exKBHFa, exKBHFe, KBHFxa, KBHFxe - to implement planned continuations etc. (plus an additional colour, actually)
Layer 3: STR, STRq, STRlf, STRrf, STRlg, STRrg (x2 for ex) - to implement any ABZs using overlaying
I've made sure these 20 are present in saffron, purple, teal, fuchsia, brown, grey, violet, yellow, lime, azure, cyan, ochre, red & green. YLSS (talk) 13:16, 2 April 2013 (UTC)

other color sets too thin[edit]

I was given the advice there exists other colors such as orange or saffron. Problem is these don't play well with the standard red, when it comes to overlays. Overlays are essential, since these other color sets are woefully incomplete.

But on an overlay, the color (such as saffron) does not completely cover up an underlying piece of standard track, for example. Why was these color tracks made thinner??

Example, 300% zoom from the en:Template:Mobile Grain page.

en:File:Colours BSIcon.png

As you can see, the red bleeds through (just below the blob of Davidson). CapnZapp (talk) 08:07, 6 November 2013 (UTC)

Yes, this is a nasty problem, I encounter it 24/7 (at least in 125%-zoomed Chrome), even in such trivial cases as when   (hABZgl+l) is overlayed with   (ABZgl+xl) and the vertical line thickens noticeably. This isn't an issue with the coding of   (STR saffron) or others, just a browser-end problem. I can only suggest using e.g.   (CONTf saffron) for the background layer, or if needed you can upload   (KSTRe saffron), which should look like this: BSicon .svgBSicon STR saffron.svgBSicon MASKe.svg  (track ending at the center of the icon). It is indeed fortunate that the colour is not messed up as well; when overlaying BSicon .svgBSicon STR2.svgBSicon RM.svg (MWSTRSTR2) , the red track show up through the yellow middle at the top; and unlike in your case, this doesn't go away if I reset zooming to 100%. YLSS (talk) 09:44, 6 November 2013 (UTC)

Dark brown[edit]

I was working on a diagram and realized that we don't have a dark brown set. So, I would suggest Category:Icons for railway descriptions/set chocolate with a colour of   4c3300  (which—if my math is correct—is 30% red 20% green). Useddenim (talk) 21:33, 5 January 2015 (UTC)

If you really need a dark brown colour, you may want to resurrect set 71592E and darken it a bit...
But possibly maroon would be a better idea. Do I understand right that it was you who chose #881210 for {{KLRT color|4}}? If that wasn't a random thought, I suggest that you proceed with it, or with #800000. Maroon is a substantially different hue from both brown and bahn, and I once wanted to introduce it myself (although now I can't recall what for...). YLSS (talk) 15:25, 6 January 2015 (UTC)
@Useddenim:: please check the ex-values, they seem to be too bright... Cf. violet → ex_violet. YLSS (talk) 19:51, 7 January 2015 (UTC)
@YLSS:: That's what the color picker tool came up with using 50% opacity over #f9f9f9 background. No icons have been uploaded yet, so the values can be changed. Useddenim (talk) 19:56, 7 January 2015 (UTC)
Well, it should be 60%, remember?.. Using a calculator, I get   928364  &   B16464 . YLSS (talk) 20:10, 7 January 2015 (UTC)

Pink[edit]

I'm looking to create a pink set as the ruby and fuchsia sets don't quite match what I want.

I got   E87EA6  and   EFAFC7  for the ex variant using the above method. Just wanted to get Some feedback/comments/concerns before proceeding. Lost on  Belmont 3200N1000W  (talk) 17:18, 18 February 2015 (UTC)

Yes, I also think that we need something lighter than fuchsia. (Tuválkin, sorry, your redirects will have to go!) But probably it would be better to choose some other shade, further away from magenta, and possibly a bit darker (to enhance contrast with ex). Something towards en:Brink pink   FB607F . How about   F0668D , ex =   F4A1B8 ? YLSS (talk) 19:06, 18 February 2015 (UTC)
I'll admit, I stole E87EA6, straight from the Chicago Transit Authority's Pink Line webpage, but I think   F0668D  and   F4A1B8  will work fine. I'll get started. Lost on  Belmont 3200N1000W  (talk) 19:25, 18 February 2015 (UTC)
For the record, here’s some numbers: The same assessment we did 2 yrs ago for the big color clean-up: Vectorial RGB distance to nearest neighbour in the w:en color list and in our own palette; correlates to how different (or not) it is from all other colors:
color RGB dist. to… (in w:en) RGB dist. to… (among BSicons) Remarks
E87EA6 18.708% Thulian pink 28,302% BSicon ex-ruby CTA pink
EFAFC7 16,310% Lavender pink 50,468% BSicon ex-grey ex-CTA pink
FB607F 00,000% Brink pink 20,833% BSicon ex-red YLSS’ suggestion #1
F0668D 18,788% Brink pink 25,671% BSicon ex-red YLSS’ suggestion #2
F4A1B8 06,557% Amaranth pink 57,801% BSicon ex-fuchsia ex-YLSS’ suggestion #2
Looks like all proposals are significatively different from anything we have, especially the "ex" versions. -- Tuválkin 00:00, 19 February 2015 (UTC)
I think adding pink is a good idea. No problem with the redirects I made a while ago for {{TramColors}} from "pink" (unexistent, then) to "ex ruby":
  •   (STRq_pink)
  •   (INTq_pink)
  •   (eINTq_pink)
The new shade looks better and will fit seamless in Category:Black_and_pink_trams and other such pages. -- Tuválkin 23:01, 18 February 2015 (UTC)
Oops, I had forgot about   (vSTR_pink) and the unused   (INT_pink). See also Category:Icons for railway descriptions/redirect/aliased colours, now only harbouring “silver”, as pink attained realhood. -- Tuválkin 01:12, 19 February 2015 (UTC)

What can I say guys... Congrats to ourselves! I think that was the swiftest inception of a set: 8 hours after the first thoughts were posted, we have a fully functional set, uploaded by three users! YLSS (talk) 01:24, 19 February 2015 (UTC)

New colour? (#0000ff)[edit]

There seem to be a number of Chinese metro lines (e.g. Tianjin Metro line 9 (diagram)) that use just flat RGB colours as their line colour. Since there isn't currently any bright blue (#0000ff) could we add this as "ultramarine" (or similar)? (Pinging Tuválkin, Lost on Belmont, YLSS, Useddenim.) Jc86035 (talkcontributionsuploads) 10:29, 3 February 2016 (UTC)

I think not:
  •   0000FF  is one of those lazy colors people pick from a simple-minded palette and don’t even think about it. It’s sad that “post-geek” computing apparently means to dismiss things like knowledge of HTML (or even wiki code!) but these nasty remains ot times long by gone (256-color screens, anyone?) are still around.
  • This color shade      is too “bright” (not pastel) to be adequate for a wikipedia page — I’m surprised this is in use in en:wp (where people are particularly fussy about this, and rightly so) and it wont probably last.
  • I don’t read the choice of   0000FF  as content-bearing while their use of   (blue) being a poor-man’s choice for lack of a more accurate shade of blue, but quite the opposite.
  • If a darker shade of blue is needed,   (denim) and   (u) are good enough.
-- Tuválkin 17:30, 3 February 2016 (UTC)
I tend to agree with Tuvalkin, unless you can make a more compelling argument. Useddenim (talk) 22:58, 3 February 2016 (UTC)
@Tuvalkin, Useddenim: Never mind. The actual line colour seems to be closer to   (u). Jc86035 (talkcontributionsuploads) 08:13, 4 February 2016 (UTC)