Talk:BSicon/Renaming/Archive 9

Archive 5

←

Archive 7

Archive 8

Archive 9

Archive 10

Archive 11

→

Archive 13

GRENZE vs. ZOLL

@Useddenim and Tuvalkin: What's the difference between  (lGRENZE) and  (lZOLL)? Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me 15:11, 8 December 2016 (UTC)

•  (lGRENZE): older, 148 transclusions;
•  (lZOLL): newer, bolder graphic elements, 238 transclusions. Useddenim (talk) 16:40, 8 December 2016 (UTC)

@Useddenim: (also pinging Axpde and Sameboat) Could we redirect  (lGRENZE) and derivatives to their ZOLL counterparts? This might be better for consistency. (Although I think the bright red of lZOLL could be changed to the lGRENZE colour, as it doesn't really seem to match the pastel colours of other BSicons; see here.) Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me 11:11, 9 December 2016 (UTC)

I'm all for eliminating the GRENZE/GRENZE2/GRZ confusion, so go for ZOLL! Useddenim (talk) 13:16, 9 December 2016 (UTC)

@Useddenim: No, no, no, no, no! Said elimination would be to reinstate the previous confusion. We managed to got to the point where GRZ is for boundary lines (international or other) and ZOLL is for toll/customs stops. (While   is a common occurrence, they should be usable also apart.) The old GRENZE thing is for de.wp use, and good riddance. -- Tuválkin ✉ ✇ 15:32, 9 December 2016 (UTC)

@Tuvalkin: You misunderstood: (IMHO)  (lGRENZE) is an inferior version of  (lZOLL) and should be replaced by the latter. Useddenim (talk) 15:41, 9 December 2016 (UTC)

Ah, okay then. We do agree. -- Tuválkin ✉ ✇ 15:55, 9 December 2016 (UTC)

• Jc86035, back then we had to create new names because de.wp was (still is?) stuck with the notion that  (GRENZE) is somewhat related to  (eGRENZE) in the same way  (BHF) is related to  (eBHF).

As for the exact design, I have no qualms. But please consider that using a shade of red distinct from line colors is a feature, not a bug, and that the white rim of the roundel is meant to be visible at 20px.

-- Tuválkin ✉ ✇ 15:32, 9 December 2016 (UTC)

• My opinion:

1. Delete "lZOLL"
2. Move "lGRENZE" to "lZoll"

Cheers a×p_de^Hello! 21:23, 9 December 2016 (UTC)

Axpde, looks like you like the name but dislike the details of the image. Fair enough, but then what should be done (besides focusing on design issues in a page about them, not in /Renaming) is rather to upload new SVG content (copied from  (lGRENZE)) into the established file  (lZOLL), avoiding the need to edit (twice!) the 200-something pages, in several projects, that transclude it. -- Tuválkin ✉ ✇ 13:09, 10 December 2016 (UTC)

Random load of crap

I'll be going on wikibreak for a while, so here's a random bunch of stuff that I've been thinking about in no particular order. Feel free to ignore this. I hope at least some of this is useful.

1. Fixing the naming of the   (muBHFa) group (wrong prefix order etc.), including stuff like   (mvtKBHFaeq yellow+) and   (INT-R azure+yellow) (possibly even the SWBHFs).
2.  (numN000) → NORTH000?
3. Deprecating the num prefix in favour of using Routemap's {{BStext}} implementation.
4.   (ABZf+l TUNNELa yellow) / orange,   (vSTRae+l yellow), other BSicons by AndreyA are a bit of a mess in naming and/or geometry.
5. Possibly using the suffix-next-to-prefix thing for icons like  (hBHFe) and  (tBHFe).
6. Using the aq/eq suffixes for  (KBHFl) etc.
7. Renaming all the icons using lf/lg/rf/rg, although that might have to wait for this (and possibly updating CommonsDelinker to allow for fixing BSicon names as well).
8. Creating a P prefix (e.g.  (STR+BSl) → PSTR-L) to allow for curved platforms (as well as using "PLT" instead of "BS" for various legende).  (ENDEe+BSelr) might become PSTRe, PSTRe-LR, PSTR-LRe, PSTRe-LMR, PSTRe+PLTe or PSTRe-LR+PLTe depending on how this works.
9. Should the non-track sides of elevated platforms have formations? Some of them don't, and some (mostly in the experimental category) do.
10. Renaming icons like  (exvuBHF-BHF) to only have one BHF (e.g. uexmvBHF, as above.
11. Replacing all the cubic Bézier ÜW curves with circular arcs (+ narrow formations for the elevated ones). I've done about 150 of these already, but there are a lot of them.
12. Fixing the stroke width of all the INT icons (and the colour of all the e[x]INT icons).
13. Why do icons like  (hABZlf) and  (hABZf+4l) have the rounded empty corner? This is inconsistent with 45° junctions.
14. Rewriting  (TRAM) to make it a little more symmetrical.
15. Why are there two/three different naming schemas for ABZs which are inconsistently applied (e.g.   (ABZf+4l) but  (ABZ+lr);  (ABZg2) but  (ABZlf))?
16. Replacing straight/cubic Bézier tunnel portals with elliptical ones, and finding consistent sizes.
17. Schema for (50px and correctly aligned) elevated formations for parallel terminus stations, including partial termini like  (vKBHFa-BHF) (and legende formation naming).
18. Doing something about the new and   (uexSTRL) etc. (1000px-high),  (xCPIClaT) etc., and  (ODICl) etc. icons.
19. Unifying the geometry of formations of  (BRIDGElr),  (ÜWt1),  (STR3u) etc.
20. Should  (hTBHFo)/ (TBHFo) have rounded or straight formations?
21. Narrowing formations of all the ÜW KRZ icons like  (KRZ2+ru) to the same as  (KRZo) and  (BRIDGE3+1o).
22. Do  (eKRZ2+4+r) etc. really need that weird curve shape without the bridge?
23. Fixing the discrepancy between  (hSTR-R) etc. and  (CSTR-R) etc.
24. Renaming the k icons; as above.
25. TUNNEL1 → tSTRae, TUNNEL2 → tSTRafeg, BRÜCKE → hSTRae, BRÜCKE1 → BRK, BRÜCKE2 → CLV (culvert) and VIADUKT-L/R → ?; as above.
26. Adding more widths (consistently with the current ones); as above.
27. Fixing all the three-quarter-parallel-shift icons which I uploaded badly.
28. Unifying the length and naming of  (CONTge),   (hCONT+f),  (utvCONTge) etc.
29. Renaming some of these (see the enwiki catalogue).
30. BS2 → SHI2.

Happy editing, Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me 12:21, 11 December 2016 (UTC)

25a. BRIDGE → BDG.

Useddenim (talk) 17:40, 11 December 2016 (UTC)

Weird icons

LBHFxa

@Useddenim, Axpde, and Tuvalkin: Is there a way of applying "not lücke" to the ex part of  (LBHFxa)'s naming? (Also missing K prefix.) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 07:09, 17 December 2016 (UTC)

• Interesting question. I agree that this station icon should include KBHF, for sure; as for how to express the lücke transition, why not using the lazy but effective naming technique of a + to denote overlaying? Like this:   (LKBHFa+exKSTRe)? It does match  (LKBHFa※ exKSTRe)  -- Tuválkin ✉ ✇ 12:47, 17 December 2016 (UTC)

  @Tuvalkin: It also matches  (LKBHFa※ xKBHFe) , which has the  (BHF) root in common. Does this suggest a path to a name? Useddenim (talk) 13:32, 17 December 2016 (UTC)

  I intentionally put a  (exKSTRe) in it and not  (exKBHFe) in order to dispell the notion that “under” the station that’s in operation somehow lies a disused station. The visual result, is, of course, the same. -- Tuválkin ✉ ✇ 22:56, 17 December 2016 (UTC)

• I suggest that  (xKBHFe) takes precedence over  (LKBHFa) because of  (STR) over  (LSTR) and top-to-bottom^{Only applies to equal elements Useddenim (talk) 13:33, 17 December 2016 (UTC)}.

  I think I agree. -- Tuválkin ✉ ✇ 22:56, 17 December 2016 (UTC)

  @Tuvalkin and Useddenim: So LKBHFa+xKBHFe? Jc86035 (talk) Use {{re|Jc86035}}
  to reply to me 10:25, 18 December 2016 (UTC)

Is all this dancing on the head of a pin really worth the effort for the difference of one dot? Useddenim (talk) 18:54, 18 December 2016 (UTC)

• @Useddenim: de:Usoratalbahn looks like it wouldn't really make a difference to change it there. Plutowiki, would it be fine to replace the icon in that diagram with  (KBHFxa)? —Jc86035 (talk) Use {{re|Jc86035}}
  to reply to me 03:20, 19 December 2016 (UTC)

• @Jc86035: In de:Usoratalbahn  (STR) and  (LSTR) ist not the same.  (STR) is for Usoratalbahn,  (LSTR) for other railways. The frontier ist in the railway station of Banja Luka and not outside. --Plutowiki (talk) 21:46, 19 December 2016 (UTC)

• @Useddenim: , in some cases (added case 2 and 3 →) one extra lücke dot is needed to make a diagram more clear. This icon  (LBHFxa) is not unnecessary, and difficulties with naming should not be “solved” by argueing it is. -- Tuválkin ✉ ✇ 16:14, 19 December 2016 (UTC)

@Tuvalkin: Go back and re-read what I said. I asked if the icon was necessary; I didn’t say it was unnecessary. Useddenim (talk) 02:36, 20 December 2016 (UTC)

nBHFa

See also   (nBHFa). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 07:14, 17 December 2016 (UTC)

Doesn’t seem to be a valid icon? -- Tuválkin ✉ ✇ 12:47, 17 December 2016 (UTC)

@Tuvalkin: Never mind, didn't realize it was uploaded as a PNG. Will nominate for deletion. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:50, 17 December 2016 (UTC)

Half-width shifts

@Useddenim, Tuvalkin, and Axpde: For all icons in the subcategories of this category:

Current	Proposed
(dWgl) etc.	dSHI2gl etc.
(dWXlr) etc.	dSHI2lr etc.
(dXl) etc.	dSHI2l etc.
(dWglp) etc.	dSHI2gl+BSl?

I'm not sure how the non-standard platforms should be handled, although we could just replace W with SHI2 and leave it at that. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:59, 19 December 2016 (UTC)

Counterquestion: Why fix something that's not broken?

I choosed those short roots as "W" and "X" to reduce the ascii-waste in large maps as e.g. de:Benutzer:Axpde/Bahnstrecke Duisburg–Düsseldorf. a×p_de^Hello! 16:11, 19 December 2016 (UTC)

@Axpde: It doesn't make a lot of sense to use three separate roots for it. I understand how it's derived, but it's unnecessarily complicated. We also already have two other roots for two-quarter shifts (for now), which makes it even more confusing. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 07:36, 20 December 2016 (UTC)

I’m all for harmonizing the icons into the SHI family. Useddenim (talk) 02:38, 20 December 2016 (UTC)

Suffixes: a, e / TUNNEL1 and TUNNEL2

• A while ago I renamed  (uextSTReaq) to   (uextSTRaeq). Should it be renamed back (along with   (tSTRae),   (extSTRae) and u, uex), given that ae seems more apt for start → end (i.e.  (uexTUNNEL1q))?

All remaining instances of utSTRae have been changed to  (utSTRea). Now can  (TUNNEL1) etc. be moved? Useddenim (talk) 12:43, 25 December 2016 (UTC)

@Useddenim: (pinging Tuvalkin, Sameboat and Axpde) I suppose, seeing as no one has objected after six months. I would rename  (BRÜCKE) and its derivatives as well. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:18, 29 December 2016 (UTC)

Yes, but leave a redirect (at least for a while), otherwise you will have to deal with a lot of screaming… Useddenim (talk) 14:41, 29 December 2016 (UTC)

• Speaking of that, could we rename  (TUNNEL1) (+ all derivatives) to tSTRae and  (TUNNEL2) (+ all derivatives) to tSTRafeg (or something like that)? Jc86035 (talk • contributions • uploads) 14:26, 16 June 2016 (UTC)

 Agree. Useddenim (talk) 10:14, 17 June 2016 (UTC)

• • do we have to ask de.wikipedia first if the icons are in the Bilderkatalog? Jc86035 (talk • contributions • uploads) 14:44, 16 June 2016 (UTC)

No, they don’t “own” BSicons (but there are some de.wp Commons admins who feel very strongly about renaming). The politic thing would be to post a notice there (but there’s always the redirect that’s left behind). Useddenim (talk) 10:14, 17 June 2016 (UTC)

Should the BRÜCKE set be moved as well (hSTRae root, like  (hBHFae)), since the above change would make it stand out (no TUNNEL icons would be left)? (I still think there's something better and less convoluted than "tSTRafeg"…) Jc86035 (talk • contributions • uploads) 12:06, 17 June 2016 (UTC)

tnl (in lower case) for "small tunnel"? Useddenim (talk) 16:59, 17 June 2016 (UTC)

I've always generally interpreted "tunnel" in BSicons to mean "underground" so on this point I would say avoid anything related to tunnel for these as they're more closely related to elevated (h) icons. Perhaps "BRK" (de) or "BRG" for bridge? But yes, "BRÜCKE" has to go. Lost on  Belmont ^3200N_1000W  (talk) 03:07, 18 June 2016 (UTC)

@Lost on Belmont: (I think Useddenim meant tnl for  (TUNNEL2). I'm not sure it's necessary to make another root…) To be honest, some of the Brücke icons' formations ( (BRÜCKE1) and  (BRÜCKE2)) are quite different from  (BRÜCKE) and  (hSTR), so for the narrower bridges we could just change them to BRK c.f.   (kBRKuf) (or leave them as they are).

We also have  (BRK3). For a multi-arch viaduct icon, it doesn't look very much like a multi-arch viaduct (I had never seen this until I went and searched for BRK icons…). Jc86035 (talk • contributions • uploads) 05:30, 18 June 2016 (UTC)

Again: Why fix something that's not broken? Please leave BRÜCKE(n) and TUNNEL(n) as they are! a×p_de^Hello! 20:12, 29 December 2016 (UTC)

@Axpde: Because it's inconsistent with icons like  (hBHFae) and  (lhSTRaeq). Having two different ways of notating the same thing (beginning and end of tunnel / viaduct) just makes it more complicated for editors to learn the already-complex syntax. (Not to mention  (VIADUKT-L)…) I do think that for  (TUNNEL2) and  (BRÜCKE2) it's probably best to use TNL and BRK, both of which have been used already, because (a) four suffixes as I suggested in June is a bit cumbersome, (b) the 2 suffix means absolutely nothing and could be confused with the corner notation and (c) the Ü character is still annoying for Windows users. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 06:18, 31 December 2016 (UTC)

BRÜCKE(n) and TUNNEL(n) are far older than those elaborately named icons.

And please remember who invented those icons, it's ok to make a redirect "BRUECKE", but again:

Don't fix what's not broken!

a×p_de^Hello! 07:46, 31 December 2016 (UTC)

BSicon_FEATURE

Moved from User talk:Jc86035. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 15:02, 31 December 2016 (UTC)

Shouldn't  (FEATUREfq) and  (FEATUREgq) actually have been named   (v-FEATURE) and   (vFEATURE-) (as with  (lv-HST) and  (lvHST-))? AlgaeGraphix (talk) 16:56, 28 December 2016 (UTC)

@AlgaeGraphix: The centre of the circle would have to be at x=125/x=375 for them to be named that, I think. (They currently use 110 and 390.) I could have kept l/r, since I wouldn't expect any naming conflicts with curves with this particular root. Do you think moving them back to the l/r suffixes is a good idea or are they fine as they currently are? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:36, 29 December 2016 (UTC)

It doesn't really make a difference semantically, as l (to the left of "through") and fq moved forward across (left) are equivalent. Perhaps this should be moved to Talk:BSicon/Renaming for more input? AlgaeGraphix (talk) 14:35, 31 December 2016 (UTC)

@AlgaeGraphix: I've moved the discussion. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 15:02, 31 December 2016 (UTC)

Icons with two 90° turns

(Aside from the inconsistently-named categories,)

• Category:Icons for railway descriptions/curve (no “s”)
• Category:Icons for railway descriptions/set u/curve (no “s”)
• Category:Icons for railway descriptions/set mixed/curves (with “s”)

all have icons of the form where the e variant has the upper segment out-of-use and the x variant has the lower segment out-of-use . This is contrary to the (roughly-paraphrased) “direction of travel” rule that parses icon names from top-to-bottom, and should be applied here for determining which is the primary feature (first line encountered: ) and which is the secondary (second line encountered: ). Useddenim (talk) 17:13, 11 December 2016 (UTC)

@Useddenim: I think the "primary line" (out-of-use with x prefix), whatever its importance, seems to be the line closest to corner 3 or the bottom (i.e. wrong way on both axes) for all of the 90° turns. See  (uxmABZ+lr),  (xABZl+l),  (xSTRl+r). May be better to just keep them as they are, unless you feel like doing a lot of page moves and redirect swapping. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:22, 22 January 2017 (UTC)

For parallel lines the "primary" seems to be the line closest to corner 2. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:29, 22 January 2017 (UTC)

The set mixed colours are off here as well:  (uxmABZ+lr),  (uxmSTRr+l). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:35, 22 January 2017 (UTC)

CCanal icon

@Useddenim: Does  (uexTRANSg) use the right prefix? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:46, 25 January 2017 (UTC)

I don't even think it uses the right ROOT. It's a combination of  (uexENDEe) +  (uLENDEa). Using  (uENDExa) as a basis, I come up with   (uENDExaL) or   (uENDExLa) (not  (uLENDExa) ). Useddenim (talk) 13:45, 25 January 2017 (UTC)

@Useddenim: Should all the TRANS icons be renamed to use ENDE? This is a mess, really. A lot of icons seem to be missing the m prefix as well (e.g.  (uLTRANSf)). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:52, 25 January 2017 (UTC)

@Jc86035: I would say yes (but the Canals people might object). Useddenim (talk) 14:02, 25 January 2017 (UTC)

Remaining ÜW icons

@Useddenim, Tuvalkin, and Axpde: Aside from a couple of random tests/deprecated icons and BRÜCKE/ÜST/ÜWB, these are the last icons with IDs containing Ü.

Current	Proposed
(ÜWt1) etc.	lSTRc1o etc.
(ÜWu1) etc.	STRc1o etc.
(tÜWu1) etc.	tSTRc1o etc.
(uÜWu1) etc.	uSTRc1o etc.
(utÜWu1) etc.	utSTRc1o etc.

Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me 13:07, 10 December 2016 (UTC)

• I  agree. The name family ÜW has become a subset of STR ever since corner indications {1;2;3;4} were introduced. -- Tuválkin ✉ ✇ 13:13, 10 December 2016 (UTC)
•  Agree. Useddenim (talk) 14:38, 10 December 2016 (UTC)

@Useddenim and Tuvalkin: Maybe it might be better if STRo1 etc. were used instead? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 08:34, 22 January 2017 (UTC)

• Hmm, maybe it’s a good opportunity to rename these propperly and, instead of just changing ÜW to ÜW, take a good look at all these icons.

• Actually, Jc86035, I don’t think that in these cases "c" should be dropped, as it usually indicates a sliver of line visible at a corner (cp.  (STR1) and  (STR+1) with  (STRc1)…), which is exactly what we have here.
• Also, concerning  (ÜWt1) (and some such), it should not have preffix "l" (bridge formation only) but "M" (mask).

-- Tuválkin ✉ ✇ 23:21, 24 January 2017 (UTC)

@Tuvalkin: I think the o suffix could imply that the mask is there.  (hSTRc2) doesn't even indicate that it has a mask. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:54, 25 January 2017 (UTC)

@Jc86035: :

1. The o suffix indicates a line over — either over another line or over empty space, or with bridge/elevated formation, or both.
2. Many icons with bridge/elevated formations lack masking (and in my opinion they all should) and those who do include a mask should be named to reflect that (since there is M for mask but no special preffix for lack thereof).

-- Tuválkin ✉ ✇ 16:54, 27 January 2017 (UTC)

Coloured road–rail crossings

Moved to Talk:BSicon/Renaming/Roads#Coloured road–rail crossings

Low elevation?

@Plutowiki: What does  (-GIPl) indicate? If it indicates a low elevation shouldn't it use a different root and not use -? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:11, 25 January 2017 (UTC)

•  Info See also  (ex-GIPl). -- Tuválkin ✉ ✇ 01:28, 30 January 2017 (UTC)
•  Comment Indeed. The down-pointing triangle analogous to the gipfel means a lowest relative altitude — here called a nadir (but not illustrated). I created one of these some time ago with a different, yet derived, root:  (lPIG)… Hmmm, it’s GIP backwards, with unintended zoological collateral dammage. (But if railways can have frogs, why not pigs, too?) -- Tuválkin ✉ ✇ 01:28, 30 January 2017 (UTC)
  • @Tuvalkin: Maybe rename lNAD, NADl, exNADl? (PIG is rather interesting, and I wouldn't be opposed to using that just because why not.) Jc86035 (talk) Use {{re|Jc86035}}
    to reply to me 11:01, 30 January 2017 (UTC)

Redirects

Is it really necessary to have all of these redirects for one article on the German Wikivoyage? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:27, 30 January 2017 (UTC)

• Probably not. At the time this was done to enable integration of slightly different icons into the BSicons family and on the other hand avoid disrupting what looked like to be the start of a local naming system seemingly planned for expanded use. Apparently this did not happen (yet?) and therefore it would not be a loss if the contents of that one article were changed to call directly BSicons by their regular names, allowing the deletion of the (then unused) redirects. -- Tuválkin ✉ ✇ 19:18, 30 January 2017 (UTC)

Agree. Useddenim (talk) 01:04, 31 January 2017 (UTC)

@Useddenim and Tuvalkin: Template nominated for deletion here. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:00, 5 February 2017 (UTC)

Okay, but the template needs to be rendered unused before being deleted. -- Tuválkin ✉ ✇ 02:00, 7 February 2017 (UTC)

Junctions at icon edges

@Useddenim and Tuvalkin: Is there any suffix combination (hq?) to indicate a line horizontal at a corner like  (uABZrff) (similar to  (uSTR2h+r) rotated)? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 15:03, 5 February 2017 (UTC)

uABZg3h (because we already have  (uSHI2gr) to indicate to the longitudinal edge). Useddenim (talk) 17:03, 5 February 2017 (UTC)

@Useddenim: This might cause inconsistencies where a line could be both (e.g. ABZ3+24h), and a different suffix ends up being used for different junctions. uABZg3hq might work, or even just uABZg3q (no conflicts possible AFAIK). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:47, 6 February 2017 (UTC)

Unrelated, but  (uABZg+1f) (used in one zhwiki diagram) should probably look like   according to the naming. (Making -F and -G suffixes would solve it, but probably unnecessary.) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 15:11, 5 February 2017 (UTC)

•  Comment: I have no horse in this race, but lines across (horizontal) split along the icon boundary is the one last thing that was left keeping “across” icons apart from regular ones. The cause for this was that such tracks, running along the dividingedge of two diagram rows, cannot have their own text lable in the text columns of the overall table. -- Tuválkin ✉ ✇ 01:55, 7 February 2017 (UTC)

  @Tuvalkin: We already have  (STR-Rq) etc., and these could be useful for junctions between two stations (avoiding having to put the station on the line), like in this diagram. Jc86035 (talk) Use {{re|Jc86035}}
  to reply to me 09:12, 10 February 2017 (UTC)

Indeed, and I see nothing wrong with it — just pointing out that this is/was the last remaining difference between normal and across icons… Well, for regular square icons: varying widths are still the exclusive province of vertically running lines, or of naming in relation to it, and will remain so unless someone comes up with icons for route diagram tables organized by rows instead of by columns, labelled with text running from top to bottom… -- Tuválkin ✉ ✇ 18:40, 10 February 2017 (UTC)

Tunnels across

@Useddenim and Tuvalkin:

Current	Proposed
(uextSTRr+1lr)	uextSTRr+1ea
(utSTR14lr)	utSTR14ea
(uextSTR14lr)	uextSTR14ea

Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:28, 12 February 2017 (UTC)

• Of course. (That should’ve been a no-brainer.) Useddenim (talk) 14:35, 12 February 2017 (UTC)
• Classy solution, I like it, too! -- Tuválkin ✉ ✇ 21:57, 12 February 2017 (UTC)

 Done Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:03, 13 February 2017 (UTC)

Parallel formations

Should  (hvSTRl) etc. use different naming? The current names imply elevated  (vSTRl) curves.

Current	Proposed
(hvSTRl)	hvSTR-L-
(hvSTRr)	hv-STR-R
(hvSTRla)	hvSTRa-L-
(hvSTRra)	hv-STRa-R
(hvSTRle)	hvSTRe-L-
(hvSTRre)	hv-STRe-R
etc. for u / ex versions

Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:29, 10 February 2017 (UTC)

Looks good, too! -- Tuválkin ✉ ✇ 18:33, 10 February 2017 (UTC)

 Agree. Useddenim (talk) 00:21, 11 February 2017 (UTC)

@Useddenim and Tuvalkin: There's also the issue of the  (hSTR-R) group, which use -L and -R to refer to the whole structure instead of just the formations (like with the legende icons and  (hBHF-R)). Would this be a good way of disambiguating them? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 05:37, 11 February 2017 (UTC)

@Jc86035: , I don’t have a good answer for your question here, but one thing I can say: In my opinion there’s nothing wrong in the name symmetry you point out, as

• icon  (hSTR-R) is related to icon  (hv-STR-R) just like
• icon  (STR-R)  is related to icon  (v-STR-R).

Hmmm, heh. I see what you mean. But could the name v-STR-R mean anything other than  (v-STR), anyway? -- Tuválkin ✉ ✇ 13:53, 11 February 2017 (UTC)

@Tuvalkin: If "-R" is taken to mean "right half" (as with  (hSTR-R)) or "moved half an icon width to the right" (I think this is used in a few icons?), then this would probably be  . I guess it doesn't really matter if the suffix means two different things, though. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 15:31, 11 February 2017 (UTC)

 Done, but used ag and ef suffixes instead to match formation length. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:31, 21 February 2017 (UTC)

Half-width junctions

@Vunz and Useddenim: Shouldn't   (dABZ+1r) etc. be dABZr+1f? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:44, 21 February 2017 (UTC)

If this is  (dSTR+r) and  (dSTRr+1) I consider the combination   (dABZ+1r). Might be dABZr+1r however. Vunz (talk) 10:45, 21 February 2017 (UTC)

@Vunz: +1r probably implies that the junction is to f from 1 and r (like  (ABZ+14)), so an icon with that name would be  (but that would be named dABZf+1r like   (ABZf+1r)). Confused as to why you didn't just go with the normal ABZ naming pattern like  (ABZr+1f). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:04, 21 February 2017 (UTC)

OK, but I still don't see why  (ABZr+1f) is not called ABZ+r1f. ABZr+1f should be a combination of  (dSTRr) and  (dSTRr+1), in other words the 'r' should be behind the '+' since it's from the right, not to. Vunz (talk) 11:36, 21 February 2017 (UTC)

@Vunz: I guess it's complicated because of the four different ways that ABZ roots are constructed (for some reason), but it's probably that both lines go to r so r is written before the plus sign. ABZ+r1f would be invalid as the location where the lines meet would be assumed to be f (whether this is a three-way junction or a zigzag), but f is the origin of one of the branches so it wouldn't make sense. Note that the usual top-to-bottom directionality is totally ignored here. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:45, 21 February 2017 (UTC)

I know, and that's why I didn't include f in these icons and I feel my naming is pretty consistent, at least across the half width icons in these category. Still If they need to be renamed, so be it. Vunz (talk) 11:56, 21 February 2017 (UTC)

@Vunz: The problem is that there are three different junctions which link f, 1 and r, and the order of the suffixes distinguishes them. I feel like I'm repeating myself though. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:05, 21 February 2017 (UTC)

Off topic, but @Useddenim and Tuvalkin: the zigzag naming doesn't really make any sense (the second junction seems to be assumed rather than delineated). Wouldn't  (ABZ+13) be  ? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:52, 21 February 2017 (UTC)

Parallel cuttings

@Tuvalkin: Should   (vCUT) etc. be renamed vCSTR? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:09, 9 February 2017 (UTC)

• Yes. Useddenim (talk) 16:56, 9 February 2017 (UTC)
• Yes. -- Tuválkin ✉ ✇ 21:28, 9 February 2017 (UTC)

@Useddenim and Tuvalkin: Renamed; there are about 96 junction icons using CUT as well (e.g.   (CUTl+l)). Should those be renamed to CABZl+l etc.? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:45, 10 February 2017 (UTC)

• Of course; why shouldn't they be? Useddenim (talk) 11:13, 10 February 2017 (UTC)

  @Useddenim: Done, although I haven't modified any of the e…l+l icons to …xl+l. Jc86035 (talk) Use {{re|Jc86035}}
  to reply to me 14:14, 10 February 2017 (UTC)

@Useddenim and Tuvalkin: See also these:

Current	Proposed
(vDAMM) etc.	vDSTR
(vLDAMM) etc.	lvDSTR
(lvDAMM-L) etc.	vDSTR+R (like   (hvSTR+Rag))?
(lvDAMM-Rq-)	KDSTReq+L?
(DAMMc2)	DSTR+c2? (This can't plausibly be a parallel lines icon.)

Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:25, 10 February 2017 (UTC)

Looks good! -- Tuválkin ✉ ✇ 18:33, 10 February 2017 (UTC)

 Done Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:40, 22 February 2017 (UTC)

Suffix order

@Useddenim and Tuvalkin: This group of icons is a bit random, but in summary:

1. Should the 16 HUB icons  (HUBaqf) etc., the 17 WSL icons   (vWSLqa) etc., and the 24 BHFCC/HSTCC icons  (BHFCCqa) etc. have their suffixes reordered so that q is at the end of each name?
2. Should the 120 STR icons   (lhSTR-Ref),   (DSTR-Lag) etc. and the 16 CONT icons   (lhCONT-L+g) etc. have their suffixes reordered so that -L, -M and -R are reordered to be after all other suffixes except q?
3. Should   (evtBHFqo) be evTBHFuq or eTBHFvo?
4. I'm not too familiar with road icon naming. Is there anything wrong with the ones in the list, should they use the (S)KRZ root in addition to SPL, or…?

This is mostly because using q and -L/M/R in the current order seems to go against the convention that suffix modifiers are outwards from the root. I could be wrong, though. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:28, 11 February 2017 (UTC)

• I changed * to # above for better referencing, sorry for being maybe too bold. -- Tuválkin ✉ ✇ 15:42, 11 February 2017 (UTC)

• Concerning the 4th question, generic road icon nomenclature was at first a kind of testing ground for new ideas; later many icons named according with usual BSicon naming rules were added. Some cases of gross inconsistency were dealt with already; what’s left is probably harmless and needed renaming will be evenrually obvious and dully delt with. -- Tuválkin ✉ ✇ 15:42, 11 February 2017 (UTC)

• Concerning the 2nd question, I’d say yes, but out of principle, as I didn’t look at them all. -- Tuválkin ✉ ✇ 15:42, 11 February 2017 (UTC)

• Concerning the 1st and 3rd questions: Yes!, the way that q is most useful and productive to solve most naming problems so many of you puzzle about is this: Use it always and only as a general quarter-turn (90°) anticlockwise rotation indicator, adding it to the very end of any icon name:

Any imaginable (and nameable!) icon  FOO has always its “across” counterpart nameable as  FOOq. Period. (Doesn’t get any simpler, nor more powerful, than this.)

-- Tuválkin ✉ ✇ 15:42, 11 February 2017 (UTC)

@Tuvalkin: Thanks.  Done #1 and #3. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:09, 14 February 2017 (UTC)

@Tuvalkin and Useddenim: To check:   (lhSTR-Lef+c1) would be lhSTRef-L+c1 and not lhSTRef+c1-L, right? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:58, 14 February 2017 (UTC)

 Done all of #2, although I accidentally moved eight lhCONT files to the wrong targets. Should be fixed shortly once the existing redirects are deleted. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:22, 22 February 2017 (UTC)

Bots

Just FYI, JJMC89 has been coding a bot to replace BSicon redirect names and some other things here on enwiki. Could be useful if ported to other wikis. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 15:04, 19 January 2017 (UTC)

@Useddenim, Tuvalkin, and Sameboat: All the redirects on the English Wikipedia have been replaced by the bot. Is it a good idea to extend the name replacement to some of the icons (manually selected) in Category:Icons for railway descriptions/obsolete (such as the CONTl/r icons)? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 15:23, 24 February 2017 (UTC)

• I would say so, but it’s better that inclusion in Category:Icons for railway descriptions/obsolete is properly vetted. -- Tuválkin ✉ ✇ 15:46, 24 February 2017 (UTC)

  @Tuvalkin: The initial list I sent to JJMC89's enwiki talk page is probably uncontroversial enough. Most of the others in the category are only used in a few or no pages on enwiki and should probably be replaced manually. Jc86035 (talk) Use {{re|Jc86035}}
  to reply to me 15:52, 24 February 2017 (UTC)

The list

Old New  (AKRZlf)  (RAl)  (AKRZlg)  (RA+r)  (AKRZrf)  (RAr)  (AKRZrg)  (RA+l)  (AROADlf)  (RAl)  (AROADlg)  (RA+r)  (AROADrf)  (RAr)  (AROADrg)  (RA+l)   (dBHFm)  (dBHF-M)  (eABZ3lf)  (eABZql)  (eABZ3lg)  (eABZq+r)  (eABZ3rf)  (eABZqr)  (eABZ3rg)  (eABZq+l)  (exCONTl)  (exCONTfq)  (exCONTr)  (exCONTgq)  (extCONTl)  (extCONTfq)  (extCONTr)  (extCONTgq)  (tABZld)  (tABZgl+l)  (tABZrd)  (tABZgr+r)  (tCONTl)  (tCONTfq)  (tCONTr)  (tCONTgq)  (uABZld)  (uABZgl+l)  (uABZrd)  (uABZgr+r)  (ueABZld)  (ueABZgl+l)  (ueABZrd)  (ueABZgr+r)  (uCONTl)  (uCONTfq)  (uCONTr)  (uCONTgq)  (uexCONTl)  (uexCONTfq)   (uexCONTr)  (uexCONTgq)  (uextCONTl)  (uextCONTfq)  (uextCONTr)  (uextCONTgq)  (utCONTl)  (utCONTfq)  (utCONTr)  (utCONTgq)

Elevated formations (legende)

Shouldn't icons like   (lhSTR-L+1) have the -L/R after the (+)n (i.e. lhSTR-L+1 → lhSTR+1-L? Changing this would make them consistent with the elevated shift formations (e.g.  (lhSHI2l-L)). Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me 11:05, 9 December 2016 (UTC)

Probably. The mid-name -L and -R was likely derived from  (KBHF-La) etc. Useddenim (talk) 13:10, 9 December 2016 (UTC)

@Useddenim: Should icons like   (lhSTR-Leg) be renamed (e.g. to lhSTReg-L) as well? Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me 11:14, 10 December 2016 (UTC)

? Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me 12:46, 10 December 2016 (UTC)

 Done in a section below. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:02, 4 March 2017 (UTC)

CONT icons

@Useddenim and Tuvalkin: Should  (CONTge) and  (CONTfa) (plus all derivatives) be renamed CONT+f and CONT+g, or should   (hCONT+f) and   (hCONT+g) (plus all derivatives) be renamed the other way? The + syntax is slightly simpler here, but it doesn't really work for icons like  (CONT3+g) (as  (CONTg+3) also exists). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:31, 1 March 2017 (UTC)

  (hCONT+f)→ (hCONTge) and   (hCONT+g)→ (hCONTfa) provides unambiguous clarity as to whether it is a line start or line end. Useddenim (talk) 02:35, 2 March 2017 (UTC)

 Done Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 15:44, 4 March 2017 (UTC)

Another candidate

•  (hSTBHF-Ma)/ (hSTBHF-Me)→? Useddenim (talk) 12:42, 4 March 2017 (UTC)
  • @Useddenim: I already renamed them last month based on  (hSKRZ-Ma) and  (hTBHF) (assuming that TBHF suffixes are the same as KRZ suffixes except for x); is there something wrong with them? Jc86035 (talk) Use {{re|Jc86035}}
    to reply to me 13:47, 4 March 2017 (UTC)

My understanding is that  (TBHF) icons are for bi-level stations, and therefore the T prefix would not be appropriate for a station elevated above some other feature. For example,  (hWHSTae) combines an elevated stop with a river crossing and formation details. Useddenim (talk) 18:00, 4 March 2017 (UTC)

@Useddenim: The only other existing way I can think of is using the α o β syntax for roads (hBHFoRMa), but then we'd be mixing road and rail naming. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 06:59, 5 March 2017 (UTC)

Water crossings

@Useddenim: Should icons like  (lhWSTRag) need the g (or f)? I renamed some of them with the extra suffix for consistency with  (lhSTRag), but it probably doesn't really matter for crossings as evidenced by icons like  (hKRZa). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:58, 4 March 2017 (UTC)

The f & g suffixes are superfluous for crossings. cf.  (hKRZ) :  (hKRZa) (start position is fixed); but  (lhSTRag) :  (lhSTRa) :  (lhSTRaf) (start position is moveable). Useddenim (talk) 17:40, 4 March 2017 (UTC)

Removed the suffixes. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 06:21, 5 March 2017 (UTC)

Parallel bridges

@Useddenim: Why  (vWBRÜCKE1) but  (vBRÜCKE)? Should all of these use one root or the other? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:04, 9 February 2017 (UTC)

BRÜCKE1, because they both have the short formation. Useddenim (talk) 16:59, 9 February 2017 (UTC)

@Useddenim: Renamed all to WBRÜCKE1 and replaced GRENZE with ZOLL; did I rename   (fumvWBRÜCKE1) and   (ufmvWBRÜCKE1) correctly? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:57, 5 March 2017 (UTC)

Road crossing

Moved to Talk:BSicon/Renaming/Roads#Road crossing

More station–road crossings

Moved to Talk:BSicon/Renaming/Roads#More station–road crossings

Junction crossings

@Useddenim and Tuvalkin: Should all of the icons in /crossing+junction (except the k-junctions) be renamed so that the l, r, +l and +r suffixes go before h, t, o and u (for example, from  (uKRZu+r) to uKRZ+ru)?

This is slightly counterintuitive, but basically having the l and r suffixes after o/u creates naming conflicts due to the  (KRZhl) group of icons using l and r to denote the start of a viaduct. For example, the icon name hKRZhr could currently mean either an elevated  (KRZr), or  (hKRZh) +  (hSTRefq). Moving the junction suffixes would eliminate this because the junction would be hKRZrh.

(The reason I'm excluding the k-junctions is that they're all supposed to be corner icons and not specifically junction icons, and are probably in some other section on this page already.)

If this is either too abstract or unnecessary, the below junctions are missing some prefixes. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:20, 6 March 2017 (UTC)

Current	Proposed (with above changes)	Proposed (without above changes)
(uhKRZl+lr)	uhKRZl+lrh	uhKRZhl+lr
(uexhKRZxl+xlr)	uexhKRZxl+xlrh	uexhKRZhxl+xlr
(uxhKRZxl)	uxhKRZxlh	uxhKRZhxl
(utKRZlr+lr)	utKRZlr+lrt	utKRZtlr+lr

Width prefixes

(pinging Sameboat, Useddenim, Tuvalkin, Lost on Belmont, Newfraferz87, Axpde) Currently, there are only three actual width prefixes – c (¹⁄₄), d (¹⁄₂) and b (2). Could we modify/extend them slightly? (This would help greatly with w:en:Module:Routemap, as its implementation of the BStext templates uses a width prefix*text syntax – i.e., d*ABC (in a regular row) – and using things like e.g. leer+cd (1³⁄₄) and leer+dbbb (7¹⁄₂) would be a little cumbersome; especially if all of them, including wider ones, have to be individually hardcoded into the module as exceptions.)

Width	Current	Proposed	Etymology
			German	English
1⁄4	c		schmal	compact
1⁄2	d		dünn	demi
1	leer	r	regelmäßig	regular
2	b		breit	broad
4		s	stark	spread
8		w	weit	wide

This would affect a very small number of current icons – essentially, those containing leer or leer+ as a width prefix. Jc86035 (talk • contributions • uploads) 15:52, 31 July 2016 (UTC)

So is this what you are proposing:

Current	(leer)	(leer+c)	(leer+d)	(leer+cd)	(b)
Proposed	(r)	(cr)	(dr)	(cdr)	(b)	Useddenim (talk) 16:45, 31 July 2016 (UTC)
alternative	( (_)	(  (+c)	(  (+d)	(  (+cd) (  (b-c)	( (b)	a×pdeHello! 06:48, 1 August 2016 (UTC)

Support and Useddenim's speculation makes sense. -- Sameboat - 同舟 (talk · contri.) 00:15, 1 August 2016 (UTC)

1. Why not just dropping the (actually redirected) "leer"?
2. I don't think we need a prefix to indicate something's "regular" -> then every "regular" BSicon has to have the r-prefix ... #shiver#
3. At the moment we "b", "c" and "d" as width-prefixes, so I'd like to see "e" in this row and maybe "a"? It's not in a logical order, but hey, life's not logical ;-)

a×p_de^Hello! 07:04, 1 August 2016 (UTC)

@Axpde: (Useddenim's table row modified to change the order of the prefixes to be from smallest to largest.) Unfortunately, as you probably know, e is already a prefix. I'd have done that too, but there are only so many letters left. Your proposal works, but you're basically using + as a prefix in an awkward order (instead of smallest-to-largest, like cd). I'd assume that any icon without these prefixes would be 500×500 (as usual). Jc86035 (talk • contributions • uploads) 07:24, 1 August 2016 (UTC)

Silly me! Of course erstwhile objects ... #sigh#

Concerning prefix order ... how about the system of latin numbers?

• bc = broad + compact = 2¹/₄
• cb = broad - compact = 1³/₄

...? Ciao a×p_de^Hello! 17:12, 3 August 2016 (UTC)

@Axpde: This would require reversal of the cd prefix, but it seems like a good idea if we ever decide to add more width prefixes. This would be a bit difficult to implement in the module though. Jc86035 (talk • contributions • uploads) 05:08, 4 August 2016 (UTC)

@Useddenim, Sameboat, and Axpde: Could we add r s and w? (To be honest, I'd like to use them in some places like w:en:Template:HK-MTR route/North Island, but I can't add them to Routemap's BStext functionality yet.) Jc86035 (talk • contributions • uploads) 10:22, 16 August 2016 (UTC)

I really don't like the "r", we really don't need a prefix for "regular" icons! All others are ok with me. a×p_de^Hello! 17:53, 18 August 2016 (UTC)

Jc86035 has already explained the "r" is required for pattern analysis in en:module:routemap of a specific function. -- Sameboat - 同舟 (talk · contri.) 02:06, 19 August 2016 (UTC)

@Sameboat and Axpde: Using + before other prefixes would be fine as well (e.g. +db for 3¹⁄₂). Jc86035 (talk • contributions • uploads) 04:53, 19 August 2016 (UTC)

Uploaded  (s) (4),  (bs) (6) and  (w) (8). Jc86035 (talk • contributions • uploads) 11:56, 19 August 2016 (UTC)

I don’t like the idea of using   (+) and - in the width definitions, since + generally denotes “coming from” and - has multiple meanings. Also, Axpde's suggestion for parsing widths like Roman numerals is a bad idea because it is both cumbersome and would also require replacement of all the cd icons. Useddenim (talk) 22:49, 19 August 2016 (UTC)

"cd" is the same as "d", so "cd" isn't needed at all.

How about "dd" instead of "r"? As far as I understand the "r" is only needed for empty icons, or? All other icons without width prefix are regarded as "regular"!

My proposal (assuming that those very special sizes beyond "b" are very seldom needed ...):

 1/4 : c
 1/2 : d
 3/4 : dc
 1/1 : dd
 5/4 : +c (''or'' cd ??? ok, it's not logical, but there's an exception to every rule ;-)
 3/2 : +d ''or'' db
 7/4 : cb
 2/1 : b
 9/4 : bc
 5/2 : bd
11/4 : bcd
 3/1 : bdd
13/4 : cds
 7/2 : ds
15/4 : cs
 4/1 : s
17/4 : sc
 9/2 : sd
19/4 : scd
 5/1 : sdd

... and so on ... a×p_de^Hello! 21:42, 25 August 2016 (UTC)

@Axpde: I thought the convention was to have the smaller prefixes first (from cd)…? Not entirely sure where you got cd = ⁵⁄₄ from, as d - c would just be ¹⁄₄. Jc86035 (talk • contributions • uploads) 07:13, 26 August 2016 (UTC)

As I said, just to have the five-quater-gab filled with a "short" prefix ... call exception that prooves the rule ;-) a×p_de^Hello! 07:51, 28 August 2016 (UTC)

@Axpde and Sameboat: Axpde's original proposal makes a bit more sense looking at  (lHUB+d), and we could extend this to +cdbsw (15³⁄₄). It probably works with the pattern matching in {{Routemap}}, although it's not much of an issue anyway since a table of options would be at most 63 entries long. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:28, 9 March 2017 (UTC)

File:BSicon uhvBS2+l-R.svg

(pinging Useddenim)   (uhvBS2+l-R) → uSHI1+r+h-R; uSHI1+r+lhSHI1+r-R; or replace with  (uSHI1+l) +  (lhSHI1+l-R)? (Formations need to be altered as well.) —Jc86035 (talk • contributions • uploads) 15:19, 5 August 2016 (UTC)

Rename to  (uhSHI1+l-R). @Tuvalkin: any disagreement? Useddenim (talk) 17:05, 11 August 2016 (UTC)

Looks good, one more step in the right direction. -- Tuválkin ✉ ✇ 15:06, 20 September 2016 (UTC)

@Useddenim and Tuvalkin: Since it's apparently possible to apply suffixes to prefixes, would uh-RSHI1+l be valid or is uhSHI1+l-R still preferable? Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me 15:22, 6 December 2016 (UTC)

I see no advantage, in this case, at least, in adding "-R" to the preffix instead of appending it at the end of the name. -- Tuválkin ✉ ✇ 16:19, 6 December 2016 (UTC)

 Done a while ago. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:29, 9 March 2017 (UTC)

Crossings

@Useddenim and Tuvalkin: Does  (KRZhl) or   (SKRZ-G2uhl) use the correct suffix? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:19, 4 March 2017 (UTC)

(Should all the road icons have their suffixes/orientation swapped? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 05:12, 5 March 2017 (UTC))

(Also icons like  (edKRZur). Should these be elevated or something? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 06:56, 5 March 2017 (UTC))

 Done anyway for consistency, by reordering the suffixes. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:31, 9 March 2017 (UTC)

Crossings

Legende

@Useddenim: Where does the "f" in   (lSTRf2) come from? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 15:20, 5 March 2017 (UTC)

For formation overlay; used to complete the formation from  (dKRZ1o). Useddenim (talk) 17:03, 5 March 2017 (UTC)

@Useddenim: It seems like a rather inconsistent use of f; maybe BRIDGE2oc etc. (after  (dKRZ2oc)) might be better? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 00:48, 6 March 2017 (UTC)

Whatever works … (as long as it's not too klunky) Useddenim (talk) 04:20, 6 March 2017 (UTC)

 Done Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:31, 9 March 2017 (UTC)

Half-width diagonal crossings

@Vunz: Shouldn't icons like  (dKRZ1) and  (dKRZ2) be named dKRZm+1/dKRZ2+m for consistency with  (dSTRm+1) and  (dSTR2+m)? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 15:24, 5 March 2017 (UTC)

I named them in consistency with  (dKRZ1o) and  (dKRZ2o) /  (dKRZ1u) and  (dKRZ2u). Vunz (talk) 17:25, 5 March 2017 (UTC)

@Vunz: Okay. I guess it's fine for now since there aren't any possible naming conflicts (which I can think of, anyway). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 00:48, 6 March 2017 (UTC)

Mixed sets

@Useddenim and Tuvalkin: Should mixed icons using sets u/f, u/g, u/W and f/g use the m prefix, or not? I've renamed some of them to remove the prefix based on the naming of  (uxgKRZu) and others, but it all seems very inconsistent. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:23, 9 March 2017 (UTC)

• I think it  should, and I have used it even for mixed “other color” icons. But a clear set of naming guidelines should be set up. -- Tuválkin ✉ ✇ 19:12, 9 March 2017 (UTC)
• I thought the m prefix was for mixed sets that had      be2d2c (or      d77f7e) + another colour. Useddenim (talk) 00:33, 10 March 2017 (UTC)
  • @Useddenim and Tuvalkin: I renamed the icons based on an old discussion about the naming of crossings (consensus seemed to be first prefix–e/x–second prefix), although the discussion's from 2013, and it might be better now to use first prefix–second prefix–e/x–m like  (uWmvSTRa) (should be SPL), especially as splitting the prefixes with e/x is rather unintuitive. Jc86035 (talk) Use {{re|Jc86035}}
    to reply to me 10:59, 10 March 2017 (UTC)

Nomenclature: Single and double parallel crossings

Is there an agreed nomenclature for parallel crossings of straight lines (double over single across, double over double across, single over double across)?

Consider  (vKRZ),  (vKRZv),  (KRZv), and other variations on grade/type (see catalog). The "v" prefix denotes vertical parallel tracks, the "v" suffix denotes horizontal parallel tracks. From a complex example such as  (umtvKRZvto), we see that the "v" is always tied directly beside the KRZ. This is somewhat akin to the  (mhKRZh) series, where the elevation type ("h" and "t") are next to the root. The majority of the icons listed on the catalog were uploaded by Imperator3733.

With this rule in mind (I had assumed it to be correct), I moved several icons, mostly those with single over double across with "q" at the end, into their new names with suffix "v". However, Tuvalkin was adamant that the naming rule was not agreed upon and the renaming issue should be brought up, and refused to let me rename his two icons   (exvKRZq) and   (uvKRZq). Now that we have arrived at an impasse, and I believe it is unwise to leave the issue with two different and incoherent types of icon nomenclature, I find a need to raise this issue for discussion. A previous mention regarding this issue was noted here.

Comments? NoNews! 09:56, 18 February 2016 (UTC)

• @Newfraferz87: Probably move them; using q here is unnecessary because there are vertical lines for all combinations (unlike the horizontal–diagonal KRZ icons). Incidentally, is the "o" or "u" (under/over) always at the end of the file name? We might have to rename  (mKRZuSHI1lq). Jc86035 (talk • contributions • uploads) 05:21, 19 June 2016 (UTC)
• My dear fellow, you can rename whatever you want: yours will remain the burden of that decision. My opinion against such renaming stems from the following:

1. The rule that says that "q" is a suffix that turns 90° degrees anticlockwise the preceding layout is simple, clear, and of universal applicability within BSicons.
2. The rule that says that parallel lines across (horizontal) are to be named as their vertical counterparts by ommiting the tell-tale "v" preffix is inherently fragile, ambiguous, and unintuitive, and applies only to parallel lines.

What makes that latter rule a thing at all is that it was devised in a moment of lacking inspiration and clarity and used to name a fair number of icons. Most of us value name stability over strict logic and homogenous convention and that kept those many poorly named icons unrenamed in spite of a few that that are logically named.

You now want to rename those few logically named vFOOq to the illogical FOO; later on the very absence of logically named vFOOq icons will be reason to argue in favour of the FOO rule — that’s the kind of dishonest trickery that we’d expect to have got rid of from within the BSicon user community.

-- Tuválkin ✉ ✇ 21:37, 29 July 2016 (UTC)

@Tuvalkin: I'm a little confused; according to Newfraferz87's logic, wouldn't vFOOq be moved to FOOv? In addition, using the q suffix prevents doing things like applying e, x, m and um affixes to individual parts of a parallel crossing. Jc86035 (talk • contributions • uploads) 16:17, 30 July 2016 (UTC)

Thanks for poiting that out, User:Jc86035, about it being FOOv not FOO: So, it’s not the old inane rule, its yet a new development for an even more specific situation of turned icons (just like before we already had “novelties” such as  (DSTq-DSTq) or  (uSTRq-uSTR+r)).

As I have been saying for 2 or 3 years, not using "q" as a general purpose terminal suffix for “blind” 90° anticlockwise rotation of any icon will cause this kind of ever increasing additional rules for specific situations, more and more intrincate, unintuitive, and ultimately illogical.

And, no: Using the "q" suffix (as described above) doesnt’t prevent anything at all. If you can name an icon, you can automatically name its 90° anticlockwise rotated version by adding a terminal q. Period. If you cannot understand this, you cannot understand how this ";-)" is a smiling winking face, and if you don’t you should not be in the internet. ;-)

-- Tuválkin ✉ ✇ 17:31, 30 July 2016 (UTC)

@Tuvalkin: So I hadn't read w:en:RDT/C#Transverse parallel lines before I wrote my comments. Sorry about that. (It might be out of date anyway, given that – for example – in 2014 YLSS moved mvKRZqu to mKRZvu, questioning the logic of the former name.) Anyway: What would you actually call a mixed-over-mixed crossing, using your preferred naming pattern? I'm honestly not sure if that's possible, or if you'd be stuck using 3 qs. Using the "v after" rule would probably produce vmKRZvm or vmKRZmv.

Using the dash-dash thing apparently also implies that there isn't a connection between the two KRZ bridges –  (umtKRZto-umtKRZto);  (umtKRZvto) (both uploaded by Useddenim). Is that supposed to happen? Jc86035 (talk • contributions • uploads) 10:06, 1 August 2016 (UTC)

@Useddenim: Should the few icons which use the q suffix where the v suffix could be used instead be renamed? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 04:49, 12 March 2017 (UTC)

I would say “Yes”. Useddenim (talk) 17:20, 12 March 2017 (UTC)

STq

Should   (STq) be MREq? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 16:26, 6 March 2017 (UTC)

• Anything to reduce the number of 2-letter icon IDs and to reduce the number of icon IDs that start with "S" (and "B"!) is welcome! -- Tuválkin ✉ ✇ 13:06, 15 March 2017 (UTC)
  • @Tuvalkin: On second thought it's probably better to rename it RWq (based on Useddenim's category naming) because a mask would be #f9f9f9 and not white. Jc86035 (talk) Use {{re|Jc86035}}
    to reply to me 13:26, 15 March 2017 (UTC)

Parallel lines

Primary Secondary

@Useddenim, Tuvalkin, Axpde, and Sameboat: Which track in parallel lines is primary? The enwiki catalogue appears to say that the down-the-line left track is the primary, but many icons (some here, and some of the ones I just moved) are named so that the primary track is the right track. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 16:25, 14 January 2017 (UTC)

See diagram. Useddenim (talk) 16:38, 14 January 2017 (UTC)

@Useddenim: Well, that's a lot of files to rename/replace, given that the catalogue itself (using example  (xvBRÜCKE) among others) is apparently wrong. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 16:43, 14 January 2017 (UTC)

That's the rule I've been following, since it conforms to the compound icon naming format (for example,  (vSTR-BHF). Is there anything explicitly stated somewhere? Useddenim (talk) 17:22, 14 January 2017 (UTC)

@Useddenim: Wikipedia:Route diagram template/Catalog of pictograms states:

All Icons with a symmetrical subject such as bridges (either highway, normal or waterway), borders and tunnels but excluding icons for crossings with other railway lines and stations use the following naming convention:

• v prefix, both lines in use: , ,
• ev prefix, left line disused, right line in use: , ,
• xv prefix, left line in use, right line disused: , ,
• exv prefix, both lines disused: , ,

Note that all the road crossings are probably incorrect as well because the road should be the secondary feature and not one of the tracks. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 17:26, 14 January 2017 (UTC)

Also pinging Vunz. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 17:27, 14 January 2017 (UTC)

Hmm… Given that (I believe) I was the one who added those lines to the Catalog, I guess I went off track somewhere. (Pun intended.) I changed the diagram above to match. Useddenim (talk) 17:58, 14 January 2017 (UTC)

@Useddenim: Could you help with some of these icons? The mixed ones need to have the colours swapped [files need to be reuploaded and usage swapped], although the e/x prefixes are okay. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 08:20, 15 January 2017 (UTC)

Replacement might be easier for some icons as most diagrams still use the old redirects for icons like  (mvSTR). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 08:31, 15 January 2017 (UTC)

e.g.  (mvSTR)

Primary (heavy railway) Secondary (light railway)

Obviously most uploaders have a different opionion to what Useddenim proposed. And there is a majority of two track lines driving on the right hand side! So you better change it the other way round! a×p_de^Hello! 12:56, 15 January 2017 (UTC)

@Axpde: The block of text highlighted above was added on 4 June 2011 and you are just now pointing out that it is reversed?
@Jc86035: I think you better put the brakes on any more renamings/colour switches.
@Tuvalkin: You wrote that explanation in the first place; can we have your comments please? Useddenim (talk) 13:19, 15 January 2017 (UTC)

@Useddenim: Haven't renamed anything affected by this after realizing the inconsistency and posting this section, and won't until consensus is reached.

@Axpde: Not sure it particularly matters what the majority is, given there isn't any direction indicated anyway. (The convention of the left down-the-line track being the main seems to have been in place for almost seven years, since about when Vunz uploaded the current version of  (evSTR) in March 2010.) Why am I (in particular) supposed to be the one changing it around? I'm just noting that I realized there's an inconsistency and that it would be better if it were fixed. (You'd expect  (emvSTR3) to use the same colours as  (emKRZo).) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:45, 15 January 2017 (UTC)

@Jc86035: Sorry; I just saw a lot of parallel line icons in AlgaeGraphix’ most recent BSicon report. Useddenim (talk) 14:25, 15 January 2017 (UTC)

@Useddenim, Axpde, Sameboat, Tuvalkin, and Lost on Belmont: ^{@Newfraferz87, Vunz, Mahir256, Imperator3733, and Circeus:} So should the primary track for parallel lines be the down-the-line left track (as it has been for non-mixed icons since 2010)? I suppose we could keep it the way it is and use opposite conventions for open/closed and mixed tracks, but that doesn't really make any sense. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:10, 16 January 2017 (UTC)

My two cents: If I recall correctly the naming convention of the file  (evSTR) I uploaded in 2010 was based on someone else's and older work. For crossings with other rail it would indeed be better to change to something the likes of  (veKRZ-exKRZ) so it would match the naming of two half-width icons albeit with a 'v' prefix instead of 'd'. However these  (evÜSTx),  (xvÜSTx),  (evÜSTlxr) etc. pose a challenge. Vunz (talk) 12:21, 16 January 2017 (UTC)

@Vunz: not sure if those are relevant; the issue is because icons like  (emvSTR3) are coloured so that the primary track is the left track for open/closed indication and the right track for the set indication. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:26, 16 January 2017 (UTC)

1. Dewiki invented the BSicons and set up the basic rules, those are undisputable!
2. Nlwiki invended the parallel BSicons and set up the basic rules, those are undisputable, too!
3. Don't try to "fix" things that aren't broken!

a×p_de^Hello! 15:56, 16 January 2017 (UTC)

@Axpde: Quoting you twice, "those are undisputable" and "you better change it the other way round" are quite conflicting, and I'm not sure how applying blanket statements to this helps, really. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 01:48, 17 January 2017 (UTC)

I'm really confused by this entire discussion since no one seems to have linked to an actual example of simple (i.e. NOT belonging to stuff like the ÜST family pointed out by Vunz above) parallel line icon with a name asserted to be facially incorrect. Until I see an actual pair of icons with names that contradict each others, I won't be able to make any sense of this debate.

I believe what's going on is that people are confusing the definition of "primary lines" used for e- and x- on single-line icons and how they were applied to double-line icons.

As I understand it, it's a more straightforward mnemonic to remember that e- and x- correspond to the same location on a double track icon (e is on the left of the name, and thus corresponds to the left track). In this particular case, we're not strictly speaking defining a certain track as primary. At least that's the impression I'm getting in the absence of an example of the "problem" we are supposedly talking about here. Circeus (talk) 17:38, 16 January 2017 (UTC)

@Circeus: Some of the mixed icons with horizontal tracks are the other way round from the other icons, like  (mvSTRq) (although this is probably my fault). Upon closer inspection I agree that there aren't really any conflicts aside from those five horizontal icons (I might have been confused by Useddenim putting the first diagram the other way round at the start of the discussion; not sure really), but it seems a bit illogical to use different colours for (e.g.)  (emvSTR2) and  (emvKRZ). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 01:48, 17 January 2017 (UTC)

The horizontal thing has always been a bit of a problem because I don't think the original guidelines were ever clear enough as to the direction that was to be used to define left and right (or beginning and end) for horizontal icons.

In so far as  (emvKRZ) perfectly parallels  (emKRZ), I don't see the issue, but I'll agree coming up with a well-defined system to deal with the interaction of mixed double and simple track may be eventually necessary. I believe those types of icons weren't very prominent when I set out to review the system years ago. At least  (mvSTR※ uexSTRq)  (whatever its name if it already exists) is readily dealt with using the hyphenation system, namely emKRZ-ueKRZ. Indeed that system was created pretty much precisely for such cases. Circeus (talk) 04:02, 17 January 2017 (UTC)

@Circeus: I guess the rule of "q means 90° anticlockwise" works well enough, although I don't think I knew about it in 2015.

As for the KRZ icons (wouldn't that icon be vemKRZ-ueKRZ?), I think they're probably a separate issue but per  (vKRZv),  (vKRZh) and others we could just tack the prefixes on as suffixes (although e and x, as well as multicolour sets, might be problematic). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:41, 17 January 2017 (UTC)

@Jc86035: Yeah, you're right about the horizontal lines and that icon's name. I think I still had in mind older sideways icons that had to change names years ago when I talked about -q icons. I am VERY out of the loop and out of practice with BSicons (although I am flattered that my efforts back then make people still consider me an authority XD).

I think basically people misunderstood your initial question leading to the thoroughly confused discussion by the time I arrived. I'm not entirely sure whether the confusion had cleared by then (My Asperger makes it hard for me to tell) or if there is still confusion.

Basically v- icons use specific meanings for what color apply where (i.e. for e-, x- and m- mostly. When I was still active in the area, none of them used g-) which are independent from the rules applied to single-line icon. I'm not sure these icons are named in a fashion that presume either line to be primary at all (if it gets even moderately complex, they move to dashed names), but take that statement with a grain of salt given what I said above about being out of practice... Circeus (talk) 01:27, 18 January 2017 (UTC)

@Useddenim: , I don’t remember having written that explanation at all (it was you?), but here’s my thoughs about all this in a nutshell: As was exposed by Jc86035, there seem to be inconsistencies in the usage of several prefixes and in the naming of vast families of icons, all stemming from an “unsimple” way to chose the Primary vs. Secondary line in «close paralllel lines» icons. Unlike Axpde, I dont think that the proto-history of these icons should prevent changes, provided that naming becomes simpler, easier to understand and use. Having a simple single criterium to pick the primary line among two seems to be worth doing. There will have to be a lot of renaming, but time is right for that now. Lets chose, after careful thinking, one of the two lines to be the primary, in all cases, then stick with it and start renaming, however slowly. -- Tuválkin ✉ ✇ 11:38, 20 January 2017 (UTC)

Oops. I added it to en:WP:Route diagram template/Catalog of pictograms#Parallel lines, copied from your Talk page, but Wiebevl (now Vunz) wrote the explanation. Useddenim (talk) 12:57, 20 January 2017 (UTC)

@Tuvalkin: If we're going to do that, most diagrams seem to use the vSTR-uSTR-type redirects anyway for  (mvSTR) etc., so moving the more common files (round-robin moves?) shouldn't affect a lot of diagrams. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:44, 20 January 2017 (UTC)

@Jc86035: Well, even better: Renaming is a hassle because it usually envolves changing also file usage across projects. -- Tuválkin ✉ ✇ 11:51, 20 January 2017 (UTC)

@Useddenim and Circeus: Do you think this is worth bothering to do? About 196 files are affected; most of them are unused outside catalogues. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:00, 22 January 2017 (UTC)

I'm no longer very involved in this area in general, but I'm not entirely sure what you want to rename these to since most of those (e.g. pretty much every single one f those which includes a curve) can't be give names with dashes in the first place. Furthermore, I don't see a single problematic one in that list, given what I said here, and which no one seems to find an inaccurate description of why these icons bear these names. I'm assuming of course that it IS accurate and that there are not actual pair of icons whose names facially contradict each others, since no one has actually bothered to present an example thereof so far. Circeus (talk) 09:58, 22 January 2017 (UTC)

@Circeus: The issue, I think, is that the um and m prefixes should be swapped. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:01, 22 January 2017 (UTC)

OH, yeah, that's a completely separate issue from what was being discussed above, thanks for clarifying that XD (I'm on break in the middle of a night shift, so that isn't helping). It does seem sensible to have u- be the "implied" color prefix of m- consistently, especially if so few of the icons seem to use the um- combination. Circeus (talk) 10:14, 22 January 2017 (UTC)

@Circeus: I think I accidentally confused you even more ("implied"?), so to clarify: pairs of icons like  (mvSTR2)/ (umvSTR2),  (emvSTR3)/ (uemvSTR3) and  (emvÜWB)/ (uxmvÜWB) would have their names swapped in round-robin page moves. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:24, 22 January 2017 (UTC)

@Tuvalkin and Axpde: I just noticed that the mvÜWB and mvSTR sets don't even match each other's colours, so some files are definitely going to need renaming. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:24, 22 January 2017 (UTC)

I'm not going to voice any opinion at all on this one, really. It doesn't seem at first blush to be actually fixing any clear issue that exists in the system as is. 11:01, 22 January 2017 (UTC) — Preceding unsigned comment added by Circeus (talk • contribs)

m em uxm uexm prefixes vSTR+1 vÜWB For reference m em uxm uexm KRZ ABZgl STRr+l (disputed)

Hope the diagram helps. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:36, 22 January 2017 (UTC)

Actually I was talking about the post above it about swapping mv- and umv- icon names rather than the issue specific to ÜWB. For others who might not have noticed (it took me a bit realise myself): the problem is that  (evÜWB) and  (xvÜWB) have the correct unused line, but for some reason, the mixed use icons are the other way around, with e- and x- positions swapped. This is almost certainly owing to the fact they have not yet been actually used for a routemap and were apparently never in the same catalog table as the basic icon (which would have revealed the problem immediately). Circeus (talk) 12:43, 22 January 2017 (UTC)

@Circeus: I think that's because Useddenim erroneously gave the convention as being " (1st line)  (2nd line)" back when Imperator3733 was going through the empty table cells in the catalogue in September 2015, and Tuvalkin didn't check before reuploading/uploading all the icons in the set with the line colours swapped. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:59, 22 January 2017 (UTC)

Can we avoid talking about colors? It's really ambiguous since the problem we are talking about is not about blue vs. pink lines. It's line status that's a problem in those icons i.e. the e- and x- versions of the icons are the ones swapped around, not m- and um-. Circeus (talk) 13:26, 22 January 2017 (UTC)

@Circeus: From the "primary/secondary" POV, where the primary (left going down the line) is set u with prefixes um and out-of-use with prefix x (like  (uxmKRZ)), both groups of prefixes are wrong so those icons' tracks should have their colours swapped. I just used it for sake of brevity. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:43, 22 January 2017 (UTC)

Of course, if we ignore the primary/secondary track thing (against Tuvalkin's suggestion), then it's just the in use/out of use status. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:59, 22 January 2017 (UTC)

1. I've already stated I don't care one bit for the m- vs um- thing. It doesn't seem to bring any set of icon in line with any other set (and I don't consider that the parallel line are "brought into consistency" with single line icons in this regard, since the similarities are hardly obvious to anyone). I have seem no standardization need/inconsistency put forth to justify swapping by swapping around pairs such as  (mvSTR2) and  (umvSTR2).
2. However, the e- and x- lines in the mÜWB set of icons are clearly swapped around compared to the base versions ( (evÜWB) vs.  (emvÜWB)) and that requires fixing regardless of what is decided regarding the m- vs. um- thing.

Circeus (talk) 14:07, 22 January 2017 (UTC)

@Useddenim and Tuvalkin: Should we just fix the e/x versions of the mvÜST icons and  (mvSTRq) (should be flipped) etc.? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:03, 30 January 2017 (UTC)

 Done anyway (swapped about 36 icons' names). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:02, 16 March 2017 (UTC)