Talk:BSicon/Renaming

From Wikimedia Commons, the free media repository
Jump to: navigation, search
See also: Talk:BSicon/Renaming/SPL,
Talk:BSicon/Renaming/ABZ,
Talk:BSicon/Renaming/k and
Talk:BSicon/Renaming/Canals

BSicon TEE+[edit]

Aren't   (TEEl+xr) and   (TEEr+xl) just special forms of   (KRZ)? AlgaeGraphix (talk) 22:22, 26 September 2015 (UTC)

  • Symbol support vote.svg Support: I can see you point, but I think that seeing these as TEEs is in fact a good idea. The reasoning behind it (which I presume to comprehend fully) is that something like   (TEEr) is a railway impossibility — it should be either   (ABZlg) or   (ABZrf); and therefore TEEs are restricted to situations where they represent something other than a railway (departing from the original semantics).
The   (KRZ), in this regard, is seen as a simple flat cross of two independent rail lines, allowing only two directions and no sharp turns. With this in mind, what would   (TEEl+xr) represent if it were a variant of   (KRZ)? Something like BSicon .svgBSicon ENDExeq.svgBSicon vSTR-.svg  (but centered), perhaps?, but if so the bumper block should be present, as it is in things like   (ENDExeq). However, if   (TEEl+xr) is seen as a special case of TEE, which allows/presuposes sharp turns, then there’s no need for a bumper block and the meaning is clear.
-- Tuválkin 01:42, 27 September 2015 (UTC)
  • Symbol oppose vote.svg Oppose: I cannot, however, extend the same approving rationale to things like   (BHF+TEEr+xr): These are better seen as a mix of a regular station and a terminal station, for which we do have long established icon ID roots — I propose either:
  • BHF+KBHFxr (or, better, BHF+KBHFxeq), based on   (BHF) and   (KBHFxr), or
  • TBHFxr (or, better, TBHFxeq), inspired by   (TBHFr) and   (KBHFxr).
This agrees with the reasoning above by assuming that in every terminal station (KBHF) there is a “hidden” line ending (ENDE), as in BSicon .svgBSicon exlBHF grey.svgBSicon ENDEa.svg , and therefore   (BHF+TEEr+xr) can be seen as BSicon .svgBSicon exlvBHF grey.svgBSicon vSTR-.svgBSicon ENDExeq.svg . -- Tuválkin 12:22, 28 September 2015 (UTC)
  • Note that   (BHF+KRZ),   (BHF+TEEr),   (BHF+TEEl) are duplicates of   (TBHF),   (TBHFl) and   (TBHFr). NoNews! 00:27, 28 February 2016 (UTC)
I would say that BHF+KRZ, BHF+TEEr & BHF+TEEl should be deleted in favour of the TBHF equivalents. de:WP discusses it here, with no apparent conclusion. (Perhaps someone who is more fluent in German than Google Translate could confirm this?) Interestingly, BHF+KRZ is approved for de:WP’s Bilderkatalog, but   (TBHF) which has been around since 2007 and is fairly widely used (~250 instances), is not. Useddenim (talk) 16:25, 5 March 2016 (UTC)

Nomenclature: Single and double parallel crossings[edit]

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 (talkcontributionsuploads) 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 (talkcontributionsuploads) 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 (talkcontributionsuploads) 10:06, 1 August 2016 (UTC)

Category:Icons for railway descriptions/stations and stops/BHF/one side/direction[edit]

See also: Talk:BSicon/Renaming/Archive 6#Name collision: BHFlf/HSTlf etc.

These names have bothered me (and @Axpde:) ever since I created the icons...

Old New Reused name
  BHFlf BHFfl  
  BHFrf BHFfr  
  BHFrg BHFgr  
  BHFlg BHFgl  
  BHFll BHFflq
  BHFlr BHFfrq
  BHFrr BHFgrq
  BHFrl BHFglq

This would bring these icons in line with   (STRlf),   (STRf),   (BHFl),   (CONTfq), etc. Useddenim (talk) 00:58, 21 February 2016 (UTC)

In addition to the BHF's, there's also the INT/uINT variants such as   (INTlf),   (INTrf),   (uINTrl),   (utINTll), and parallel variants such as   (vBHFrf-BHFrg).
For the first four, take note that the new suffixes are already in use for some icons (such as   (CONTgl) and   (exCONTfr), alongside the "older" suffixes such as   (CONTlf)). If the change would not cause ambiguity or confusion, then I'm fine with the renaming.
(Also take note of User:京市's misnamed icons,   (exhBHFl),   (uhBHFl),   (uexhBHFl) and in various other colors, uploaded June 2015)
The last four would seem somewhat convoluted, but I don't have any better suggestions at the moment. Some other (non-standard?) variants include   (pBHFrq). NoNews! 10:51, 21 February 2016 (UTC)
Yes! Absolutely. This has bothered me for a while and this scheme of direction and side of track makes perfect sense. Lost on  Belmont 3200N1000W  (talk) 14:56, 21 February 2016 (UTC)
@Lost on Belmont, Newfraferz87, Useddenim: Since I've requested renames for the second half of the table to BHFlfq etc. per this section, the icons in the fourth column could use the l, r, +l and +r suffices instead. (The existing   (BHFl) and   (BHFr) appear to not be used anywhere, except for one page on ruwiki. There's also a set of four HST icons which uses nonstandard naming. Maybe we could replace all of them with versions with arrows?) Jc86035 (talkcontributionsuploads) 10:18, 16 August 2016 (UTC)

Added icons[edit]

Reposted from Talk:BSicon/Renaming/Archive 4#Added icons.

Hello! Don't know if I am writing on the right page. But I made som new icons to make a map smaller on SvWP.

The icons is:

BSicon KBFrg.svg File:BSicon KBFrg.svg
BSicon KBFrf.svg File:BSicon KBFrf.svg
BSicon ABHFl+xl.svg File:BSicon xKBFlg.svg
BSicon KBFlg.svg File:BSicon KBFlg.svg
BSicon KBFlf.svg File:BSicon KBFlf.svg

I didn't know if the names got 100% correct, feel free to change them if it's wrong according to the standard. Didn't either put them in the Bilderkatalog-category as the sign says.

Have a nice day! --Civilspanaren (Diskussion) 22:29, 15. Mär. 2013 (CET)

All terminal stations have the root ID "KBHF". Anyway those icons don't need to be terminals, so "BHF-L" or "BHF-R" should be correct. You might wanne discuss this on Talk:BSicons. Bye a×pdeHallo! 23:43, 15. Mär. 2013 (CET)
Consider:
Current Others Should be
  (KBFlf)   (STRlf)   (BHFlf)   (BHFlff)
  (xKBFlg)   (ABZl+xl)   (BHFl+xl)
  (KBFrg)   (STRrg)   (BHFrg)   (BHFrgg)
  (KBFrf)   (STRrf)   (BHFrf)   (BHFrff)
  (KBFlg)   (STRlg)   (BHFlg)   (BHFlgg)
Of course, that presupposes that these should even be kept. Useddenim (talk) 04:48, 22 February 2016 (UTC)

Suffixes "o"/"u": before or after "x" & "h"/"t"?[edit]

This question came to me while I renamed the   (extTINTxto) icon and its variants   (tTINTto),   (xtTINTto): what is the ideal order of the "o" and "u" with respect to the other suffixes?

As far as I know, this problem mainly pertains to icons with stations/features on junctions, i.e. those with "T" as part of the root id, as they require a grade suffix (none/"h"/"t") for the horizontal track, and an "x" suffix, to be added in front of the grade suffix to denote off-use. The existing naming scheme in icons such as   (uTHSTxu) and   (hTBHFho) also positions the bridge/elevation separation suffixes "o" and "u" after the grade suffix. So we have "x" (for horizontal off-use), "h"/"t" (for grade of horizontal track), and then "o"/"u" (for the elevation difference of vertical versus horizontal).

But this nomenclature may lead to possible problems in understanding the icon, as now the "o"/"u", when paired with the "x", can lead to ambiguity as to which side is off-use.   (THSTxo) can have the unwanted meaning of "x"-ing the "o"ver, i.e. the overcrossing track is ex'd, which is not the case.

I have considered the alternative option of moving the "o"/"u" in front of the "x", as in THSTox / tTINToxt, which helps to visually separate the station/feature and vertical track (the prefix, root and "o"/"u") from the horizontal track (the "x" and "h"/"t"). It is more logically coherent to call an icon "interchange over unused horizontal track" than "interchange with unused horizontal track, vertical track crossing over horizontal track".

But once again, there's different rules for other languages, as well as dozens of icons involved (using these suffixes), including the various diagonal variations (even with somewhat conflicting schemes such as   (exkKRZuxlr+xr),   (KRZoxl) and   (tKRZqf+1tu)), so I am apprehensive to any changes.

Any inputs? NoNews! 10:05, 26 February 2016 (UTC)

@Newfraferz87: I'd rather have the "o" and "u" suffixes right after KRZ/T[BHF]/whatever (per reasons above); it's also consistent with several files which were very recently renamed to have "u" or "o" immediately after the main track's root/suffices (e.g.   (STR3uh);   (STR2+4uhc4)). It also additionally reduces any potential issues with any KRZ icons involving single-line parallel tracks (see the section below). Jc86035 (talkcontributionsuploads) 09:30, 22 June 2016 (UTC)

k curves[edit]

Is it just me, or is the naming of the icons in Category:Icons for railway descriptions/k/curve (and various related categories) really inconsistent? Jc86035 (talkcontributionsuploads) 10:01, 12 June 2016 (UTC)

  • …and Yes. Useddenim (talk) 13:07, 12 June 2016 (UTC)
  • Not just you, for sure. But I suspect that the many such inconsistencies that plague the BSicon tree are being side-stepped by all of us while we keep on nonetheless doing improvement work on its categorization — starting with the basic error of misusing a generic category name to mean what should logically be categorized specifically as Category:BSicon. I think that once the proper approach gets a modicum of use (as was hinted at with this cat), it will snowball fast and the changes will smooth out these and other quirks and kinks. -- Tuválkin 23:59, 12 June 2016 (UTC)
File Should be Similar to
  (kSTRgr)   (kSTR3)   (STR3)
  (kABZgr)   (kABZg3)   (ABZg3)
  (kABZc4)   (kSTRc4)   (STRc4)
  (kSTRqr)   (kSTRr+1)   (STRr+1)
  (kABZqr)   (kABZq+1)   (ABZq+1)
 
File Should be Similar to
  (kSTRgl)   (kSTR2)   (STR2)
  (kABZgl)   (kABZg2)   (ABZg2)
  (kABZc1)   (kSTRc1)   (STRc1)
  (kSTRql)   (kSTRl+4)   (STRl+4)
  (kABZql)   (kABZq+4)   (ABZq+4)
  (kSTRq+r)   (kSTR2+r)   (STR2+r)
  (kABZq+r)   (kABZq2)   (ABZq2)
  (kABZc3)   (kSTRc3)   (STRc3)
  (kSTRg+r)   (kSTR+4)   (STR+4)
  (kABZg+r)   (kABZg+4)   (ABZg+4)
  (kSTRq+l)   (kSTR3+l)   (STR3+l)
  (kABZq+l)   (kABZq3)   (ABZq3)
  (kABZc2)   (kSTRc2)   (STRc2)
  (kSTRg+l)   (kSTR+1)   (STR+1)
  (kABZg+l)   (kABZg+1)   (ABZg+1)

I’m not sure how to name the kAB~ icons, though… Useddenim (talk) 10:35, 13 June 2016 (UTC)

@Useddenim: maybe (for example)   (kABlg)kABZf+4r (like   (ABZf+4r))? Jc86035 (talkcontributionsuploads) 09:13, 17 June 2016 (UTC)
Ah, but notice which side of the corner the stroke goes to:   (kABlg) vs BSicon .svgBSicon STRlg.svgBSicon kSTRg+r.svg (kSTRg+rSTRlg) . Useddenim (talk) 10:21, 17 June 2016 (UTC)
@Useddenim: How could we put SHI+r (or similar, assuming you're not renaming the k shift icons) into the icon name? Jc86035 (talkcontributionsuploads) 12:02, 17 June 2016 (UTC)
Change the prefix from k to ks (for k-shift). We've done similar name-bending for HUBs (  (HUBsr) for example) and generic roads. Useddenim (talk) 16:59, 17 June 2016 (UTC)
@Useddenim: I think that leaves   (kBHFl+l) (and lr, qlr, TBHFlr),   (kBRKuf) (and ug), everything in category /formations/elevated/k and subcategory, and possibly category /k-crossing and subcategories. Jc86035 (talkcontributionsuploads) 05:40, 18 June 2016 (UTC)
Old New Comment
  (kBHFl+l) BHFk12
  (kBHFlr) BHFk14
  (kBHFqlr) BHFqk14
  (kTBHFlr) TBHFk14
  (kBRKuf) BRKukq bridge, under, k feature, moved forward
  (kBRKug) BHFukf bridge, under, k feature, moved back
In all cases, k becomes a suffix because it refers to the secondary feature. (BSicon .svgBSicon lBHF.svgBSicon kSTRgr.svg (kBHF3) , for example, should exlain why.)

┌─────────────────────────────────┘
@Useddenim: Did you mean BRKukf and BRKukg? Jc86035 (talkcontributionsuploads) 05:56, 19 June 2016 (UTC)

I totally support standardising the kABZ/kSTR suffices to those of STR (aka UW). The transverse set of kABZ/kSTR in particular is the worst offender, they are downright not intuitive to remember. Also not to forget the 3-way junctions:   (kABZglr) and   (ABZg23). -- Sameboat - 同舟 (talk · contri.) 09:30, 29 July 2016 (UTC)

Suffixes: a, e / TUNNEL1 and TUNNEL2[edit]

  • 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 (talkcontributionsuploads) 14:26, 16 June 2016 (UTC)

Symbol keep vote.svg Agree. Useddenim (talk) 10:14, 17 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 (talkcontributionsuploads) 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 3200N1000W  (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 (talkcontributionsuploads) 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×pdeHello! 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×pdeHello! 07:46, 31 December 2016 (UTC)

Bridged corner icons[edit]

The icons in this set of bridged corners for overlaying (e.g.   (tÜWu1),   (utÜWu4)) are pretty much the only icons left using the ÜW root.[1] Should …ÜWu… be changed to …STRo…, and ÜWt… (e.g.   (ÜWt2)) to lSTRo…? (I'd use c as well but it seems unnecessary given there aren't any naming conflicts.) Jc86035 (talkcontributionsuploads) 06:02, 18 June 2016 (UTC)

References

  1. Except   (ÜW1dr) and   (ÜW1dl) in the obsolete category, which should really be redirected to   (KRWr+r) and   (KRWl+l).

(Pinging: Useddenim · YLSS · Lost on Belmont · Newfraferz87 · Fukuokakyushu2012 · Sameboat. Jc86035 (talkcontributionsuploads) 15:11, 18 June 2016 (UTC))

BRIDGE root[edit]

The BRIDGE root isn't even on w:WP:RDT/C, so I thought it might be a good idea to rename all the icons using it.

Sure it is: en:Wikipedia:Route diagram template/Catalog of pictograms/formations#Bridges. Useddenim (talk) 16:30, 18 June 2016 (UTC)
@Useddenim: I meant, as in, in the list of roots on the main landing page (i.e. the exact page I linked to). It's also kind of inconsistent because it's both longer than 4 letters and not in German. (Can we keep the discussion at the bottom of the table? Thanks.) Jc86035 (talkcontributionsuploads) 16:57, 18 June 2016 (UTC)
Old name New name like notes
  (BRIDGE) lMKRZo   (KRZo) will need to have geometry changed slightly to match
  (BRIDGE-L) ?   (KRZo-L) and   (KRZo-R) are different to these two
  (BRIDGE-R)
  (BRIDGEq) lMKRZu   (KRZu) will need to have geometry changed slightly to match
  (BRIDGEq-L) ?
  (BRIDGEq-R)
  (BRIDGElr) lMKRXo   (KRXo)
  (BRIDGErl) lMKRXu   (KRXu)
  (BRIDGE2+4o) lMKRZ2+4o   (KRZ2+4o) create corner formations for ends? not sure what to call them though
  (BRIDGEq2+4o) lMKRZq2+4o   (KRZq2+4o)
  (BRIDGE3+1o) lMKRZ3+1o   (KRZ3+1o)
  (BRIDGEq3+1o) lMKRZq3+1o   (KRZq3+1o)
  (BRIDGE2+4u) lMKRZ2+4u   (KRZ2+4u)
  (BRIDGEq2+4u) lMKRZq2+4u   (KRZq2+4u)
  (BRIDGE3+1u) lMKRZ3+1u   (KRZ3+1u)
  (BRIDGEq3+1u) lMKRZq3+1u   (KRZq3+1u)
  (BRIDGEl) ? not sure what to call these. maybe just classify them as tunnel portals or something
  (BRIDGEr)
  (BRIDGEf)
  (BRIDGEg)
  (-BRIDGEl)
  (BRIDGEl-)
  (-BRIDGEr)
  (BRIDGEr-)
  (v-BRIDGEf)
  (vBRIDGEf-)
  (v-BRIDGEg)
  (vBRIDGEg-)
  (lhKRZq+4u) lMKRZq+4u this isn't a BRIDGE icon, but the current previousUseddenim (talk) 23:14, 14 August 2016 (UTC) name KRZq+4u implied an icon with tracks so it's not ideal
  (BRIDGEv) lMKRZvo   (KRZvo) formations need to be fixed
  (-BRIDGE) lM-KRZvo? (or KRZ-
  (BRIDGE-) lMKRZvo-? (or -o)
  (vBRIDGE) lMvKRZo   (vKRZo)
  (v-BRIDGE) lMv-KRZo?
  (vBRIDGE-) lMvKRZo-? (or -o)
  (v-BRIDGEv) lMv-KRZvo?   (vKRZvo) formations need to be fixed
  (vBRIDGEv-) lMvKRZ-'vo? formations need to be fixed; apostrophe is to avoid ambiguity. whoever did the krz set really helped by inverting the order of the suffices
  (BRIDGEvq-) lMvKRZ'-vu?   (vKRZvu)
  (-BRIDGEvq) lMvKRZv-u? formations need to be fixed
  (-BRIDGEv) lMvKRZv-o?
  (vBRIDGEq) lMKRZvu   (KRZvu) formations need to be fixed
  (-BRIDGEq) lM-KRZvu? (or KRZ-)
  (BRIDGEq-) lMKRZvu-? (or -u)
  (BRIDGEvq) lMvKRZu   (vKRZu)
  (v-BRIDGEq) lMv-KRZu?
  (vBRIDGEq-) lMvKRZu-? (or -u)
  (dBRIDGE-L) ?
  (dBRIDGE-R)
  (dBRIDGE) lMdKRZo   (dKRZo)
  (dBRIDGEq) lMdKRZu   (dKRZu)
  (dBRIDGEl) ? not sure what to call these. maybe just classify them as tunnel portals or something
  (dBRIDGEr)
  (dBRIDGEf)
  (dBRIDGEg)
  (d-BRIDGE) lMd-KRZvo? (or KRZ-) formations need to be fixed
  (dBRIDGE-) lMdKRZvo-? (or -o)   (dKRZo-)
  (d-BRIDGEq) lMd-KRZvu? (or KRZ-)
  (dBRIDGEq-) lMdKRZvu-? (or -u)
  (dKRZo-) dKRZvo-? (or -o) just for clarity? not sure if this is necessary

Haven't done anything in /half width/uw/crossing/formations yet; maybe someone else could try that? Jc86035 (talkcontributionsuploads) 15:08, 18 June 2016 (UTC)

The root could be shortened to BRG, because bridge is an English/German cognate. Useddenim (talk) 03:32, 19 June 2016 (UTC)
@Useddenim: I'd say changing some of these (particularly the diagonals) to KRZ would be better, as it reflects their actual usage, but I have no objection to using the BRK/BRG root for the single-ended bridges. (If we change   (BRÜCKE1) to BRK/BRG, then we could probably change these icons to match the formations.) Jc86035 (talkcontributionsuploads) 05:26, 19 June 2016 (UTC)
I'm generally against changing the structural legend icons to KRZ, as it simply represents a bridge and not necessary a crossing; there would be naming restrictions to having a KRZ root pertaining to the perpendicular track, but less so with just a BRK / BRG / BRIDGE root. This is also shown with the naming problems with regards to some of the bridge icons listed above. However, those with ambiguous suffixes, such as   (BRIDGErl), can indeed be renamed to proper ones.   ~ Newfitz Yo! 02:20, 22 June 2016 (UTC)
@Newfraferz87: I'd still prefer an lMKRX/Z or lKRX/Z root for the diagonal ones, because it better reflects their actual usage (especially since KRX doesn't have any tunnel versions for some reason). Maybe we could have lKRZ for the ones with masks (since they wouldn't be much use without masks) and lBRK for the ones without (and lMBRK for the ones which would have name conflicts due to only having half a side, I guess). Jc86035 (talkcontributionsuploads) 09:38, 22 June 2016 (UTC)

Crossing over roads[edit]

With regards to crossing over roads (see enWP gallery), is there an agreed nomenclature for closed road variants? Compare   (exSKRZ-Ao),   (exAKRZo) and   (evSKRZ-Ao). Also, are the icons supposed to belong in this category, this one, or both?   ~ Newfitz Yo! 07:23, 28 June 2016 (UTC)

  1. The standard nomenclature is that the e prefix indicates the secondary feature (the crossed road) is out of use, while the x prefix indicates the primary feature (the railway) is out of use.
  2. Yes, both Category:Icons for motorway descriptions/RA/crossing rail and Category:Icons for railway descriptions/crossing road. (Despite some opinions to the contrary, over-categorization is better than under-.)
  3. With respect to parallel lines, the left and right lines are primary and secondary, so the possibilities become:
Both lines in use Left line out of use Right line out of use Both lines out of use
Road in use BSicon .svgBSicon vSKRZ-Au.svgBSicon RAq.svg (vSKRZ-Au)  BSicon .svgBSicon evSKRZ-Au.svgBSicon RAq.svg (evSKRZ-Au)  BSicon .svgBSicon xvSKRZ-Au.svgBSicon RAq.svg (xvSKRZ-Au)  BSicon .svgBSicon exvSKRZ-Au.svgBSicon RAq.svg (exvSKRZ-Au) 
Road out of use BSicon .svgBSicon vSKRZ-Au.svgBSicon RMq.svg (vSKRZ-Axu)  BSicon .svgBSicon evSKRZ-Au.svgBSicon RMq.svg (vSKRZ-Axu)  BSicon .svgBSicon xvSKRZ-Au.svgBSicon RMq.svg (vSKRZ-Axu)  BSicon .svgBSicon exvSKRZ-Au.svgBSicon RMq.svg (vSKRZ-Axu) 
Useddenim (talk) 00:15, 29 June 2016 (UTC)
Actually, scratch that. I've just found that the off-color roads ( ) uses   (SKRZ-M) instead of   (SKRZ-A). Though the backlog still seems extremely terrible and I have no naming schemes for all of them at the moment.   ~ Newfitz Yo! 07:14, 30 June 2016 (UTC)

BSicon hSTRl.svg and BSicon hSTRr.svg[edit]

It would appear that the icons mentioned in the title, along with their u- counterparts, run counter to what the orange, violet, and brown color sets depict, though oddly enough not what the pink color set depicts. I was tempted to use the former direction scheme (hence the 64 icons I uploaded following this), but if I am in error, would it be possible to harmonize these names? Mahir256 (talk) 23:11, 25 July 2016 (UTC)

@Mahir256: Yes, there seems to be an error in the direction:   (STRl),   (tSTRl), but   (hSTRl). (You also seem to have used a template with the old 60px side formations instead of the 50px ones, which should be fixed at some point.)
(pinging Useddenim, Sameboat, Tuvalkin, Lost on Belmont, Newfraferz87) Taking into account that this has been ignored for about 7 years, should we swap all of the icon names or just ignore the issue? It is certainly unnecessarily confusing. Jc86035 (talkcontributionsuploads) 13:17, 28 July 2016 (UTC)
We may rename to STRfq and STRgq like   (CONTfq) and   (CONTgq) for consistency.. -- Sameboat - 同舟 (talk · contri.) 21:37, 28 July 2016 (UTC)
  • @Sameboat: That actually sounds like a much better idea than reversing the file names. Should we wait a few days first, considering that a lot of documentation in several languages will have to be updated? Jc86035 (talkcontributionsuploads) 08:57, 29 July 2016 (UTC)
  • I like Sameboat’s idea. -- Tuválkin 21:14, 29 July 2016 (UTC)

┌─────────────┘
@Lost on Belmont, Tuvalkin, Sameboat, Mahir256: ✓ Done Requested moves for all   (STRl) and   (STRr) variations (including the half-stations) to STRfq and STRgq. This also, incidentally, allows   (STRlf),   (STRrf) and the like to be moved to STRr and STRl (plus +l and +r). Jc86035 (talkcontributionsuploads) 09:58, 16 August 2016 (UTC)

Width prefixes[edit]

(pinging Sameboat, Useddenim, Tuvalkin, Lost on Belmont, Newfraferz87, Axpde) Currently, there are only three actual width prefixes – c (14), d (12) 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 (134) and leer+dbbb (712) 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
14 c schmal compact
12 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 (talkcontributionsuploads) 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×pdeHello! 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 (talkcontributionsuploads) 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 = 21/4
  • cb = broad - compact = 13/4
...? Ciao a×pdeHello! 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 (talkcontributionsuploads) 05:08, 4 August 2016 (UTC)

┌───────────────────┘
@Useddenim, Sameboat, 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 (talkcontributionsuploads) 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×pdeHello! 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, Axpde: Using + before other prefixes would be fine as well (e.g. +db for 312). Jc86035 (talkcontributionsuploads) 04:53, 19 August 2016 (UTC)
Uploaded   (s) (4),   (bs) (6) and   (w) (8). Jc86035 (talkcontributionsuploads) 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×pdeHello! 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 = 54 from, as d - c would just be 14. Jc86035 (talkcontributionsuploads) 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×pdeHello! 07:51, 28 August 2016 (UTC)

Thanks[edit]

Thanks to all of you still working on this Gordian Knot! I always said it's to much to much to allow every thinkable combination of every root, line, dot or whatever. And some talks could have been shortened by logical rules, as if it's tKRZtu it should be hKRZhu as well ...

But nevertheless I agress with most of your suggestions above (and if not, who cares ;-) and I'd like to thank you all for your work! a×pdeHello! 07:04, 1 August 2016 (UTC)

File:BSicon uhvBS2+l-R.svg[edit]

(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 (talkcontributionsuploads) 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, 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)

Elevated formations[edit]

(pinging Useddenim, Sameboat, Tuvalkin) Do -L and -R mean "formations only on one side" (  (hBHF-L)) or "icon shifted to the side" (  (hSTR-L))? I'm inclined towards the latter, as the former is inconsistent (see   (BHF-L)) and easily replaceable using overlays instead. Jc86035 (talkcontributionsuploads) 16:03, 16 August 2016 (UTC)

┌───┘
@Sameboat, Useddenim: Would it be better for the first case to add the -L/-R suffix to h instead of at the end (since, again, that seems to be syntactically valid)? Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
15:25, 6 December 2016 (UTC)

-lf and -rg suffixes / -L and -R suffixes[edit]

moved from en:User talk:Useddenim

This is just a half-formed thought, but I'm wondering about finally renaming all the [lr][fg]-suffixed BSicons to the (+)[lr] suffices, if I have time. (The suffices still confuse me sometimes because they're quite unintuitive even for BSicons.)

This could be done by first renaming the one-sided stations   (BHFl), (-r) to BHFlr, -rl over the current redirects (etymology: [root][f-direction side][g-direction side]); and the half-station icons   (lBHFl), (-r) to something like KBHFl-R and -r-L. (KBHF[lr] to KBHF[ea]q could also be considered.) After uses of those are replaced (AWB on at least enwiki), I think that removes pretty much all the naming conflicts which could possibly occur, and allows things like   (uhBHFl).

Your thoughts? —Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
14:45, 11 September 2016 (UTC)

There's also   (hBHF-L) and   (hBHF-R). This is rather tangential, but those probably aren't named correctly since they'd be like   (uhBHF-L). Maybe just delete and replace them with overlays? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
14:55, 11 September 2016 (UTC)

? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
08:42, 13 September 2016 (UTC)

Ah yes, among my earliest icon contributions...
Since   (lBHF)  (lBHFf), then   (lBHFl) should actually be   (lBHFfq).
WRT to the -L and -R suffixes, for stations it means "connects to the left/right", whereas for formations it means "on the left/right (only)". You may want to double-check with Axpde and/or Tuvalkin, though. Useddenim (talk) 17:03, 13 September 2016 (UTC)
@Useddenim: The problem with having that rule for non-legende formations is that we don't really have a nice alternative to using   (uhBHF-L)/R, and it's already inconsistent with   (hSTR-R). I might post a proposal on the Commons talk page for the one-sided stations. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
03:47, 14 September 2016 (UTC)
Good idea. Useddenim (talk) 11:05, 14 September 2016 (UTC)

┌─────────┘
@Useddenim: Well, since this section is now here, let's make a table.

Semicircular stations
Current Proposed Notes
  (BHFl)   (BHFlr) Move over redirect
  (BHFr)   (BHFrl) Move over redirect
  (epBHFl)   (epBHFlr)
  (epBHFr)   (epBHFrl)
  (expBHFl)   (expBHFlr)
  (expBHFr)   (expBHFrl)
  (pBHFl)   (pBHFlr)
  (pBHFr)   (pBHFrl)
  (xpBHFl)   (xpBHFlr)
  (xpBHFr)   (xpBHFrl)
  (pBHFrq)   (pBHFrlq)
  (HSTd)   (HSTlr)
  (HSTu)   (HSTrl)
  (HHSTl)   (HSTlrq)
  (HHSTr)   (HSTrlq)
  (uxpBHFl)   (upBHFlr)
  (uxpBHFr)   (upBHFrl)
  (upBHFrq)   (upBHFrlq)
  (uxpBHFf)   (-uepBHF) This is just named incorrectly
  (uHSTd)   (uHSTlr)
  (uHSTu)   (uHSTrl)
  (uHHSTl)   (uHSTlrq)
  (uHHSTr)   (uHSTrlq)
  (uexHSTd)   (uexHSTlr)
  (uexHSTu)   (uexHSTrl)
  (uexHHSTl)   (uexHSTlrq)
  (uexHHSTr)   (uexHSTrlq)

Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
11:42, 14 September 2016 (UTC)

TL;DR: This removes one of the name conflicts preventing the complete deprecation of the lf, lg, rf and rg suffixes. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
13:23, 14 September 2016 (UTC)

"Festina lente!" - one step after the other, we won't find the Egg of Columbus this way! a×pdeHello! 20:33, 14 September 2016 (UTC)

┌───┘
@Axpde, Useddenim: I'm not entirely sure what that means, but in any case, here's another few tables.

Half-stations (legende)
Current Proposed
  (lBHFl) lBHFfq
  (lBHFr) lBHFgq
  (exlBHFl) exlBHFfq
  (exlBHFr) exlBHFgq
  (ulBHFl) ulBHFfq
  (ulBHFr) ulBHFgq
  (uexlBHFl) uexlBHFfq
  (uexlBHFr) uexlBHFgq
  (lHSTl) lHSTfq
  (lHSTr) lHSTgq
  (exlHSTl) exlHSTfq
  (exlHSTr) exlHSTgq
  (ulHSTl) ulHSTfq
  (ulHSTr) ulHSTgq
  (uexlHSTl) uexlHSTfq
  (uexlHSTr) uexlHSTgq
Half-stations (legende)
Current Proposed
  (lDSTl) lDSTfq
  (lDSTr) lDSTgq
  (exlDSTl) exlDSTfq
  (exlDSTr) exlDSTgq
  (ulDSTl) ulDSTfq
  (ulDSTr) ulDSTgq
  (uexlDSTl) uexlDSTfq
  (uexlDSTr) uexlDSTgq
  (lBSTl) lBSTfq
  (lBSTr) lBSTgq
  (exlBSTl) exlBSTfq
  (exlBSTr) exlBSTgq
  (ulBSTl) ulBSTfq
  (ulBSTr) ulBSTgq
  (uexlBSTl) uexlBSTfq
  (uexlBSTr) uexlBSTgq
Half-stations (legende)
Current Proposed
  (lINTl) lINTfq
  (lINTr) lINTgq
  (exlINTl) exlINTfq
  (exlINTr) exlINTgq
  (lACC-L) lACCfq
  (lACC-R) lACCgq
  (ldBHFr) ldBHFgq
  (exldBHFl) exldBHFfq
  (ldHSTl) ldHSTfq
  (ldHSTr) ldHSTgq
  (exldHSTl) exldHSTfq
  (uldHSTl) uldHSTfq
  (uexldHSTl) uexldHSTfq
  (ldBSTl) ldBSTfq
  (exldBSTl) exldBSTfq
  (uldBSTl) uldBSTfq
  (uexldBSTl) uexldBSTfq
  • "q" should be only used for tracks running across, all other "ideas" are neither intuitively nor consistently! a×pdeHello! 13:57, 18 September 2016 (UTC)
    • I always assumed q meant "rotate 90° anticlockwise around the centre", assuming you're referring to the legende stations. Are there any inconsistencies with this? Jc86035 (talk) Use {{ping|Jc86035}}
      to reply to me
      14:05, 18 September 2016 (UTC)
      • I introduced the "q" prefix 2006 for tracks running across (German: "quer") and that's exactly what I always pleed to respect. The big problem with "rotate quarter" is what what direction? There is simply no consistent way to make sure every icon creator will obey the same direction! The "mathematical order" is anti-clockwise, but every non-mathematician will tend to see on his (analogue) watch ... bad idea! a×pdeHello! 14:46, 18 September 2016 (UTC)
        • There haven't ever been more than 10 people actively uploading icons at any point in this decade, so probably not a lot of issues with newbies (who are probably going to make other naming mistakes anyway). Jc86035 (talk) Use {{ping|Jc86035}}
          to reply to me
          14:58, 18 September 2016 (UTC)
          • IMHO opinion everyone in this project may upload BSicons named whatever he thinks is useful, but it's up to the community to find consistent rules ... a×pdeHello! 16:34, 18 September 2016 (UTC)
Switchback stations
These could probably use better naming (like ABZl+l+BHFfq), but this might not work for the wide icons.
Current Proposed (Axpde) Proposed (Jc86035)
  (KBFl) ABHFl+l ABZBHFl+l
  (KBFr) ABHFr+r ABZBHFr+r
  (eKBFl) eABHFl+l eABZBHFl+l
  (xKBFl) ABHFxl+l ABZBHFxl+l
  (xKBFlg) ABHFl+xl ABZBHFl+xl
  (exKBFl) exABHFl+l exABZBHFl+l
  (exKBFr) exABHFr+r exABZBHFr+r
  (tKBFl) tABHFl+l tABZBHFl+l
  (tKBFr) tABHFr+r tABZBHFr+r
  (umtKBFr) umtABHFr+r umtABZBHFr+r
  (tKBFlfxq) xtABHFq+l tABZBHFxq+l
  (tKBFlgxq) xtABHFql tABZBHFlxq
  (utKBFlfxq) uxtABHFq+l utABZBHFxq+l
  (bKBHFl) bKBHFl+l bABZKBHFl+l
  (bKBHFr) bKBHFr+r bABZKBHFr+r
  (exbKBHFl) exbKBHFl+l exbABZKBHFl+l
  (exbKBHFr) exbKBHFr+r exbABZKBHFr+r
  (bKS+BHFl) bS+KBHFl+l bS+ABZKBHFl+l
  (bKS+BHFr) bS+KBHFr+r bS+ABZKBHFr+r
  • KBF is an old leftover, should be KBHF for consistency reasons!
    • @Axpde: KBF → KBHF would create a conflict with   (KBFrg) etc., which would – assuming we proceed with the second stage – be renamed to   (KBHFr). So would all the   (KBHFl),   (KBHFr) icons – as mentioned above – have to be renamed to KBHFfq, KBHFgq? Jc86035 (talk) Use {{ping|Jc86035}}
      to reply to me
      14:05, 18 September 2016 (UTC)
    • @Axpde: Also, re. the question marks on tKBHFxq+l etc: I took the naming pattern from the ABZ series (e.g.   (ABZq+l)), but added the x before q because the prefixes could refer to the station circle / the whole junction. Jc86035 (talk) Use {{ping|Jc86035}}
      to reply to me
      14:10, 18 September 2016 (UTC)
    • (Pinging Useddenim, Tuvalkin, Lost on Belmont. Jc86035 (talk) Use {{ping|Jc86035}}
      to reply to me
      14:15, 18 September 2016 (UTC))
      • I agree with you, the regular sized icons shouldn't be called KBHF, even worse they are not imperatively terminal stations (German: "Kopfbahhof"), see BSicon ABHFl+l.svgBSicon ABHFr+r.svg, that why they should be called ABHF for Abzweigbahnhof (Austrian for "Trennungsbahnhof" or "junction station"! a×pdeHello! 14:46, 18 September 2016 (UTC)
        • @Axpde: A might cause some naming problems with the road series, and I'm not sure it's a good idea to introduce a new prefix for something this specific. Jc86035 (talk) Use {{ping|Jc86035}}
          to reply to me
          14:58, 18 September 2016 (UTC)
          • I don't know who introduced AKRZ for an autoroute crossing, should have been an ABRÜCKE or whatever you prefer, but that shouldn't be a reason to back off from using a very consistent meaning: ABHF (for "Abzweigbahnhof") is simply the combination of ABZ (for "Abzweig") and BHF (for Bahnhof), which will even understand those users who know ABZ and BHF and their use without knowing the German descent! a×pdeHello! 16:34, 18 September 2016 (UTC)
            • I guess there's also BHFABZ (like   (BHFABZgl+l)). From that, we could make KBHFABZ, or simply swap them around to make ABZBHF (like   (eABZHSTrd), which should really be eABZHSTgr+r). Both of them avoid making a new prefix (also: unused   (ATUNNELlu), which I should have renamed with   (htSTRaq), but didn't). Jc86035 (talk) Use {{ping|Jc86035}}
              to reply to me
              12:12, 20 September 2016 (UTC)
              • I don't like those "double roots", "ABHF" is intuitively understandable as an abbreviation of "ABZ(+)BHF", same with "AHST" (which is impossible by german railways law) short for "ABZ(+)HST"! And btw. I really don't see the reason for the "A" in that tunnel icon ... a×pdeHello! 18:07, 20 September 2016 (UTC)
                • @Axpde: Well, I guess we could have two separate prefixes for "little stations around junction" and "station on junction", but there's also   (BHFWYEf+14) (and two others), which would make things more complicated. Probably best to have compound prefixes (they're already used in things like   (HSTACC) anyway, so probably aren't going anywhere). Jc86035 (talk) Use {{ping|Jc86035}}
                  to reply to me
                  12:29, 21 September 2016 (UTC)
                  • Arghh, I never understood why we need those specialized icons while having the possibility to overlay ... at least outside dewiki :-( BSicon .svgBSicon HST.svgBSicon lHSTACC.svg  is the same as BSicon .svgBSicon HSTACC.svg  ... btw lHSTACC should be shortened ... maybe lACCs ("small"?). a×pdeHello! 20:59, 24 September 2016 (UTC)
                    • @Axpde: That sounds a lot more ambiguous than just "HSTACC". No point creating a prefix just meaning "HST" – it's just two fewer letters. Jc86035 (talk) Use {{ping|Jc86035}}
                      to reply to me
                      03:46, 25 September 2016 (UTC)
  • ┌─────────────────────────────────┘
    @Axpde, Useddenim, Tuvalkin: Found a different solution:   (KBFl)  (BHFsl+l), per   (STRsl); KBHF for wide icons. (Also, rename   (STRsl) and   (STRsr) to ENDEsl+l and …r+r respectively.) Jc86035 (talk) Use {{ping|Jc86035}}
    to reply to me
    07:11, 25 September 2016 (UTC)
I do like this solution. It’s a good sign that something like   (STRsl) gets a new name including "ENDE". -- Tuválkin 16:37, 6 December 2016 (UTC)
@Tuvalkin: I think that for the switchback icons, which weren't renamed along with the stations, it might be better to use the A (pseudo-?)prefix instead of the s suffix for consistency. This would make them AENDEl+l and …r+r, and the s suffix—not used for anything else—could then potentially be freed up for other things, for example to denote a 25.6° slant. —Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
09:49, 7 December 2016 (UTC)
I like   (AENDE). Useddenim (talk) 15:20, 7 December 2016 (UTC)
@Useddenim: given the lack of opposition towards this particular proposal, could we rename the icons? Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
13:27, 8 December 2016 (UTC)
@Axpde: your thoughts (  (STRsl)AENDEl+l)? Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
13:28, 8 December 2016 (UTC)
Sounds reasonable to me. But this talk thread grows a) gigantic b) unreadable c) confused ... ;-) a×pdeHello! 20:15, 8 December 2016 (UTC)
d) All of the above. 8) Useddenim (talk) 01:57, 9 December 2016 (UTC)
@Useddenim, Axpde: (I've renamed the files.) This is a very confusing thread, yes. Maybe create a new section to finish off the loose ends (if any)? Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
11:01, 9 December 2016 (UTC)

Some years ago, Axpde adamantly insisted (with reference to BSicon .svgBSicon STRrg.svgBSicon CONTgg.svg (CONT+ABZ) , IIRC) that there should not be multiple features on an icon, yet WP:DE seems to strongly resist any attempt to eliminate the   (KBF) icons… Useddenim (talk) 14:37, 18 September 2016 (UTC)
@Useddenim: I'd support deleting the wide icons (because they're easily replaceable) and anything that's not in use, and renaming the rest to stuff like STRl+BHFfq. Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
14:51, 18 September 2016 (UTC)
The broad icons with the terminal stations are in used in dewiki, they are simple and useful, no need to delete them. a×pdeHello! 16:37, 18 September 2016 (UTC)
@Axpde: None of them are used on more than 10 articles each; renaming them from KBF to KBHF or something else would be rather fiddly since ABZs usually stretch to the edges of an icon and KBHFs are normally in the centre of icons. Syntactically, much easier to replace and delete them. Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
12:12, 20 September 2016 (UTC)
But we don't need any crooks, we have the icons we need, we want to keep them, period. Don't fix what's not broken! a×pdeHello! 18:07, 20 September 2016 (UTC)
@Axpde: Then maybe replace the root with ABZKBHF / ABZKSBHF? Alternatively AKBHF? Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
12:29, 21 September 2016 (UTC)
Why insisting in the "K" prefix? As said before those icons don't need to be terminal stations, so the "K" is missleading! The root "ABHF" is sufficient. a×pdeHello! 20:45, 24 September 2016 (UTC)
@Axpde: Well, because you put the suffix in the table above for bKBHFr and the other wide icons. I'm using both K and A(BZ) because bA(BZ)BHF would mean that the line goes to the left or right edge of the icon (like the normal-sized icons) and just using bKBHFr would conflict with the meaning of   (KBHFr). Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
03:46, 25 September 2016 (UTC)
To expand on my thought above, all of these icons could easily be replaced with overlays, but to quote Metrophil at Talk:BSicon/New icons and icon requests#uxmABZrg tunnel version, “We do not use overlay on German Wikipedia.” Perhaps the better (long-term) solution would be to either add overlay functionality to WP:DE’s {{BSu-table}} or—dare I say it—port {{Routemap}} over. Useddenim (talk) 01:06, 19 September 2016 (UTC)
To make it clear: I alread coded an overlay possibility that was 100% consistent with the old usage. But some stubborn users of dewiki adamantly oppose even the possibility to overlay BSicons. Can't tell you why, the only reason I know of was that M$ Internet Exploiter 6 (!) is not capable of showing those! a×pdeHello! 18:07, 20 September 2016 (UTC)
@Axpde: Wo wurde sowas diskutiert? Könnte man das Thema nicht nochmal aufbringen? Ich fände es echt besser und um einiges einfacher, wenn wir Overlay auch benutzen könnten. (Where was this discussed? Wouldn’t it be possible to raise that topic again? I think it would really be better and easier if we could use overlay on de.wp too) -- Metrophil (talk) 15:55, 21 September 2016 (UTC)
In dewiki? An vielen Stellen, das letzte Mal unter de:Portal Diskussion:Bahn/Archiv/2014/III#Überlagerung von BSicons – leider ohne Erfolg ... (It's been discussed in dewiki several times, last one can be found at de:Portal Diskussion:Bahn/Archiv/2014/III#Überlagerung von BSicons) a×pdeHello! 20:42, 24 September 2016 (UTC)

┌─────────┘
@Axpde, Useddenim: A few others:

Current Jc86035's proposal axpde's proposal
  (pHSTl) pHSTlr pHSTg
  (pHSTr) pHSTrl pHSTf
  (xpHSTl) xpHSTlr (makes no sense)
  (xpHSTr) xpHSTrl (makes no sense)
  (uxpHSTl) upHSTlr upHSTg
  (uxpHSTr) upHSTrl upHSTf

Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
08:49, 24 September 2016 (UTC)

To be honest those icons aren't in our "Bilderkatalog" and are only very seldom used in dewiki. IMHO it's a bad idea to use the "l"- and "r"-suffix in a meaning other than "track running to left/right". In this case it's the question of driving direction (forward or against, seen in right hand side driving order). a×pdeHello! 20:42, 24 September 2016 (UTC)
We already have   (BHFf) (which is the entire reason we can rename the   (lBHFr) group), so pHSTf would just mean a normal pHST is moved forwards half an icon space. As you said below… Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
03:46, 25 September 2016 (UTC)

@Tuvalkin, Useddenim: I'm considering renaming the KBHF[lr] icons anyway even if there don't turn out to be any naming conflicts, as they'd otherwise be the last usage of the l and r suffixes for anything not containing curves. Some icons, like   (KBHFeq brown), have already been renamed (mostly by YLSS) or, like   (KBHFeq orange), were created with that naming. Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
11:57, 24 September 2016 (UTC)

Once again: Don't fix what's not broken! a×pdeHello! 20:59, 24 September 2016 (UTC)
@Axpde: Or we could, instead, rename the coloured icons. Whichever way works, but keeping l/r means that   (bKBHFr) (both currently and if we renamed it under your proposal) would mean (and currently means) a completely different thing from   (KBHFr). Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
03:46, 25 September 2016 (UTC)

Oh, and we also seem to have forgotten the   (CPICrf) group, which would become   (CPICr). Could we just rename all the CPIC icons without a station or line in them to lCPIC etc.? Would make things much easier. Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
03:50, 25 September 2016 (UTC)

Other things[edit]

Current Proposed
  (lvINTlq)
  (lvINTrq)
  (ldvINTlq)
Non-standard naming; delete and replace (2 uses) with overlaid   (lvINTq)
  (bvKBHFr-STR) bvKBHFr+r-STR? This appears to be used only in the BSicon navbox as a decoration, not sure how useful this could possibly be – at least for dewiki withouth overlay possibility :-(
  (ABZl+l+HSTl) AHSTl+l ✓OK
  (ABZr+r+HSTr) AHSTr+r ✓OK

(Pinging Sameboat, because pagemover rights.) Should the KBHFl/r icons be renamed? I might have missed a few icons or used the wrong naming patterns, so please correct me below. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
10:53, 15 September 2016 (UTC)

  • Concerning   (bvKBHFr-STR) above, it was not created «as a decoration» (!). It was originally created for a (never completed) diagram of the Darjeeling Himalayan Railway (see here), which was later developed and end up not needing it. The suggested name is better than the one I used — although I’m not (yet) fully convinced about this way of naming switchback stations. -- Tuválkin 21:12, 21 September 2016 (UTC)
    • @Tuvalkin: We could also use compound roots ABZKBHF or AKBHF instead (based on ABZHST and Axpde's proposed ABHF respectively), since using KBHF would also require that all variations of KBHFl/r be renamed to KBHFfq/gq to avoid more naming conflicts. Jc86035 (talk) Use {{ping|Jc86035}}
      to reply to me
      02:23, 22 September 2016 (UTC)
      • Nope! There is no need to rename any KBHF icon because none of them have a track running across ("q")! I know you like your idea to convert the meaning of the q-suffix, but I don't do that! And behalf of dewiki we don't want to rename those icons! a×pdeHello! 20:25, 24 September 2016 (UTC)
        • If that actually is a rule (Useddenim: is it?), I have never known about it (only found it here, but relating to 45° curves). I've probably uploaded several dozen violations. e.g.   (uextSTR-Rq). Jc86035 (talk) Use {{ping|Jc86035}}
          to reply to me
          03:46, 25 September 2016 (UTC)
        • @Axpde: It's almost definitely not a rule anymore, given that   (CONTfq),   (ENDEeq) etc. were renamed almost three years ago (again by YLSS) to fix the misapplication of the l and r suffixes. Jc86035 (talk) Use {{ping|Jc86035}}
          to reply to me
          04:21, 25 September 2016 (UTC)

Proposed changes[edit]

@Useddenim, Tuvalkin, Axpde, Lost on Belmont, Sameboat: Are there any problems with the below set of changes? (I'm switching to Axpde's ABHF because it'd be weird/inconsistent to use "ABZBHF" for icons without any actual junction. The CPIC renames can wait for now, since there aren't actually any conflicts.)

Semicircular stations
Current Proposed Notes
  (BHFl) BHFlr Move over redirect
  (BHFr) BHFrl Move over redirect
  (epBHFl) epBHFlr
  (epBHFr) epBHFrl
  (expBHFl) expBHFlr
  (expBHFr) expBHFrl
  (pBHFl) pBHFlr
  (pBHFr) pBHFrl
  (xpBHFl) xpBHFlr
  (xpBHFr) xpBHFrl
  (pBHFrq) pBHFrlq
  (HSTu) HSTlr
  (HSTd) HSTrl
  (HHSTl) HSTlrq
  (HHSTr) HSTrlq
  (uxpBHFl) upBHFlr
  (uxpBHFr) upBHFrl
  (upBHFrq) upBHFrlq
  (uxpBHFf) -uepBHF Named incorrectly
  (uHSTu) uHSTlr
  (uHSTd) uHSTrl
  (uHHSTl) uHSTlrq
  (uHHSTr) uHSTrlq
  (uexHSTu) uexHSTlr
  (uexHSTd) uexHSTrl
  (uexHHSTl) uexHSTlrq
  (uexHHSTr) uexHSTrlq
  (pHSTl) pHSTlr
  (pHSTr) pHSTrl
  (xpHSTl) xpHSTlr
  (xpHSTr) xpHSTrl
  (uxpHSTl) upHSTlr
  (uxpHSTr) upHSTrl
Half-stations (legende)
Current Proposed
  (lBHFl) lBHFfq
  (lBHFr) lBHFgq
  (exlBHFl) exlBHFfq
  (exlBHFr) exlBHFgq
  (ulBHFl) ulBHFfq
  (ulBHFr) ulBHFgq
  (uexlBHFl) uexlBHFfq
  (uexlBHFr) uexlBHFgq
  (lHSTl) lHSTfq
  (lHSTr) lHSTgq
  (exlHSTl) exlHSTfq
  (exlHSTr) exlHSTgq
  (ulHSTl) ulHSTfq
  (ulHSTr) ulHSTgq
  (uexlHSTl) uexlHSTfq
  (uexlHSTr) uexlHSTgq
  (lDSTl) lDSTfq
  (lDSTr) lDSTgq
  (exlDSTl) exlDSTfq
  (exlDSTr) exlDSTgq
  (ulDSTl) ulDSTfq
  (ulDSTr) ulDSTgq
  (uexlDSTl) uexlDSTfq
  (uexlDSTr) uexlDSTgq
Half-stations (legende)
Current Proposed
  (lBSTl) lBSTfq
  (lBSTr) lBSTgq
  (exlBSTl) exlBSTfq
  (exlBSTr) exlBSTgq
  (ulBSTl) ulBSTfq
  (ulBSTr) ulBSTgq
  (uexlBSTl) uexlBSTfq
  (uexlBSTr) uexlBSTgq
  (lINTl) lINTfq
  (lINTr) lINTgq
  (exlINTl) exlINTfq
  (exlINTr) exlINTgq
  (lACC-L) lACCfq
  (lACC-R) lACCgq
  (ldBHFr) ldBHFgq
  (exldBHFl) exldBHFfq
  (ldHSTl) ldHSTfq
  (ldHSTr) ldHSTgq
  (exldHSTl) exldHSTfq
  (uldHSTl) uldHSTfq
  (uexldHSTl) uexldHSTfq
  (ldBSTl) ldBSTfq
  (exldBSTl) exldBSTfq
  (uldBSTl) uldBSTfq
  (uexldBSTl) uexldBSTfq
Switchback stations
Current Proposed
  (KBFl) ABHFl+l
  (KBFr) ABHFr+r
  (eKBFl) eABHFl+l
  (xKBFl) ABHFxl+l
  (xKBFlg) ABHFl+xl
  (exKBFl) exABHFl+l
  (exKBFr) exABHFr+r
  (tKBFl) tABHFl+l
  (tKBFr) tABHFr+r
  (umtKBFr) umtABHFr+r
  (tKBFlfxq) tABHFxq+l
  (tKBFlgxq) tABHFlxq
  (utKBFlfxq) utABHFxq+l
  (bKBHFl) bAKBHFl+l
  (bKBHFr) bAKBHFr+r
  (exbKBHFl) exbAKBHFl+l
  (exbKBHFr) exbAKBHFr+r
  (bKS+BHFl) bS+AKBHFl+l
  (bKS+BHFr) bS+AKBHFr+r
  (bvKBHFr-STR) bvAKBHFr+r-STR
  (ABZl+l+HSTl) AHSTl+l
  (ABZr+r+HSTr) AHSTr+r
Other
Current Proposed
  (STRsl) AENDEl+l
  (STRsr) AENDEr+r
  (exSTRsl) exAENDEl+l
  (exSTRsr) exAENDEr+r
  (lvINTlq) lINTfq-INTfq
  (lvINTrq) lINTgq-INTgq
  (ldvINTlq) ldINTfq-INTfq

Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
15:14, 28 September 2016 (UTC)

I guess if no one can be bothered to reply or anything I'll just request all the renames in about three weeks or so. Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
11:19, 2 October 2016 (UTC)

@Useddenim, Sameboat, Tuvalkin, Axpde: All the icons (sans the "Other" table) have been renamed, so I guess that clears the way for finally replacing the lf, lg, rf and rg suffixes. (By the time that's been finalised, hopefully en:WP:BOTREQ#BSicons will have been completed.) Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
05:25, 26 October 2016 (UTC)

Tangential[edit]

There are icons in this category which seem to be named very strangely. Might be best to replace them with standard-width icons (which don't seem to exist yet).
Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
10:53, 15 September 2016 (UTC)

I created these half icons to allow any variation of   (vBHFq) to be displayed without having to create each and every individual icon. Yes, the naming isn't perfect, but it was the best we came up with at the time. Useddenim (talk) 11:20, 15 September 2016 (UTC)
@Useddenim: From a quick scan, they don't seem to be used very widely anyway (only found one), so we could just create icons for the few diagrams where they're used (plus a few other basic ones). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
13:18, 15 September 2016 (UTC)
  • Symbol oppose vote.svg Oppose: Guys, there’s two things that may happen:
  1. When we find a misnamed icon, we rename it to a better name that follows our naming rules. (Yes, some times is very hard to come up with a good name, some times this process may even call for changes in the naming rules.)
  2. And when we find an icon that doesn’t make sense within the whole BSicon universe, based on the nature of its topology and/or semantics, we delete it, replacing its usage, if any, with conventional icons.
What we should never do is to try to solve complex naming issues with deletion of the icon in question. I’ve seen this proposed a couple times in this section and before, and this trend gotta stop. We come a long way of improving and developing of a system that was originally much small-scoped and which had some flaws; it’s not time for U-turns. BSicon .svgBSicon STR3+1.svgBSicon uexWSLa.svg  -- Tuválkin 14:59, 20 September 2016 (UTC)
@Tuvalkin: Keeping + renaming would likely end up being something like dlBHFfq-BHFfq for   (d-BHF-L), not opposed but practically none of the icons are used anyway. It's also much easier to overlay   (lvBHFq) and variants over plain tracks. Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
12:13, 21 September 2016 (UTC)
Yep, make use of overlay. I'd wish I had this in dewiki, too! a×pdeHello! 20:59, 24 September 2016 (UTC)
@Axpde: If only we could add overlay or {{Routemap}} to dewiki. Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
03:03, 25 September 2016 (UTC)

Arrows[edit]

Should the DNUL group of icons be renamed to remove the D prefix (since D usually means "embankment")? Example:   (lvDNULfgq)lvNUL2+4fg. Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
13:29, 24 September 2016 (UTC)

Seems like these should be renamed using parallel lines and diagonal structures. Lost on  Belmont 3200N1000W  (talk) 01:17, 26 September 2016 (UTC)
I never liked the D(iagonal) prefix, but Tuvalkin was insistent… Useddenim (talk) 21:30, 26 September 2016 (UTC)
I don’t mind its renaming if the new names fit well the whole system. When I created these, the preffix "D" had been proposed recently and introduced to name icons that were later renamed with corner indications ("3+1" etc.) and at least one special case —   (KRX) (which I find a great idea and a good example of allowable exceptional naming: nobody wants to use STR3+1+STR2+4 for such a simple concept). If the arrow overlays are the last remnant of that old abortive use of "D", let’s rename them. I would oppose though, as said above, suggestions of deletion of part of this system just because good names cannot be found for them. -- Tuválkin 23:01, 26 September 2016 (UTC)

Border icons[edit]

I’ve just finished rationalizing the BL (Black Line) icons (see en:Template:Walkway icons), so maybe it's time to tackle the GRZ (from the German Grenze—border) ones?

Current Proposed
  (GRZ)   (exlGRZ) GRZ
  (vGRZ-) vGRZ-
  (v-GRZ) v-GRZ
  (GRENZE2f)   (exlGRZf) GRZa
  (GRENZE2g)   (exlGRZg) GRZe
  (GRZq)   (exlGRZq) GRZq
  (GRZq-) GRZq-
  (-GRZq) -GRZq
  (GRENZE2l)   (exlGRZl) GRZaq
  (GRENZE2r)   (exlGRZr) GRZeq
  (GRENZE2+q)   (exlGRZ+q) GRZk
  (GRENZE2+l)   (exlGRZ+l) GRZtl
  (GRENZE2q+f)   (exlGRZq+f) GRZtf
  (GRENZE2+r)   (exlGRZ+r) GRZtl
  (GRENZE2q+g)   (exlGRZq+g) GRZtg
  (GRENZE2le)   (exlGRZle) GRZl
  (GRENZE2la)   (exlGRZla) GRZ+l
  (GRENZE2ra)   (exlGRZra) GRZ+r
  (GRENZE2re)   (exlGRZre) GRZr
  (GRENZElf)   (exlGRZlf) GRZlf
  (GRENZErg)   (exlGRZrg) GRZrg
  (GRENZElg)   (exlGRZlg) GRZlg
  (GRENZErf)   (exlGRZrf) GRZrf
  (GRENZE2rg+rf)   (exlGRZ3+1) GRZ3+1
  (GRENZE2lg+lf)   (exlGRZ2+4) GRZ2+4
  (GRENZE2x)   (exlGRZx) GRZx
  (GRENZE2rg)   (exlGRZ+1) GRZ1
  (GRENZE2lf)   (exlGRZ+2) GRZ2
  (GRENZE2rf)   (exlGRZ+3) GRZ3
  (GRENZE2lg)   (exlGRZ+4) GRZ4
  (GRENZE2lf+rg)   (exlGRZlf+rg) GRZl+l
  (GRENZE2lg+rg)   (exlGRZ+23) GRZlr
  (GRENZE2lg+rf)   (exlGRZlg+rf) GRZr+r
  (GRENZE2lg+rf)   (exlGRZ+14) GRZ+lr
  (GRENZEl)   (exlGRZ12) GRZ2+1
  (GRENZEf)   (exlGRZ23) GRZ23
  (GRENZEr)   (exlGRZ34) GRZ3+4
  (GRENZEg)   (exlGRZ14) GRZ14

Useddenim (talk) 03:39, 11 October 2016 (UTC)

  • @Useddenim: Looks good, although it might be better if GRZ+l etc. were used for the curve instead of the 90° corners (since the whole point of this section is to enable renaming of the [lr][fg] suffixes). Jc86035 (talk) Use {{ping|Jc86035}}
    to reply to me
    04:15, 11 October 2016 (UTC)
  • Also, should the icons with masking between dashes be prefixed M? Jc86035 (talk) Use {{ping|Jc86035}}
    to reply to me
    13:37, 11 October 2016 (UTC)
Seems like a good idea. -- Tuválkin 22:51, 11 October 2016 (UTC)
  • I don't disagree with the proposed renaming and, given the very checkered past of this collection's naming, it is a relief to see it finally named in a minimally sensible way. Having been the creator of most these names, though, I want to remind/clarify this point: Unlike the approach followed above (whose spirit is followed up by Jc86035's 04:15 post), which is admitedly the simplest, these were originally seen not as a path/track in themselves, albeit linear, but as an additional feature that may intersect and/or follow a track. That explains most of the apparently capricious names and also some of the design choices. -- Tuválkin 22:51, 11 October 2016 (UTC)
  • @Useddenim: Additionally, t would probably be better capitalized (like   (TBHF)) to avoid ambiguity with the existing suffix. Jc86035 (talk) Use {{ping|Jc86035}}
    to reply to me
    10:30, 22 October 2016 (UTC)

CPIC[edit]

And while we’re at it, maybe we should look at the CPIC icons, too? Sortening the root from CPIC to CP will allow for such compound constructions as (Cross Platform Banhof quer ende), BSicon .svgBSicon CPICqq.svgBSicon CPIC.svg (CPXu) , etc.

Present Proposed
  (CPICqq)   (CP)
  (dCPICqq)   (dCP)
  (CPICuu)   (CPa)
  (CPICdd)   (CPe)
  (CPICll)   (CPr)
  (dCPICll)   (dCPr)
  (CPICrr)   (CPl)
  (dCPICrr)   (dCPl)
  (CPIC)   (CPq)
  (dCPIC)   (dCPq)
  (CPIClf)   (CPlf)
  (CPIClg)   (CPlg)
  (CPICrf)   (CPrf)
  (CPICrg)   (CPrg)
  (CPICal)   (CPal)
  (CPICar)   (CPar)
  (CPICel)   (CPel)
  (CPICer)   (CPer)
  (CPTa)
  (CPTe)
  (CPTl)
  (CPTr)
  (CPICpasso)   (CPo)
  (CPICpassu)   (CPu)
  (exCPICpasso)   (exCPo)
  (exCPICpassu)   (exCPu)
  (extCPICpasso)   (extCPo)
  (extCPICpassu)   (extCPu)
  (tCPICpasso)   (tCPo)
  (tCPICpassu)   (tCPu)
  (vCPICpassu)   (vCPu)
 
Present Proposed
  (CPICr)   (CPBr)
  (CPICm)   (CPBlr)
  (eCPICm)   (eCPBlr)
  (exCPICm)   (exCPBlr)
  (CPICla)   (CPKal)
  (ehaCPICl)   (ehaCPBl)
  (CPICma)   (CPKalr)
  (xCPICma)   (CPKxalr)
  (CPICra)   (CPKar)
  (CPICKa)   (CPKae)
  (CPICle)   (CPKel)
  (CPICme)   (CPKelr)
  (xCPICme)   (CPKxelr)
  (CPICre)   (CPKer)
  (heCPICr)   (heCPBr)
  (hCPICrxe)   (hCPKxer)
  (CPICKe)   (CPKea)
  (CPICl)   (CPBl)
  (CPICa)   (CPBqa)
  (CPICe)   (CPBqe)
  (tCPICm)   (tCPBlr) etc.
  (uCPICm)   (uCPBlr) etc.
  (CPICAm)   (CPAlr) etc.
  (INTCPICm)   (CPIlr) etc.

Obviously, not all possible combinations are shown.

Useddenim (talk) 21:52, 13 October 2016 (UTC)

Well, I like it. -- Tuválkin 22:06, 13 October 2016 (UTC)
@Useddenim: It looks good, although I'm not sure using e as a prefix to denote "end of bridge" is a very good idea. As with the previous section, I'd rather use (e.g.) CP+r than CPlg. Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
03:40, 14 October 2016 (UTC)
With   (ehaCPBl) and   (heCPBr) the a and e are a suffix to the h prefix. Useddenim (talk) 03:48, 14 October 2016 (UTC)
also: Maybe use CPKB instead of CPK for consistency? Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
10:32, 22 October 2016 (UTC)
The rest is good, my opinion is the lf/lg/rf/rg suffices which should be replaced by the newly proposed changes. -- Sameboat - 同舟 (talk · contri.) 13:28, 22 October 2016 (UTC)

@Useddenim: I've renamed two of these partially (temporarily?) according to the proposal to avoid a conflict (  (hCPICre)  (heCPICr)). Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
15:11, 4 December 2016 (UTC)

Parallel stations (legende)[edit]

Current Proposed
  (lvBHFf) lBHFc23
  (lvBHFg) lBHFc14
  (exlvBHFf) exlBHFc23
  (exlvBHFg) exlBHFc14

@Useddenim, YLSS, Tuvalkin, Axpde: Is this okay? Just a minor change for consistency, which would make it a lot easier to rename the parallel half-stations a few sections up. Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
13:12, 24 October 2016 (UTC)

Hmmm, when reading "c23" i'd expect the corners to be part of the "bullet" ... actually I have no bearing on parallel lines, but it should stay compareable with regular BSicons as   (lBHFf)! a×pdeHello! 15:07, 24 October 2016 (UTC)
@Axpde: Cf.   (lBHFc2) and   (lBHFc3) (less confusing than, say, lv-BHF--BHF or l-vBHF-BHF). Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
15:17, 24 October 2016 (UTC)
When I looked at this, my first thought was that   (lvBHFf) should be renamed l-vBHF and   (lvBHFg) should be lvBHF- . Useddenim (talk) 16:03, 24 October 2016 (UTC)
@Useddenim: Problem being that   (lvBHF-) is something else entirely; to follow this naming pattern we would need both horizontal and vertical parallel lines syntax. Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
16:06, 24 October 2016 (UTC)
  • Frankly, this renaming seems wrong to me:
  1. These are double stations, for parallel lines, one expects a "v" preffix. (They are also both symmetrical and to be used with vertical lines, so that pesky illogical rule about supressing the "v" preffix for assymetrical icons for parallel lines across doesn’t apply.)
  2. These stations has nothing to do with corners, and all to do with regular stations moved back or fro, so not only the new names are wrong but also the old names are correct.
  3. This is a «change for consistency» — with what?
-- Tuválkin 18:45, 24 October 2016 (UTC)

Agree (with Tuválkin): parsing the existing name gives legend v (parallel) BahnHoF moved forward; so it seems there's no need to change. Useddenim (talk)

@Tuvalkin, Useddenim: It's inconsistent with   (lBHFf) and   (lBHFg), which are moved forward or backward 250px as opposed to 125px. Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
03:52, 25 October 2016 (UTC)
I see — well, then maybe the best is to rename   (lBHFf) and   (lBHFg) respectively to   (lBHFff) and   (lBHFgg) (and ditto for their double line and/or line across variants). Would need some considerable moving and editing, but we’d end up with a simpler, more solid nomenclature. -- Tuválkin 16:18, 25 October 2016 (UTC)
@Tuvalkin: Makes sense; would align this series with   (v-STRlf) and similar. (  (l-BHF) might end up as l-BHFq or lBHFf though.) Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
05:35, 26 October 2016 (UTC)

LSTR endings[edit]

@Useddenim, Tuvalkin, Sameboat: Because of a potential conflict with   (tLSTRe)

Current Proposed
  (LSTRa) KLSTRa
  (LSTRe) KLSTRe
Repeat for all variations

Not sure about the prefix order though. (PS are there any elevated versions of LSTRa/e, or LSTR elevated–ground transitions?) Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
08:22, 26 October 2016 (UTC)

I don't think there should be K prefix on this, since it isn't a line beginning/end. (See   (tSTRa),   (hSTRe), for example.) Useddenim (talk) 10:45, 26 October 2016 (UTC)
CONTgq LSTRq LSTReq BSicon .svg LSTRaq CONTfq
@Useddenim: It isn't? (see   (KSTRa)) [I'd use a wider map but apparently no one bothered to copy over {{BS7}}.] Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
10:59, 26 October 2016 (UTC)
@Jc86035: AFAIK, all K-icons start at the centre. Useddenim (talk) 14:23, 26 October 2016 (UTC)
@Useddenim: I guess we could instead use the f and g suffixes (like   (ENDEf)) to prevent naming conflicts for (e.g.) a tunnel version of LSTRe. Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
14:33, 26 October 2016 (UTC)
Wouldn't KLSTRa just be the same as   (LENDEa) without the black bar? Useddenim (talk) 16:09, 26 October 2016 (UTC)
@Useddenim: Hmm I guess so. I'd still prefer to rename them though (enabling tunnel versions), so maybe LSTRa → LSTRg and LSTRe → LSTRf? Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
16:15, 26 October 2016 (UTC)
I'm not sure that that would be any better, as a/e denote start/end, while f/g are moved forward/backward. Useddenim (talk) 16:37, 26 October 2016 (UTC)

┌───────────────────────┘
@Useddenim: would KLSTRag / ef be valid? Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
03:39, 27 October 2016 (UTC)

(sigh) yes… Useddenim (talk) 03:46, 27 October 2016 (UTC)

Coloured road–rail crossings[edit]

Are   (SKRZ-G4u cerulean+) and   (SKRZ-G4uq cerulean+) valid icon names? Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
07:12, 27 November 2016 (UTC)

I would say they are, as the trailing hanging + indicates that the secondary “line” (in the case the road) is in its default color (which it is, thank the stars, and lets keep it that way!).
Likewise, a leading hanging + indicates that the primary “line” is in its default color. This was agreed upon back when we claned up all those “other” colors. Recently created icons such as   (vBHF sky-dBHF yellow) should be named instead   (vBHF-dBHF yellow+sky), etc.
-- Tuválkin 09:28, 27 November 2016 (UTC)
@Tuvalkin: Should   (vBHF sky-dBHF yellow) have the same geometry as   (vBHF-exBHF) (and then be named mvBHF yellow+sky)? (Incidentally, should icons like   (exvBHF-uBHF) be renamed exmvBHF or similarly?) Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
10:34, 27 November 2016 (UTC)
I’d say that the only time the half-moon geometry is appropriate would be when an existing station is being expanded in some way; eg BSicon .svgBSicon uexv-STR.svgBSicon exlvINT.svgBSicon vBHF-.svg (vBHF-uexINT)  which could indicate a new transit line being built adjacent to an existing rail line.
I believe the consensus was that the m prefix is only used when both features were identical except for colour. (I also thought that all existing were moved to the long-form names, with redirects.) I agree, however, with + renaming.
Finally, you might not be hearing from Tuvalkin until 11:59, 4 December 2016 (UTC). Useddenim (talk) 13:06, 27 November 2016 (UTC)
@Useddenim: So   (mvBHF black+orange) and   (exvuBHF-BHF)uexmvBHF (like   (uexmlvBHF)) but mvBHF-exBHF +green? Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
13:30, 27 November 2016 (UTC)
A cautious “Yes”, but I think it’s necessary to reexamine the discussion to check whether the m prefix only applies to plain/u/f/g combinations, or all colours. Useddenim (talk) 13:44, 27 November 2016 (UTC)

mBS2 ?[edit]

moved from User talk:Axpde

Gibt es Misch-Icons für BS2? (mBS2 -> gerader Strang Heavy, corner light; umBS2 -> gerader Strang light, corner heavy). Diese Erweiterung müsste mit den gängigen BS2-Bezeichnungen möglich sein. Ein Anfang wurde mit   (eBS2lb) gemacht, doch dieses Icon entspricht zum einen nicht der üblichen BS2-Notierung und ist zum anderen nur ein kleiner Bestandteil aller BS2-Icons. Da du meines Wissens alle BS2er erstellt hast, ware es nett, wenn du diese dazufügen könntest. --C21H22N2O2 (talk) 08:47, 21 November 2016 (UTC)
Are there mixed icons for BS2? (MBS2 -> straight strand Heavy, corner light; umBS2 -> straight strand light, corner heavy). This expansion should be possible with the usual BS2 designations. A start was made with (eBS2lb), but this icon does not correspond to the usual BS2 listing and is only a small part of all BS2 icons. Since you have to my knowledge created all BS2er, it would be nice if you could add these.

Ich glaube, das sollte korrekt benannt werden   (xmBS2l) (x Hauptmerkmal außer Betrieb, m gemischte Linien, BS2 Verschiebung 2/4 l nach links). Ich werde diese Symbole nächste Woche (nach Thanksgiving), wenn niemand anderes zu suchen. Useddenim (talk) 04:37, 24 November 2016 (UTC)
I believe this should be named correctly xmBS2l (x main feature out of operation, m mixed lines, BS2 shift 2/4 l to the left). I will take care of these icons next week (after Thanksgiving) if no one else does.
Klingt plausibel :-) Gruß a×pdeHello! 16:58, 24 November 2016 (UTC)
Sounds plausible
Die Umbenennung passt auf jeden Fall ins Schema. Wenn die Icons da sind, freu ich mich auf jeden Fall. Danke für die schnelle Hilfe! --C21H22N2O2 (talk) 17:18, 24 November 2016 (UTC)
The rename fits in any case into the schema. If the icons are there, I am happy in any case. Thanks for the quick help!

KRW bridges[edit]

@Useddenim, Tuvalkin, Sameboat: I requested renames for a bunch of ÜWB icons to match the pattern of   (KRWgo+l), but didn't realise there was also another naming pattern (  (extKRWl+lo) etc.). Which one of these is correct/preferable? Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
14:14, 4 December 2016 (UTC)

The former is a relic from the ÜW days. The latter pattern is newer and more universally applied. Useddenim (talk) 14:16, 5 December 2016 (UTC)
And why haven't you applied for Filemover privileges for yourself, so you don't have to keep making move requests? Useddenim (talk) 14:21, 5 December 2016 (UTC)
@Useddenim: Thanks for the suggestion. I've requested the right. Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
14:30, 5 December 2016 (UTC)
@Useddenim: Did I move them correctly? It's a little weird how the suffix u/o always refers to the bottom track, but the prefixes' "main line" is always the track on the bridge. Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
10:57, 10 December 2016 (UTC)
Should the e/x prefixes have been replaced with xl/xr/+xl/+xr suffixes? Not sure about the m/um prefixes, though. Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me
11:04, 10 December 2016 (UTC)
  • m =  main feature  secondary feature 
  • um =  main feature  secondary feature  Useddenim (talk) 12:24, 10 December 2016 (UTC)

GRENZE vs. ZOLL[edit]

@Useddenim, 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 BSicon .svgBSicon ZOLL.svgBSicon GRZq.svg  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×pdeHello! 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)

Elevated formations (legende)[edit]

Shouldn't icons like   (lhSTR-L+1) have the -L/R after the (+)n (i.e. lhSTR-L+1lhSTR+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)

Remaining ÜW icons[edit]

@Useddenim, Tuvalkin, 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 Symbol keep vote.svg 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)
  • Symbol keep vote.svg Agree. Useddenim (talk) 14:38, 10 December 2016 (UTC)

Random load of crap[edit]

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)

Icons with two 90° turns[edit]

(Aside from the inconsistently-named categories,)

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)

Weird icons[edit]

LBHFxa[edit]

@Useddenim, Axpde, 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 BSicon .svgBSicon exKSTRe.svgBSicon LKBHFa.svg (LKBHFaexKSTRe)  -- Tuválkin 12:47, 17 December 2016 (UTC)
    @Tuvalkin: It also matches BSicon .svgBSicon xKBHFe.svgBSicon LKBHFa.svg (LKBHFaxKBHFe) , 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-bottomOnly 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, Useddenim: So LKBHFa+xKBHFe? Jc86035 (talk) Use {{re|Jc86035}}
    to reply to me
    10:25, 18 December 2016 (UTC)
xKBHFe + LKBHFa
BSicon xKBHFe.svg
BSicon .svg
xKBHFe + LKBHFa
BSicon xKBHFe.svg
xKBHFe + LKBHFa
BSicon xKBHFe.svg
LSTR BSicon .svg LCONTf xABZqLl
KBHFxa BSicon .svg KBHFxa KBHFxa
LSTR BSicon .svg LCONTf xABZqLl
num1m BSicon .svg num2m num3m
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[edit]

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[edit]

@Useddenim, Tuvalkin, 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×pdeHello! 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[edit]

@Useddenim, Tuvalkin, Axpde: There are some inconsistencies with how the -L/R and l/r suffixes have been applied, particularly with   (hBHF-L) and   (uhBHF-L). So maybe this might help a little bit.

Current Proposed
  (BHF-R) etc. BHF-R
  (hBHF-R) etc. h(r)BHF
  (VIADUKT-L) etc. h(l)STRae
  (CSTR-Rag) etc. C(r)STRag
  (lhSTR+1-L+c2) etc. lh(l)STR+1+c2?
  (exhWBRÜCKEe-L) etc. exh(l)WSTRe (This isn't really a BRÜCKE anyway.)
  (CINT-R) etc. C(l)INT-R
  (CBHFCCq) etc. C(r)BHFCCq
  (STR-R) etc. STR-r
  (BHFlf) etc. BHF(l)f
  (BHFrgq) etc. BHF(l)gq
  (BHFlr) etc. BHF(l)
  (KRZo-L) etc. KRZ(l)o?
  (heCPICr) etc. heCPB-R? (see Useddenim's table above)
  (MASKr) etc. v-MASK
  (MASKrr) etc. MASK-r?
  (dMASKr) etc. dMASK-r?
  (MASKa) etc. MASK-

I haven't added platforms to this, as I'd rather not propose another affix just yet. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
09:16, 31 December 2016 (UTC)

I don't think it's necessary to rename the MASK icons. Useddenim (talk) 16:24, 31 December 2016 (UTC)

BSicon_FEATURE[edit]

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)

Parallel lines[edit]

c
c + vSTR
BSicon c.svg
POINTERl
Primary
c + POINTERr
BSicon c.svg
vSTR c
Secondary

@Useddenim, Tuvalkin, Axpde, 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)

c + POINTERr
BSicon c.svg
mvSTR c
Primary (heavy railway)
c
c + mvSTR
BSicon c.svg
POINTERl
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×pdeHello! 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, Lost on Belmont:@Newfraferz87, Vunz, Mahir256, Imperator3733, 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×pdeHello! 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 BSicon .svgBSicon uexSTRq.svgBSicon mvSTR.svg (mvSTRuexSTRq)  (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)