Talk:BSicon/Renaming/Archive 3

Names of parallels from left to right (& vice-versa)

I needed this   (uSTRl1-), so I named it thusly, loosely based on Circeus’ plan, but I’m not sure of anything. Please advise. --Tuvalkin (talk) 10:05, 25 October 2011 (UTC)

(I needed it for this but meanwhile I made it differently — the matter and the question remains, anyway.) --Tuvalkin (talk) 10:10, 25 October 2011 (UTC)

Hmmm, I'd suggest to add the "v"-prefix to clearify it's starting at 125px ... The "l"-suffix shuold be ok, but the "1"-suffix is wrong because it's not ending/coming from the upper rights corner! a×p_de^Hello! 12:14, 25 October 2011 (UTC)

Indeed. the name in my scheme is   (u1STRlv). 1 is for the incoming line, and -v indicates that it shifts to the other line, -v being the replacement for -l2r/r2l (revealing their limitations: they work poorly for curves...). Circeus (talk) 12:42, 25 October 2011 (UTC)

We developed a method of describing any odd-direction STR curve icon, by using these cöordinates:

4	g	1
r		l
3	f	2

Unfortunately, the system breaks down when attempting to apply it to vSTR icons, so I would like to suggest an expansion, to accommodate them:

4	η	θ	1
ζ			α
ε			β
3	δ	γ	2

so now, using the example from above,   (uSTRl1-) would become   (uvSTRα-η). Useddenim (talk) 04:34, 4 November 2011 (UTC)

I, for one, believe the system should be kept strictly to ASCII characters. Say what you will, -v actually integrates pretty well even in the hyphen-based system. Circeus (talk) 06:15, 4 November 2011 (UTC)

Yes, -v does work just fine for parallel lines running across; the problem is in the description of curves...
{αβγδ…} came to mind as the next sequence after {1234…) and {abcd…}. (I didn't think that {i, ii, iii, iv …} would be a good idea! The last eight letters of the alphabet were also out, as t, u, and x—and potentially s and v—already have meanings as suffixes.) Useddenim (talk) 12:04, 4 November 2011 (UTC)

I have no issues with -v having distinct, but related meanings in different icon sets (i.e. "horizontal parallel lines" in crossings and "going from the left to the right line" in other icons): it's not like there's any chances of a need for it to ever assume both meanings in one icon, and I'm already using -u and -o with separate (but related) meaning outside crossing icons. Circeus (talk) 18:10, 4 November 2011 (UTC)

-v as suffix

Continuing along the line of the above: What says you people to   (mvKRZqu) being  (mKRZvu), on the model of  (mKRZh). We have -x, -t, -h, and soon -m and -s used to indicate features having the specific of their matching prefixes, so -v only makes sense for these crossing (as long as the crossing line is not itself mixed). Circeus (talk) 06:34, 28 October 2011 (UTC)

I like this idea. -- Tuválkin ✉ 05:15, 30 October 2011 (UTC)

How strange... That move was performed only now, by me, 2½ years later... YLSS (talk) 22:05, 1 May 2014 (UTC)

Bridges for double lines

moved to #Structure-only_.5Bk-corner.5D_names because it ends up to be the same matter

Structure-only [k-corner] names

The names for these —   (vBRK-L) and   (vBRK-R) — are not good: Sorry, I was not thinking right! They should be something like   (lvBRK-Lo) and   (lvBRK-Ro), or   (vNUL-Lo) and   (vNUL-Ro), even using Circeus’ system; or, more consevatively   (vBRÜCKE-Lo legende) and   (vBRÜCKE-Ro legende).-- Tuválkin ✉ 10:40, 7 November 2011 (UTC)

I'm not sure what would be the correct names; we probably need to create a proper nomenclature for the entire set of elevated structure elements:  (hleer)   (hleerr)   (hleerl)  (vhLGD-Ra)  (leer+hr)  (vhLGD-Re)  (vhLGD-MLa)  (vhLGD-MRa)  (leer+h)  (vhLGD-MLe)  (vhLGD-MRe)  (vhLGD-La)  (leer+hl)  (vhLGD-Le)  (hNULm)   (hNULg)   (hNULf)  (hNULq). BTW, three different roots (leer, LGD, NUL) for the same general feature are two too many. Useddenim (talk) 12:47, 7 November 2011 (UTC)

And there’s also  (dBRÜCKEr) and  (dBRÜCKEl)! -- Tuválkin ✉ 05:36, 25 November 2011 (UTC)

I needed two and created all four possible left-side elevated structure corners for k-icons, here: en:Wikipedia:Route_diagram_template/Catalog_of_pictograms/compound_junctions#Corners.

•  (hkABZq1) from  (kABZc1)
•  (hkABZq2) from  (kABZc2)
•  (hkABZq3) from  (kABZc3)
•   (hkABZq4) from  (kABZc4)

However the names I used (with "q" replacing "c") were not well-thought at all. In hindsight I think it should be something like hkNUL-Lc1 etc., based on the notion that these are only needed for the left side of lines curving leftwards from the main direction, and that there’s no track depicted on the icon. -- Tuválkin ✉ 12:27, 15 November 2011 (UTC)

For once I'm going to argue against the use of the NUL root, as the icons are not identical with the exception of the presence or absence of the track: compare  (hSTRq) vs. (hNULq). Useddenim (talk) 13:57, 15 November 2011 (UTC)

Fair point. That begs for a suggestion for naming these “structure-only” icons, as it is not only the case of these four. I checked here and gathered the following:

•  (vhLGD-La)  (vhLGD-Ra)
•  (leer+hl)   (leer+hr)
•  (vhLGD-Le)  (vhLGD-Re)
•   (vBRK-R)     (vBRK-L) (added -- Tuválkin ✉ 05:46, 21 November 2011 (UTC))

These six eight, plus the four above, are intended to accompany track on neighbouring icon cells. (All refering to elevated structure, but the same applies to hitherto non-existant trench cutting or embankmant marks.) These need consistent naming.

I would say that the presence of the prefixes "v" or "k", along with "h" (or possibly "C" or "E" as per Circeus’ renaming proposals for trench cuttings and enbankments) and a "-L" or "-R" suffix, would make it clear that the track is on a neighbouring icon cell and therefore using "NUL" as icon root name would be unambiguous. But lets discuss it.

-- Tuválkin ✉ 14:39, 20 November 2011 (UTC)

What about resurrecting the obsolete ELEV root for structure-only icons that go in an adjacent cell? Useddenim (talk) 17:50, 20 November 2011 (UTC)

I don’t like it, because:

• hELEV_ would look rather silly (indeed ELEV_ vs. hELEV_ immediately implies that something’s not right with the naming scheme)
• this needs to cover also trench cutting and enbankment “sides” for k- and v-preffix icons, not only h- ones

-- Tuválkin ✉ 21:30, 20 November 2011 (UTC)

Another root suggestion: FRM (for FoRMation), which covers cuttings, embankments and elevated structures, and works for both English and German. Useddenim (talk) 13:35, 21 November 2011 (UTC)

I ♥ FRM already. -- Tuválkin ✉ 14:18, 21 November 2011 (UTC)

<undent> regarding the issue of structures aligned to rail on a neighbouring structure, we have two competing problems, in that the "leer" icons are not used, or at least not originally designed that way: they were intended as overlays by ja:wp for the +BS platform icons. Additionally, the   (vBRK-L) name is in incorrect in my proposal (  (BRK-L) is  ). A possible solution for these variants is to use + instead of - ("coming from"):

•  (vhLGD-La) →   (hLGD+La)§
•  (leer+hl) →  (vhLGD-L)
•  (vhLGD-Le) →   (hLGD+Le)§
•   (vBRK-R) →   (BRK+L)

Adding a v- to those marked with § would indicate a variant designed for overlapping a  (vSTR). I cannot check whether  (leer+hl) is indeed the placement of the elevation mark on a double-track icon because, surprisingly enough, no   (vhSTR) icons seem to exist yet (but the placement seems obviously problematic as such an icon could not have -a/e variants). Circeus (talk) 18:18, 21 November 2011 (UTC)

I’m not so hot about "+", but before you dwell on this matter further please consider that elevated parallel (as also cutted and embanked parallel) lines have the “formation” fully on neighbouring icons cells. There’s no   (vhSTR) because the parallel eqv of  (hSTR) is made of three icons (the lateral ones may be half width). Lets discuss the matter rather at Talk:BSicon/Icon_topology_and_semantics#Building_bridges_for_double_lines. -- Tuválkin ✉ 20:28, 21 November 2011 (UTC)

Using the + makes sense to me, since even though the feature is on the right side of the icon, it is to the left of the lines (and vice-versa):    Useddenim (talk) 13:06, 22 November 2011 (UTC)

names stuff

moved from User talk:Useddenim

So I've been looking at the bunch of preliminary BSicon_50XX icons in Category:Icons for railway descriptions/experimental and tried to integrate them in the naming, which revealed some... dubious naming choices in the 45° junction set,and here's what I ended up coming up with:

1-branch 45°		2-branch 45°		2-branch 90°		1-branch 90°
Existing	Proposed	Existing	Proposed	Existing	Proposed	Existing	Proposed
(ÜWl+r)	(ÜWl+4) (ABZ2+g4)	(5014)	(ÜWABZgl+r) (ABZg2+4)	(5024)	ÜWgor+l (ÜABZgl+r) (ABZg2+4)	(ÜWgo+r)	(ÜABZlg) (ABZf+g4) (ABZ+4)
(5007)	(ÜWo2+r) (ABZf2+4)					(ÜWgor)	(ÜABZrf) (ABZg+f3) (ABZg3/ABZ3)
(5003)	(ÜW2+r) (ABZl2+4)	(5013)	(ÜWABZgr+l) (ABZq2+4)	(5022)	(ÜABZql+r) (ABZq2+4)	(ÜWgo+l)	(ÜABZrg) (ABZf+g1) (ABZ+1)
(5004)	(ÜWl+4) (ABZ2+r4)					(ÜWgol)	(ÜABZlf) (ABZg+f2) (ABZ2)
(ÜWr+l)	(ÜWr+1) (ABZ3+g1)	(5011)	(ÜWABZqr+l) (???)	(5023)	ÜWgol+r (ÜABZgr+l) (ABZg3+1)	(ÜWgu+r)	(ÜABZlgu) (ABZf+g4u)
(5002)	(ÜWo3+l) (ABZf3+1)					(ÜWgur)	(ÜABZrfu) (ABZg+f3u)
(5006)	(ÜW3+l) (ABZr3+1)	(5012)	(ÜWABZql+r) (ABZq2+4)	(5021)	(ÜABZqr+l) (ABZq3+1)	(ÜWgu+l)	(ÜABZrgu) (ABZf+g1u)
(5005)	(ÜWr+1) (ABZ3+l1)					(ÜWgul)	(ÜABZlfu) (ABZg+f1u)

The ÜWABZ/ÄBZ distinction is thin, but I couldn't think of anything. Yes I realize some of these names verge on the useless since the icons are not in use, but at least they are somewhat more useful than the numeral names. Circeus (talk) 15:18, 24 August 2011 (UTC)

Aw, gee... now I have to think about this! Useddenim (talk) 19:23, 24 August 2011 (UTC)

Some suggestions in green. Useddenim (talk) 21:15, 24 August 2011 (UTC)

The ÜABZ scheme follows the existing one for horizontal, which is fairly straightforward and easy to extend to everything above except maybe the first column. The g+f# scheme seems unnecessarily explicit... ABZ+# and ABZg# (because of the presence of multiple ABZ# roots, which raise issues with any names in ABZ3 or ABZ4) seems to me to fulfill what we need for. I have put up my simplified versions of your name as a third option. Circeus (talk) 21:46, 24 August 2011 (UTC)

Personally, I would like to eliminate the ÜW prefix/root, as the set has gone far beyond "flying junctions" (but I have no desire to recategorize 350+ icons, so Category:Icons for railway descriptions/uw and Category:Icons for railway descriptions/set blue/uw can stay). I also wouldn't mind hearing from axp_de^Hello!, if he has an opinion. Useddenim (talk) 23:17, 24 August 2011 (UTC)

Mass recategorization is what AutoWikiBrowser is for... Also you seem to have overlooked that the second columns (the 501# series) have a diagonal, not vertical or horizontal main line. Circeus (talk) 23:55, 24 August 2011 (UTC)

I aggree with you, Useddenim, we went far beyond what I started with the "ÜW" root, same with some icons now using the "STR" root. I'm not sure whether the "ABZ" root will be sufficient to gather all those icons, maybe we have to consider "KRZ" as well ... or finding a complete new root. Have to sleep over it ;-) a×p_de^Hello! 21:27, 25 August 2011 (UTC)

P.S.: Nevertheless I think the right column is quite easy to understand and shouldn't be changed ... a×p_de^Hello! 21:29, 25 August 2011 (UTC)

P.P.S.: Even enlarged there is no obvious difference between   (5013) and   (5022) ... do we really need both? Or let's combine both and keep only this one! a×p_de^Hello! 21:32, 25 August 2011 (UTC)

  (5022) = + + ;

  (5013) = +   + ... one (or both) need to be redrawn. Let me work on that.

I'm not sure how much could/would/should be covered by it, but one possibility for a new root is DAG for Diagonal (which also works in German). Useddenim (talk) 02:29, 26 August 2011 (UTC)

(5022)	(5122)		I hope the 51xx versions are clearer than the 50xx ones. The curves don't swing quite as close to the centre, and there's a subtle kink to the through line to better define the white space. ("Thank you" to the font designers for that little trick.) Useddenim (talk) 16:03, 26 August 2011 (UTC)
(5113)	(5013)

I'd also prefer to eliminate the "ÜW" root... --Pic-Sou (talk) 09:18, 27 August 2011 (UTC)

[undent] How about this: DAG is introduced for icons with a branching diagonal line and no horizontal or vertical across, other icons keep the ABZ root. I don't mind coming up with a full scheme covering all the ÜW stuff starting from what we got here. Circeus (talk) 16:24, 28 August 2011 (UTC)

"DAG" is no good idea, "diagonal" is the direction of a track, not its facility. It's a kind of mixture of "KRZ" and "ABZ" ... a×p_de^Hello! 22:10, 29 August 2011 (UTC)

Admittedly the ABZ root works well enough (as shown above). I can see about listing all the ÜW stuff and relatives (the horizontal pendants of column 4, for example, are not listed) and see what their ABZ names would be. Circeus (talk) 22:37, 29 August 2011 (UTC)

Yeah, but there desn't seem to be a better way of describing them, so I say let's see what Circeus proposes. Useddenim (talk) 22:37, 29 August 2011 (UTC)

Excuse-me, but why not to create icons overlapping + + +   ? It would give that... Sincerely --Pic-Sou (talk) 14:03, 31 August 2011 (UTC)

1. Not all wikis support multiple overlays;

2. A specific icon can be drawn much more clearly;

3. Your composite shows a crossing + two curves, while the table is aboutjunctions with two curves. Useddenim (talk) 19:55, 31 August 2011 (UTC)

Misnamed corner arrows

corner #1 ([l]NUL[+]c1[-[+]c1])
corner #2 ([l]NUL[+]c2[-[+]c2])
corner #3 ([l]NUL[+]c3[-[+]c3])
corner #4 ([l]NUL[+]c4[-[+]c4])

These were wrongly uploaded with an extra "D" preffix, and renaming was requested. -- Tuválkin ✉ 14:40, 8 May 2012 (UTC)

 Done -- Tuválkin ✉ 22:17, 10 May 2012 (UTC)

  File:BSicon KBFer.svg

I stumbled upon this (BHF with an HST connection to the side), and can't figure out what it properly should be called. Anyone have any thought on this? Useddenim (talk) 11:52, 2 February 2012 (UTC)

Cannot be vBHF-HST, as it would be  (dBHF)+ (dHST), but what about   (vBHF-HST)? -- Tuválkin ✉ 20:34, 2 February 2012 (UTC)

For this peculiar set I've been using BHF(L,R)-H(a,e). Circeus (talk) 01:39, 3 February 2012 (UTC)

I thought this icon was for a connection to a (non-existant  (HSTl), but it turns out (after checking and changing usage) that it was merely an alternative to  (CPICle). All instances have now been replaced (as well as for   (KBFel)).   (KBFar) and   (KBFal) still to be done. Useddenim (talk) 05:32, 3 February 2012 (UTC)

THere IS a matching icon in HST, it's   (HSTr2). Circeus (talk) 20:34, 3 February 2012 (UTC)

Still,  (CPIC) seems to be the better way to connect disparate station icons, rather than trying to cover all the possible mix 'n' match permutations. Useddenim (talk) 04:30, 4 February 2012 (UTC)

I agree. Connecting BHF and a HST is a ridiculous idea. At worst you'll want the HUB icon, because otherwise the whole thing would be in BHF! Circeus (talk) 19:18, 4 February 2012 (UTC)

  File:BSicon ÜWolr.svg

Why was this name assigned to this icon? Nothing crosses over anything else. And until yesterday, the name had been used for .
Admittedly,   (ÜABZ+lr) was not the best name, but there are already two proposed new names (  (ABZg+23) and   (ABZ_23)), both of which describe the design more accurately. (Besides, Vunz (talk) and Axpde (talk), you left   (uÜWolr) and   (uexÜWolr) just hanging in the wind! Useddenim (talk) 00:22, 8 January 2012 (UTC)

Step by step ... a×p_de^Hello! 18:23, 8 January 2012 (UTC)

Mixed stations

I noticed here two new mixed station icons,  (vuexKBHFa-BHF) and  (vBHF-uexKBHFa). These names seem a bit bloated (just as the SVG code of these two icons, too) — or is "m" being deprecated?! I’d expect something named vuexKBHFa-BHF to be fully pale blue (akin to  (uexvBHF) a.s.o.), not to mention the unusual "vuex" instead of "uexv" (is this meaningful?), while vBHF-uexKBHFa is just weird, with base color indicator "u" in the middle of the name. Why not just  (umvexKBHFa-BHF) and  (mvBHF-exKBHFa)? -- Tuválkin ✉ 18:58, 10 July 2012 (UTC)

It appears that Géofer (talk · contribs) was merely following the pattern established for partly in/out-of use parallel line icons and extending it to mixed heavy/light rail. Moves have been made. (And  (vBHF-uexBHF) to  (mvBHF-exBHF) done at the same time, for good measure.) Useddenim (talk) 04:09, 11 July 2012 (UTC)

Awesome! -- Tuválkin ✉ 04:46, 11 July 2012 (UTC)

Fish or fowl?

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)

Two thoughts inspired by this:

• 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. But here.
• This is also why I think that other color icons should not be named as RGBs, but by “human” (pref. generic) color names.

-- Tuválkin ✉ 02:23, 21 August 2012 (UTC)

Given the 50% alpha on white RGB derivation rule, I retract my suggestion above that exact RGB naming of oddball color icon sets is an unusable idea. (Though I still think that human-readable, “semantic” names are better.) -- Tuválkin ✉ 09:58, 21 August 2012 (UTC)

See Category talk:Icons for railway descriptions/other colors for some thoughts. Useddenim (talk) 12:39, 22 September 2012 (UTC)

Under void bridges

This  (uxKRZuw) (and its cohort) is a great addition to  (SBRÜCKE), with room enough for overlaying with any kind of across straight — File:BSicon HLUECKE 1A8BB9.svg (uxKRZuw※ HLUECKE 1A8BB9)  File:BSicon uSTRq BlnU3.svg (uxKRZuw※ uSTRq BlnU3)  File:BSicon STRq MO MZD.svg (uxKRZuw※ STRq MO MZD) , et c., but it needs to be renamed, as it is not a KRZ in any useful way. It is a BRÜCKE and should be renamed to  (uexBRÜCKEu), don’t you think? (I’m also campaigning for slightly change its design.) -- Tuválkin ✉ 05:46, 9 July 2012 (UTC)

Geometry fixed. What about uexBRÜCKEu for the name? (cf.  (uexBRÜCKE). Useddenim (talk) 20:20, 20 August 2012 (UTC)

2 votes for  (uexBRÜCKEu) so far. -- Tuválkin ✉ 01:51, 18 September 2012 (UTC)

Renaming  Done. -- Tuválkin ✉ 15:42, 21 September 2012 (UTC)

Now missing:

•   (ugKRZuw) →   (ugBRÜCKEu)
•  (uKRZuw)  →   (uBRÜCKEu)

-- Tuválkin ✉ 16:03, 21 September 2012 (UTC)

Missing also fixing the uses of the old name(s), in all projects. -- Tuválkin ✉ 16:03, 21 September 2012 (UTC)

I have an alternative proposal based on the origins of  (SBRÜCKE)'s name (personally I'd obsolete it for icons based on an empty normal-width crossing, but the Germans are fond of it.): call them  (SKRZu) and design them as the empty version of the generic road crossing  (SKRZ-G1u). I write design because neither of the three icons needing renaming use the actual bridge format for a normal crossing!  (uexBRÜCKEu) is actually broader, and the two created by the canal project have bridge drawn in too narrow lines and with a main line that stops short of the bridge.

The current  (SKRZu) is a LGD icon in disguise anyway and redirects to   (BRÜCKEq legende). Circeus (talk) 22:21, 22 September 2012 (UTC)

Double lines with one-side-only stations

(vBHF-STR)  (veBHF-STR)  (vexBHF-STR)  (vSTR-BHF)  (vSTR-eBHF)  (vSTR-exBHF) File:BSicon exvBHFr legende.svg  (veBHF-exSTR)  (vexBHF-exSTR) File:BSicon exvBHFl legende.svg   (vexSTR-exBHF) File:BSicon exvBHFl legende.svg  (vexSTR-eBHF)

AlgaeGraphix recently marked the newly created icon   (uvexSTR-exBHF) as a duplicate of older  (uexvSTR-BHF), and likewise the new   (vexSTR-exBHF) as a dupe of  (exvSTR-BHF). I was about to nod and slap my forehead for having missed those before creating the new ones when it struck me that the new names may be better.

The thing is: when there’s one station on one of two paralel lines, we need to cover three things in the icon name:

• left line closed/open
• right line closed/open
• station closed/open (be it on the left or right line)

Even leaving aside the needlessness of having an open station on a closed line, this cannot be made with assuming is not very clear to assume^{(edited: -- Tuválkin ✉ 12:56, 5 April 2012 (UTC))} that, say, the name exvSTR-BHF should signify instead of .

That’s why I’m proposing a refining of our current naming system to include always the prefix "ex" or "e" after the dash of assymetrical parallel line icons, to unambiguously mark the open/closed state of the right side feature/line. (This of course goes for all line colors and for all features akin to stations.)

-- Tuválkin ✉ 01:22, 5 April 2012 (UTC)

Yeppers. It's the only sensible approach and a natural departure from the otherwise enforced policy that all-ex icons must have ex- as the first prefixes. Circeus (talk) 11:41, 5 April 2012 (UTC)

Just followed the conventions used at Wikipedia:Route diagram template/Catalog of pictograms/parallel junctions#Heavy Rail / Light Rail: 「e|x|ex」vICON when applied to the entire icon, otherwise v「e|x|ex」ICON-「e|x|ex」ICON. AlgaeGraphix (talk) 12:00, 5 April 2012 (UTC)

Yes, exvFOO-BAR means fully out of use: That’s according to the current rules and has logic in it (being akin to any regular exFOOBAR). However, when vexFOO-BAR is used, to mean that bar is in use and foo is out of use, it might be confusing (because both names are so alike), while the alternative synonym vexFOO-exBAR is less so and more akin to the remaining combinations. -- Tuválkin ✉ 12:52, 5 April 2012 (UTC)

I thought we already came to this conclusion, at least that's what User:Vunz explained to me ... {e}{x}vID is an abbreviation for v{e}{x}ID-{e}{x}ID, same with {e}{x}vID1-ID2 for v{e}{x}ID1-{e}{x}ID2 ... Regards a×p_de^Hello! 16:25, 5 April 2012 (UTC)

So, what's the conclusion? One, or the other? or both, with a redirect? and if so, which? AlgaeGraphix (talk) 18:27, 5 April 2012 (UTC)

I am of the opinion that each half needs its own indication for e/x/etc. and it is on that basis that I chose the name for
 (veBHF-exKBHFa)
v (eBHF)- (exKBHFa)
which I uploaded recently. --Redrose64 (talk) 12:21, 6 April 2012 (UTC)

Well,  (veBHF-exKBHFa) is correct, as the status of the two sides is unequal. The question under discussion is the proper naming of icons where the two sides are the same: partially or fully out of use. Useddenim (talk) 16:49, 6 April 2012 (UTC)

Yet more icon renaming...

Level		Over		Under
Existing	Proposed	Existing	Proposed	Existing	Proposed
(ÜWolrKRZ)	(KRZ2+4)	(ÜWulrKRZo)	(KRZ2+4o)	(ÜWolrKRZu)	(KRZ2+4u)
(ÜWorlKRZ)	(KRZ3+1)	(ÜWurlKRZo)	(KRZ3+1o)	(ÜWorlKRZu)	(KRZ3+1u)
(ÜWolr+KRZ)	KRZ2+4q  (KRZq2+4)	KRZ2+4qo   (ÜWulr+KRZo)	(KRZq2+4o)	(ÜWolr+KRZu)	KRZ2+4qu  (KRZq2+4u)
(ÜWorl+KRZ)	KRZ3+1q  (KRZq3+1)	(ÜWurl+KRZo)	KRZ3+1qo  (KRZq3+1o)	(ÜWorl+KRZu)	KRZ3+1qu  (KRZq3+1u)
(ÜWolr+rl)	(KRX)	(ÜWolr+orl)	(KRXu)	(ÜWolr+url)	(KRXo)

I realize that this somewhat violates the "symmetry of q" rule, but I couldn't think a better way of describing the configurations. Useddenim (talk) 14:18, 16 August 2011 (UTC)

...and just checking to make sure that I have the order correct:

		e	x	ex
KRZ2+4u					Underpass crossing line to corner 2 from corner 4

Useddenim (talk) 18:25, 16 August 2011 (UTC)

This multiID icon name is no good idea, but at the moment I have no better suitable name. a×p_de^Hello! 14:58, 17 August 2011 (UTC)

Quick question: would it violate the convention too horribly to put those with an horizontal line as (KRZq2+4)and so on? This makes it easier to explain that these are not rotated forms of (KRZ2+4) and corresponding (or a new KRZ2/3 base!) but in fact independently named icons "built up" from a straight horizontal. Circeus (talk) 16:01, 18 August 2011 (UTC)

Good idea; but I still don't know what to do about the flat junction with both diagonals? Useddenim (talk) 22:16, 18 August 2011 (UTC)

Within the existing frame, I don't think we can get a really satisfying solution. I'm not clear if a one-time -d suffix (diagonal) would be workable: (KRZdo/KRZdu). Here -u/o would be somewhat arbitrary, I suppose... Circeus (talk) 23:18, 18 August 2011 (UTC)

One possibility for a new root is DAG for Diagonal (which also works in German). Useddenim (talk) 21:41, 27 August 2011 (UTC)

Nope, "diagonal" refers to a direction, it is no root! a×p_de^Hello! 00:27, 28 August 2011 (UTC)

Icon renaming (for the n^th time…)

• moved from en:Wikipedia talk:Route diagram template/Catalog of pictograms
• later moved back from the archive because it is not closed

I'll be fixing these, but if anyone else wants to jump in, please do. -- Tuválkin ✉ 17:30, 17 January 2013 (UTC)

• ueÜWcro should be   (uexÜWc1) Done. -- Tuválkin ✉ 16:44, 17 January 2013 (UTC)
• ueÜWcru should be   (uexÜWc2) Done. -- Tuválkin ✉ 08:01, 21 January 2013 (UTC)
• ueÜWclu should be   (uexÜWc3) Done. -- Tuválkin ✉ 03:36, 10 February 2013 (UTC)
• ueÜWclo should be   (uexÜWc4) Done. -- Tuválkin ✉ 04:17, 11 February 2013 (UTC)

for consistency with the other corner icons. Useddenim (talk) 16:23, 21 February 2011 (UTC)

Naming pattern

Where is the naming and coloring system described? -DePiep (talk) 15:47, 19 November 2012 (UTC)

I don't know if that can be revealed to a noviciate or not… but seriously, it's all at en:WP:RDT/C. Useddenim (talk) 01:28, 20 November 2012 (UTC)

Thx. Eh, maybe I don't want to be initiated. Jee. Even when I leave out the German thing, it's weird. -DePiep (talk) 00:52, 25 November 2012 (UTC)

Rename carefully, please!

Last Feb9th,  (fKBHFa) become the redirect reciepient for three other file pages, all obsolete namings of the same. That’s very good and I agree with this naming. However it is necessary to manually replace each and evey use of these three icons in all diagrams in all projects, because CommonsDelinker will only fix uses that call for the whole filename (it doesn’t recognize it when an icon is called from the {{BS-overlap}} template), and because filenames thusly called often do not enable redirects, showing a broken link instead (the alt text shows in place of the icon). So, we have had for 11 days later the following:

•   (KBFa green): 4X damaged diagrams in nine Wikipedias  Done
•  (KBHFa green): fifty something damaged diagrams in seven Wikipedias  Done
•   (fKBFa): sixty something damaged diagrams in six Wikipedias (incl. in Latin! TV·QVOQVE!)  Done

I am about to fix them, but it would be really grat that whoever enacts the renaming/mergin does also the cleanup. -- Tuválkin ✉ 08:17, 22 February 2013 (UTC)

Many of the usages of   (fKBFa) were in abbandone user pages and old discussions. And I noticed that the missing image errors, with blue alt text showing (which messes the whole diagram), occurs not always (never in wp:de, only some times in wp:la), even in the same project. Just random, or something about the exact templates in use? -- Tuválkin ✉ 10:28, 22 February 2013 (UTC)

My bad. Having requested a move, I always update links in templates across Wikipedias, but as for the links in plain articles... ahem, I often do update them, but if there's a lot of them, I may skip this part. The broken thumbnails are updated after some time (up to a week, I think), although the page may need purging. In this particular case, I did not proceed because I was not sure that the file wouldn't be moved again shortly - though now it seems that f/green issue has lessened in priority. Concerning red/blue links/empty pictures: I guess it's rather an issue with cashing at Commons. A more disturbing bug is when a new version of a file is uploaded over an existing (cashed) version. This one may take a far longer time to update, and occasionally some cashed thumbnail - e.g. 20px sized - may remain the same old version while all other sizes are updated. YLSS (talk) 20:01, 22 February 2013 (UTC)

It is fixed now. The main problem, IMO, is not when the 20px thumbnail doesnt update fast enough, it will get sorted before anyone really notices, the problem is when the 20px thumbnail is not displayed and instead its alt-text shows — because that is much wider than 20px and ruins the whole diagram. -- Tuválkin ✉ 20:59, 22 February 2013 (UTC)

File:BSicon ENDEma.svg + others

moved from en:User_talk:YLSS#File:BSicon_ENDEma.svg_.2B_others

I noticed that you have added a new group of icons. However, I have two observations:

1. I think these are more like  (PSL) than  (ENDEe);
2. They look very cramped at 20px.

I have added four more (two in tunnel, two partially out of use) – with more white space – to the set. What's your opinion? Useddenim (talk) 00:12, 6 January 2013 (UTC)

(uENDEma)	(uxPSLa)	(utPSLa)
(uENDEme)	(uxPSLe)	(utPSLe)

Your versions are certainly clearer; I just didn't want to deviate from existing patterns. But I guess I'll reload mine now in parallel with yours. Concerning 1. - what do you mean? Yes, they are based on PSL/ÜST, but the main point is the presence of a dead end track. If your point is about the title, I could go both ways. YLSS (talk) 00:52, 6 January 2013 (UTC)

With respect to 1., consider the third case, where the centre track joins at both ends. The PSL still exists, but there is no ENDE: Useddenim (talk) 13:41, 6 January 2013 (UTC)

(uPSLm)	(uePSLm)	(uxPSLm)	(uexPSLm)
(utPSLm)	(uetPSLm)	(uxtPSLm)	(uextPSLm)

Note, also, that the PSL name is more consistend with the x/e naming convention regarding the primary/secondary feature being out-of-use. Useddenim (talk) 13:47, 6 January 2013 (UTC)

 Done Re-uploaded and renamed files. YLSS (talk) 21:04, 19 January 2013 (UTC)

Right or r?

New icon   (uFLOODright) is named with the unexpected suffix "right", instead of the usual "r". Any thoughts? -- Tuválkin ✉ 01:48, 18 September 2012 (UTC)

Blame the British canal people – it's one of their icons. Useddenim (talk) 14:29, 18 September 2012 (UTC)

Okay, blamed. What now? Any trouble in going ahead and rename it in the usual way? -- Tuválkin ✉ 17:31, 4 January 2013 (UTC)

All renamed:  (uFLOODr)  (uFLOODl)  (ueFLOODr)  (ueFLOODl) -- Tuválkin ✉ 17:26, 25 February 2013 (UTC)

h or no h?

Moved to Talk:BSicon/Renaming/Roads#h or no h

Two ongoing experiments

I recently uploaded   (KBHFeq(yellow)), to match the shape of   (KBHFl yellow) and mismatch its consevative naming — I used an “other color” category as testing ground. The experimental bits are:

• "q" used to mark a quarter turn (anti-clock), not just an icon across, embracing an arbitrary default direction from left to right, just like the top-down default direction of non-"q" icons. (Not a bold new idea, just one that has been slow to catch on)
• 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)

(edit conflict) Oops, I just moved the file to match the naming scheme.

I don't like the "q" for "quarter turn anti-clockwise" 'cause it makes the icon hard to recognize.

Whether with or without brackets, well, I think we shouldn't use too many special chars in our names ... a×p_de^Hello! 12:03, 15 February 2013 (UTC)

Concerning "q" for «quarter turn anti-clockwise», lets keep the discussion in the original location. 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)

Discussion on space/brackets follows here.

I have to (partly) agree with Axpde about the q suffix: IMHO it should only apply to icons that have 180° rotational symmetry; i.e. can be rotate clockwise or anti-clockwise.

 (BHFq) OK
 (exABZql)  Not OK
Useddenim (talk) 22:09, 15 February 2013 (UTC)

That matter is being discussed elswhere (lets keep it there). This opinion is mathematically unsound — the theoretical proof is not hard, but our particular naming system and the needs it addresses (especially the fact that these icons are to be legended with horizontally running text, its symmetry being thus fuzzy/gritty) makes the matter less than 100% perfectly ideal for trivial application of a theoretical principle. However I’m sure that reasonable and well-meaning people will sooner or later come to agree with the idea that "q" should be just a switch from top-bottom to left-right, and leaving all the rest unperturbed. People against any change, regardless of how it is argumented will be, well… against any change. -- Tuválkin ✉ 03:42, 16 February 2013 (UTC)

Of course Axpde had to come over and vandalize my work. He doesn’t have much free time or patience any more to do any actual work, but to keep pulling his string in order make sure all his ideas are left unchallenged — well, for that he always finds himself a minute. Sad. -- Tuválkin ✉ 11:41, 15 February 2013 (UTC)

Discussion on renamings follows here.

Renaming process

Moved to Talk:BSicon/Renaming/Roads#Renaming process