Talk:BSicon/Colors/Archive 2

Archive 1

Archive 2

Archive 3

Deriving the ex-shade given an RGB

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 File:BSicon dHUB25.svg . Useddenim (talk) 17:36, 1 March 2013 (UTC)

Testing half opacity with colors

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

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

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

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

Tokyo Hibiya

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

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

(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×p_de^Hello! 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

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

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

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

See also: en:Template talk:Waterways legend.

See also: Talk:BSicon/Categorization#Green icons.

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

File:BSicon uxgTRANSg.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

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

Here's what I've found so far:

over

o	—	ex	u	uex	f	fex	g	gex
—	(KRZo)	(xKRZo)	(umKRZo)	(uxmKRZo)	(fmKRZo)		(ugmKRZo)
ex	(eKRZo)	(exKRZo)	(uemKRZo)	(uexmKRZo)			(uxgmKRZo)
u	(mKRZo)	(xmKRZo)	(uKRZo)	(uxKRZo)			(gKRZo)
uex	(emKRZo)	(exmKRZo)	(ueKRZo)	(uexKRZo)			(xgKRZo)
f	(mfKRZo)		(ufKRZo)		(fKRZo) (f)	(fx)
fex					(fe)	(fex)
g	(gmKRZo)	(xgmKRZo)	(ugKRZo)	(uxgKRZo)			(g)	(gx)
gex							(ge)	(gex)

under

u	—	ex	u	uex	f	fex	g	gex
—	(KRZu)	(xKRZu)	(umKRZu)	(uxmKRZu)	(fmKRZu)		(ugmKRZu)
ex	(eKRZu)	(exKRZu)	(uemKRZu)	(uexmKRZu)			(uxgmKRZu)
u	(mKRZu)	(xmKRZu)	(uKRZu)	(uxKRZu)			(gKRZu)
uex	(emKRZu)	(exmKRZu)	(ueKRZu)	(uexKRZu)			(xgKRZu)
f	(mfKRZu)
fex
g	(gmKRZu)	(xgmKRZu)	(ugKRZu)	(uxgKRZu)
gex

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×p_de^Hello! 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×p_de^Hello! 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×p_de^Hello! 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×p_de^Hello! 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×p_de^Hello! 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×p_de^Hello! 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

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

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

replace this	…with this	…or this
File:BSicon ABZlg black-orange.svg File:BSicon BHF black-orange.svg File:BSicon tSTR black-orange.svg File:BSicon HST black-orange.svg File:BSicon INT black-orange.svg File:BSicon STR black-orange.svg File:BSicon BHF black-halforange.svg	File:BSicon mSPLe+vBHF-KBHFe black+orange.svg	File:BSicon STR Lblack-orange.svg File:BSicon tSTR black-orange.svg File:BSicon STR Lblack-orange.svg File:BSicon STR Lblack-orange.svg File:BSicon STR Lblack-orange.svg
	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)