Talk:BSicon/Renaming/Archive 4

From Wikimedia Commons, the free media repository
Jump to: navigation, search
Archive This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Renaming "legende"

moved/copied from Category talk:Icons for railway descriptions/experimental/borders

There were recently some scattered discussions concerning the possibility of replacing the name segment " legende" with a more manageable and flexible preffix or suffix, root (i.e., uppercased) or not. I tried to gather those discussion here; there may be more. --Tuvalkin (talk) 03:58, 6 October 2011 (UTC)

Recent experimental use suggests that we have need for both a prefix and an icon root to expresse this, depending on the item depicted in these legend/overlay icons. -- Tuválkin 09:49, 20 February 2013 (UTC)

With a prefix

Let’s cast our vote on this?
N L- L l o O User
Symbol neutral vote.svg  Symbol neutral vote.svg  Symbol oppose vote.svg  Symbol neutral vote.svg  Symbol support vote.svg  Symbol support vote.svg  -- Tuválkin 09:49, 20 February 2013 (UTC)
Symbol support vote.svg  Symbol support vote.svg  Symbol neutral vote.svg  Symbol oppose vote.svg  Symbol oppose vote.svg  Symbol oppose vote.svg  -- Useddenim (talk) 13:43, 21 February 2013 (UTC)
Symbol neutral vote.svg  Symbol neutral vote.svg  Symbol support vote.svg  Symbol oppose vote.svg  Symbol oppose vote.svg  Symbol support vote.svg  -- AlgaeGraphix (talk) 02:09, 27 February 2013 (UTC)
Symbol oppose vote.svg  Symbol oppose vote.svg  Symbol oppose vote.svg  Symbol support vote.svg  Symbol neutral vote.svg  Symbol oppose vote.svg  a×pdeHello! 19:58, 27 February 2013 (UTC)
Symbol oppose vote.svg  Symbol oppose vote.svg  Symbol support vote.svg  Symbol support vote.svg  Symbol oppose vote.svg  Symbol oppose vote.svg  Circeus (talk) 18:48, 6 March 2013 (UTC)
−1 −1 0 0 −2 −1 (tally up)

I already thought about a substitute for the "_legende" suffix. It would be logical to find a prefix such as "l" for "legende" ... axpdeHello! 00:32, 4 June 2011 (UTC)

I love the idea of a substitute for _GRENZE _LEGENDEOops, fixed that! --Tuvalkin (talk) 05:33, 9 June 2011 (UTC), and you’re dead right it would be a preffix. Not so much enthused about "l", though, as it looks like an "1" or an "I", and there’s already the "l" suffix. But I’d go with the crowd on that one for sure. Tuvalkin (talk) 01:10, 4 June 2011 (UTC)
What about using the letter O (for overlay) as a prefix? Useddenim (talk) 14:33, 6 June 2011 (UTC)
Well, "overlay" does not describe the type of an icon but it's purpose! That's why I prefer the 'l'. And there's no problem with "I" or "1" - same with the 'l'-suffix! axpdeHello! 15:13, 6 June 2011 (UTC)
I only mentioned the fact that "l" is already used as suffix because e.g. "t" is used with the same meaning as both suffix and preffix and that could confuse some users needlessly. I like Useddenim’s idea about "o", but like I said, I’ll go with the consensus — which apparently is going to be whatever Axpde decides because «he’s got a gun »(deletion rights)« and he’s not afraid to use it.» --Tuvalkin (talk) 16:51, 6 June 2011 (UTC)
The "e" also has different meaning as prefix ("erstwhile") or suffix ("end"), same with "u" ("underground" vs. "underneath") or "m" ("mixed" vs. "middle"). And don't forget, there's already an "o"-suffix for "overhead"!
"concensus" does not mean you or me, even commons is the wrong place, we should at least ask the two biggest projects w:de: and w:en:! axpdeHello! 09:07, 7 June 2011 (UTC)
If the others aggree to introduce a new prefix as "o" or "l", your icons should be named "{ex}oGRENZE2" resp. "{ex}lGRENZE2" and so on. axpdeHello! 09:22, 9 June 2011 (UTC)
Well, there's yet no other convention for "legend type icons" than to add "_legende" to the name of the icon with the (straight) track. axpdeHello! 19:31, 7 June 2011 (UTC)
After realizing I did NOT need a lowercase l- prefix for single-line v- icons, I've been using it for legende and relatives (including NUL and leer) in my proposal. Circeus (talk) 18:52, 25 October 2011 (UTC)

About this renaming:

12:47, 16 December 2012 Useddenim (talk | contribs) moved page File:BSicon lvBHF.svg to File:BSicon LvBHF.svg

The lower case "l" is always a bad idea (because "1lI|") but the upper case "L" is already a BSicon preffix, the one for lücke. And even though only tracks can be lücke while absence of track is what defines these “legende” icons, it is still confusing to use the same prefix for both. These are two reasons to avoid "l"/"L" as prefix standing for “legende”; for that I favour "o" instead because is looks like a zero/nul and stands for "overlay" — and we’re using these much more as overlays than as legend key swatches. There is, I think, no risk of confusion caused by the "o" suffix, too. -- Tuválkin 19:43, 6 January 2013 (UTC)

I want change my views above concerning the unambiguity of "L" — it means "lücke" already and there would be ambiguous cases if we’d use it also for "legende": E.g., LENDE could be interperted to mean something like either   or  . -- Tuválkin 09:49, 20 February 2013 (UTC)
After some further thought, what about LROOT for lücke and L-ROOT for legende? Useddenim (talk) 15:24, 20 February 2013 (UTC)
IMO it is needlessly clunky. It introduces a new concept, prefix+dash, for no good reason — it is not like we’re running out of letters… -- Tuválkin 16:00, 20 February 2013 (UTC)
N (for LEGENDE) is unused. Useddenim (talk) 17:36, 20 February 2013 (UTC)
Useddenim, why are you against "O"/"o" now? It was originally proposed by you (on 6 June 2011), just half a screen above! ;-) -- Tuválkin 13:58, 21 February 2013 (UTC)
That was a year-and-a-half ago. I changed my mind. (Also Axpde made some valid points.) Useddenim (talk) 14:26, 21 February 2013 (UTC)

Explanation for my vote:

  • I don't like uppercase prefixes, "W" for "Water", "S" for "STREET" and "L" for "LUECKE" are confusing enough ...
  • We use the dash to split up parallel line icons, no good idea to introduce "L-" prefix ...
  • Among those two lowercase prefixes I have a strong preference for "l" ("legend") to describe the style of the icon (rather than the use).

That all folks a×pdeHello! 19:57, 27 February 2013 (UTC)

Prefix position

moved from Talk:BSicon/Colors#Tokyo

Currently, colour prefixes - i. e. "u" & "f", less sure about "g"/"ug" - come first, just like colour "postfixes" come last, and I say let's cling to that. It eases name generation via tables etc.; this is the outer layer of our non-existent-but-should-have-been-created regular grammatics. Topological changes come at an inner level; "ex"-ness, IMO, should come in between, at least in those cases where it can affect the whole of icon. YLSS (talk) 16:32, 18 March 2013 (UTC)

I am assuming that "l" (or whatever prefix) to replace "_legende" would go before anything else, but I’m not deadset on this, it was just the way these alternative names have been done recently (mostly by me, I guess). This should be discussed (at its proper place!), even if it will probably be easy to settle. -- Tuválkin 19:20, 18 March 2013 (UTC)
Well, I have no stance on overlays for "extra" elements, but for those derived from normal stations or lines, I would prefer "l" to go closer to the root (save maybe for "t", "h" etc.). Otherwise, it will be impossible to generate such tables as here, which is not a problem in itself, but shows some fault in the overall naming scheme. Cf. these: exl, ul, fl. YLSS (talk) 18:53, 19 March 2013 (UTC)

With a root ID

We could shorten it to something like "LGD" Circeus (talk) 14:03, 6 October 2011 (UTC)

Here I added a few legend/overlay icons using LGD instead of leer. Opinions? --Tuvalkin (talk) 05:05, 16 October 2011 (UTC)
Their use isn't exactly intuitive from looking at the icons themselves, but becomes clear once one looks at the example.
As far as the use of LGD for an otherwise empty (i.e. without track) icon, I would suggest NUL instead since it is the same word in so many languages. Useddenim (talk) 13:52, 16 October 2011 (UTC)
I wish I thought of NUL in time. :-\ That example will be better after I churn out some hSTR-L and hSTR-R icons crossing road. --Tuvalkin (talk) 14:48, 16 October 2011 (UTC)
I don't think "NUL" or "LGD" is a practical solution! "NUL" means "nothing", but there is something (esp. the whitened area!). And "LGD" implies, that the main feature of this icon is a *legend*, what's wrong too! The main feature (in your case) is a *bridge*, but without the track, so File:BSicon lBRÜCKEqr.svg will do better by far! a×pdeHello! 12:32, 25 October 2011 (UTC)
To clarify: I was thinking that NUL (as in "empty", ∅) would be used only for icons that would otherwise have the STR root, as in   (hSTRq) vs.   (hNULq). Useddenim (talk) 14:10, 25 October 2011 (UTC)
Oh yes; it would also replace the lower-case leer root. Useddenim (talk) 14:12, 25 October 2011 (UTC)

Prefixes and suffixes

(Is this subject discussed to a conclusion? Even if not, can it be summarized and allow for this section to be archived?) --Tuvalkin (talk) 23:42, 5 October 2011 (UTC)

moved from User talk:Axpde/Archive 3#BSicon suffixes r/l

Hi again! Concerning this:

30 June 2011 22:38 . . Axpde (talk | contribs) moved File:BSicon hWBRÜCKEar.svg to File:BSicon hWBRÜCKEa-R.svg over redirect [redirect suppressed] (lowercase "r" suffix has a different meaning!

I think I understand what the problem is: Not just that «lowercase "r" suffix has a different meaning» than what I tried to do in this case (because if so   (CPICr) and a million other such icons would be wrongly named), which was simply to mean "right", but that «lowercase "r" suffix has a different meaning» when used with BRÜCKE (or STR etc.) — that being track coming from the right.

Fair enough, I grok that. But "-R" seems to be a terrible way to fix it and name these icons; I think that the way to go is to rename these as members of the VIADUKT family: Current   (hWBRÜCKEa-R) to be hWVIADUKTra,   (hWSTR-R) to be hWVIADUKTr, etc.

What do you think? --Tuvalkin (talk) 22:55, 1 July 2011 (UTC)

Shame on you for wanting consistency! 8·0 But seriously: Agree. Useddenim (talk) 17:11, 2 July 2011 (UTC)
We have a German saying: "We come to hell's kitchen when doing this!"
The suffix "r" means "track running to the right"! And we mustn't reuse this suffix just because it's convenient. I already renamed all "Halfviaducts" to match "-R/L" ... and as long as you don't have a better idea we should keep this! a×pdeHello! 23:42, 2 July 2011 (UTC)
P.S.: I don't like the suffix in "CPICr" as well, but that's your english speciality, "CPIC" is no German ID so do whatever you like, but don't take this one as precedent! a×pdeHello! 23:44, 2 July 2011 (UTC)
Axpde, it is really hard to take you seriously, inspite of your titanic work. My “English” speciality? What does that even mean, considering that >99% of my work is in/for wp:pt?! --Tuvalkin (talk) 02:23, 3 July 2011 (UTC)
Sorry, Tuvalkin that "your" wasn't meant personally, "CPIC" stands for "cross platform interchange", so it's an English ID ... a×pdeHello! 09:37, 3 July 2011 (UTC)
Then what about using < for "on the right" or "continues to the right", and > for "on the left" or "continues to the left"? Useddenim (talk) 04:23, 3 July 2011 (UTC)
As a matter of principle "<" and ">" could be used for some special use, but I'm not sure whether it'd be wise to use those special icons in file names ... e.g. the "|" (possible meaning: in the middle) is definetly unusable.
Looking at the current usage we shouldn't change anything with the "l" and "r" suffix in the sense of "track running left/right". But we really need a sensible suffix for "structure on the left/right"! a×pdeHello! 09:37, 3 July 2011 (UTC)
My suggestion is to add the uppercase "R" or "L" directly to the ID of the icon (thus creating two new IDs for each), instead of as a suffix as done with   (hWBRÜCKEa-R) — like   (DAMML) as opposed to   (DAMMl). That doesn’t introduce any major change in what are stable naming conventions, and allows icon catalog table to show the left/right “half structure” icons in separate, contiguous tablerows (Also, it is a very bad idea to add a "-" with a meaning other that what’s used in so many assymetrical parallel track icons, like, say   (vBHF-STR). I wholeheartedly agree that "<" and ">" should be avoided in filenames.) --Tuvalkin (talk) 12:14, 3 July 2011 (UTC)
Hmmm, that sounds like a reasonable plan to me! I'm not sure whether others may hesitate to have lowercase and uppercase "suffixes" (even if the uppercase version melts into the icon ID ;-) a×pdeHello! 16:07, 3 July 2011 (UTC)
Precedent already exists for using upper case letters to modify the root. (Although, so far, all have been used as prefixes):
A Autobahn/Autoroute BSicon KRZo.svg KRZo BSicon SKRZ-Ao.svg AKRZo
K Terminal station (Kopfbahnhof) BSicon BHF.svg BHF BSicon KBHFa.svg KBHFa
L Interruption (Lücke) BSicon STRlf.svg STRlf BSicon LSTRlf.svg LSTRlf
MW Motorway BSicon STR.svg STR BSicon RM.svg MWSTR
S Suburban/commuter (S-Bahn) station BSicon BHF.svg BHF BSicon SBHF.svg SBHF
T split-level station (Turmbahnhof) BSicon BHF.svg BHF BSicon TBHF.svg TBHF
W Water/Wasser BSicon BRÜCKE.svg BRÜCKE BSicon WBRÜCKE.svg WBRÜCKE
Useddenim (talk) 12:35, 4 July 2011 (UTC)
Well put, indeed. I’m however partial to suffixation of such ID-modifiers, e.g. à la   (DAMML) instead of LDAMM, because when alphasorting BSicons by ID it falls next to   (DAMM). --Tuvalkin (talk) 15:58, 4 July 2011 (UTC)
Oh, don't take me wrong – that table was for illustration purposes. Those prefixes are type modifiers, and serve to group them all together in an α-sort. The proposed suffixes indicate directionality or orientation, and most certainly should group with the base icon. So I think we're all in agreement on this as ~~L = on left, ~~M (middle) = on both sides, and ~~R = on right? (With ~~F, ~~G and ~~C – for centre – applied to transverse cases.) Useddenim (talk) 19:02, 4 July 2011 (UTC)
I agree, but this is only Axpde’s talk page. ;-) Maybe this discussion should be moved to / linked from a more central location and after a few days, if there's no againsts, implemented? --Tuvalkin (talk) 20:58, 4 July 2011 (UTC) ✓ Done

Proposal for uppercase suffix

Actually I feel honored to host this talks, they have been quite efficient :) And I agree with both of you, capital pre-/suffixes are modifiers of the structure, lowercase ones modifiers of the track etc. (even if I'm not very happy with the "A" and "MW" modifiers, I'd introduced complete new IDs instead). Ok, let's propose this rule (with two modifications):

  • ~L structure continues to/exists only on the left
  • ~M structure continues to both sides/exists only in the middle
  • ~R structure continues to/exists only on the right
  • ~A structure continues to/exists only on the bottom (like   (KBHFa))
  • ~C structure continues to both ends/exists only on the center
  • ~E structure continues to/exists only on the top (like   (KBHFe))

I think A and E is more sensible. Regards a×pdeHello! 21:57, 4 July 2011 (UTC)

BSicon CPICll.svg
BSicon .svg
BSicon CPICuu.svg
BSicon CPICrr.svg
BSicon .svg
BSicon CPICdd.svg
BSicon CPIC.svg
BSicon .svg
BSicon CPICqq.svg
BSicon .svg
BSicon CPICll.svg
BSicon CPICdd.svg
BSicon .svg
BSicon CPICrr.svg
BSicon CPICuu.svg
Okay, this seems discussion to be going the right way, after a sputtering start. Axpde, I took the liberty of moving your comment/proposal back to indent level zero because it is a host's proposal after discussio (and because it was getting really longer). For one I agree with this suggestion, but for one minor quibble: A/E is not better than F/G, as this is neither a case for ahead and backwards in travelling direction, nor start and end along the conventional direction of a track. This “top” and “bottom” of the icone as we see it are still left and right of the travelling direction of a horizontal line. Thus they should be IMO be simply added a "q".
Thus (assuming that the “default” travelling direction is from left to right of the viewer’s screen, inspired on the top-to-bottom of regular lines and following the article’s text direction):
right middle left
straight up FOOR FOO FOOL
across FOORq FOOq FOOLq
--Tuvalkin (talk) 03:52, 5 July 2011 (UTC)
Just to add that the use of   (CPIC) halves in the examples was meaningless, just to illustrate the concept of “thingy foo” at left, right, and middle. Also, that I understand there’s a difference between FOOM and mere FOO, akin to that of   (INT) vs.   (INTm). --Tuvalkin (talk) 04:09, 5 July 2011 (UTC)
The concept of "taking the normal icons and rotate them by 90°" has a huge disadvantage: Rotating clockwise or anti-clockwise ...?!?
As you can seen I can take your example and "pervert" it to explain the diametral opposed meaning. That's why we need "A" and "E" do describe the position!
And additionally we need "M" and "C", e.g.   (INTm) should rather be "INTM" ... and   (CPICm) should be "CPICM"! a×pdeHello! 10:41, 5 July 2011 (UTC)
uBHFlr uABZlr uBHFll
BHFlr ¦ BHFll
BSicon .svg uBHFrf BSicon .svg
BSicon .svg uBHFlf BSicon .svg
BSicon .svg uBHFrg BSicon .svg
BSicon .svg uBHFlg BSicon .svg
uBHFrr uABZrl uBHFrl
BHFrr ¦ BHFrl
Simply put, we need to consider both orientation and directionality. When there is a clear direction of travel there is no problem, as a quick inspection will let one determine which suffix letter applies to which attribute. (Even though the single-direction station is not the best example, as the horizontal icons have the direction first and the vertical icons have the feature first, the construct is still readily apparent.)
descriptions are still referenced from top-to-bottom travel (↓).

BSicon .svg
BSicon CPICll.svg
BSicon CPICdd.svg
FOO+Rq or FOO-Lq
BSicon .svg
BSicon CPICrr.svg
BSicon CPICuu.svg
FOO+Lq or FOO-Rq
Would it be too radical a change to introduce the +/- concept to transverse (q) icons? where FOO+Rq indicates the feature is on the right when rotated +90° and FOO-Rq indicates the feature is on the right when rotated -90°. (The latter case is also equivalent to FOO+Lq.)
I'm not sure where the negative rotation would be used (although it may be necessary for an icon with asymmetry on two axes), but I would include it in the specification anyways to allow for the future. Initially, any new icon names would use +, until a case came along that required disambiguation and the -.
Useddenim (talk) 13:31, 5 July 2011 (UTC)

A further thought: the FOO+q/FOO-q construct could solve other problems, too. For example, Tuvalkin's   (exvBHFl) would become exvBHFa+q; compared with   (vBHFl) which would be vBHFL under the proposed naming scheme. Useddenim (talk) 15:41, 5 July 2011 (UTC)
uBHFlr uABZlr uBHFll
BSicon .svg uBHFrf BSicon .svg
BSicon .svg uBHFlf BSicon .svg
BSicon .svg uBHFrg BSicon .svg
BSicon .svg uBHFlg BSicon .svg
uBHFrr uABZrl uBHFrl

There we have another problem: Using the same suffix with two different meanings will end up in chaos. Better have the "L" & "R" to indicate whether the structure is on left resp. right side and the "l" & "r" to indicate the direction of travel!

And conc. +90° vs. -90° ... we already have severe problems to explain "direction of travel" and that left and right are opposed to the normal point of view. We get into hell's kitchen when starting to introduce +/-90° rotations.

Mathematically +90° is always seen clockwise, but clockwise from top to bottom leads to ... headache! :(

KISS! Keep it smart and simple! a×pdeHello! 16:14, 5 July 2011 (UTC)

I see the point about “perverting” the example I gave by turning the curve to right instead of left, but I started out assuming that we could decide arbritarily that horizontal tracks run from left to right of the page, just like it is assumed that vertical tracks run from top to bottom. If anything, this one is simpler to get through user’s heads because while top-bottom implies that left and right are swapped, horizontal’s are arbitrary and users just need to know how to tilt their heads (and users are used to tolt their heads, with all those smileys!). This makes side naming simpler for horizontal tracks ("q" suffix meaning 90° rot. counter-clockwise) and avoids complex and unintuitive use of "a" and "e" suffixes — which would simply mean «start/end of something along the “natural” direction of the track (top-down or left right)» with no exception for these to mean left/right of the track whenever the track is horizontal. Please note that this is me explaining my idea, not insisting on it. --Tuvalkin (talk) 11:27, 8 July 2011 (UTC)

Icon name query

moved from Talk:BSicon

I would like to know the proper way for naming canal swing bridge icons, particularly those where the bridge carries a railway. This is because I recently created   (umKRZqusw) and   (uxmKRZqusw) and based the name on the existing   (umKRZusw). --Redrose64 (talk) 19:23, 22 July 2011 (UTC)

I would suggest a new root based on the German Drehbrücke (swing bridge) – DBK possibly? – and then just follow the same pattern as the existing KRZ icons. Useddenim (talk) 21:45, 22 July 2011 (UTC)
It's a complete different icon so a new root ID is adviseable. At the moment I have no better idea, so let's call
old icon new comment
umKRZqusw BSicon umKRZqusw.svg DBK } the swing bridge is the main point of interest
uxmKRZqusw BSicon uxmKRZqusw.svg xDBK
umKRZusw BSicon umKRZusw.svg DBKq swing bridge runs across
Regards a×pdeHello! 11:38, 23 July 2011 (UTC)
I think such a change requires a broader discussion, as there are multiple other no-rail swing bridge icons:   (uAKRZusw),   (uKRZuysw),   (uSWING)  (uHSWING)... Furthermore the canal in these would usually be considered the primary feature...Circeus (talk) 04:05, 26 July 2011 (UTC)
I asked at en:Wikipedia talk:WikiProject UK Waterways#Route diagram icons for swing bridges with absolutely no response. --Redrose64 (talk) 16:57, 26 July 2011 (UTC)
I responded at UK Waterways, once I saw it, but I don't get to look at it every day. My suggestion was umKRZuswq ought to be mKRZusw, and umKRZuxswq ought to be xmKRZusw, so they become railway icons with canals crossing, rather than canal icons with railways crossing. This then allows em, exm and gm variants to be produced as necessary. However, I like the idea of a new root, but the DBKq is all wrong, and was strongly resisted over other icons by User:Axpde for normal bridges. I would therefore suggest
old icon new comment
umKRZusw BSicon umKRZusw.svg uDBK canal is main route
Cheers. Bob1960evens (talk) 14:15, 4 August 2011 (UTC)
Further thought: ought there to be an 'm', since bridges with mixed railway/canal now use an 'm' to show this. So mDBK, xmDBK, umDBK, etc. Bob1960evens (talk) 14:58, 4 August 2011 (UTC)
As said before, the swingbridge is main feature, are it's the railtrack, that swings! The canal is not moved at all ... please remember, you "reused" the blue tracks (which we railroaders call "light railway", not "canal" ;-) but the red tracks are the original BSicons ;-) a×pdeHello! 22:47, 3 September 2011 (UTC)

Archiving required

Some of the past topics need to be archived, as this page has been placed into Category:Pages with too many expensive parser function calls, and the {{BSicon quote}} template will not display all the icons on the page. Useddenim (talk) 19:15, 17 December 2011 (UTC)

Okay, but — which of the above are ready for archiving? -- Tuválkin 22:25, 17 December 2011 (UTC)
(partly ✓ Done) -- Tuválkin 23:03, 17 December 2011 (UTC)
Did some more. But everybody should be trying to figure out if there's pending threads and archive those which are all decided on (or whose subject in now hot in another thread/section). -- Tuválkin 22:30, 12 January 2012 (UTC)

This is getting too big again (with BS-q not working at the bottom of the page). I’m moving to a separate page (not archive) the discussions that pertain to the SPL icon root, as there’s nothing ready for archiving. Still it would be great if BS-q, BS-o, andand other “expensive templates” are used when they are really necessary, not just for ornament (like in titles). -- Tuválkin 08:57, 20 May 2012 (UTC)

Renamed icons still around

moved to Talk:BSicon/Redirects

Suffix problems

While I was still working on my renaming proposal, the icons   (BHF-L) and   (BHF-R) were uploiaded. This causes problems: I intended L/R/M to be used WITHOUT a hyphen. Compare:   (KRZo-L) (itself problematic: it should have been KRZ-Lo, I'm not sure if I caused the problem...) and   (BHFrf) (which was the intended recipient of BHF-R!)...Circeus (talk) 01:39, 3 February 2012 (UTC)

Oh crap! Now I have to start over… Useddenim (talk) 05:35, 3 February 2012 (UTC)
Technically I'm the only one to blame for failing notice the problem with the "BHF-" set earlier ><. Circeus (talk) 20:37, 3 February 2012 (UTC)
So then you didn't see en: Wikipedia talk:Route diagram template/Catalog of pictograms/stations#Found in ja.wikipedia BSicon catalog (ja:Wikipedia:経路図テンプレート/鉄道用ピクトグラム一覧/駅). Useddenim (talk) 00:12, 4 February 2012 (UTC)
I barely glanced at it, it wasn't until I relooked at the above convo it suddenly struck me. It was really just a massive brainfart on my end. Circeus (talk) 02:14, 4 February 2012 (UTC)

JCT root

  (utvJCTgo+l)   (utvJCTgu+l)   (utvJCTgu+r)   (utvJCTgol)   (utvJCTgur)

I uploaded these with the JCT root (a standard English abbreviation for JunCTion) as I couldn't figure out what they really should be called. Any suggestions? Useddenim (talk) 10:25, 21 May 2012 (UTC)

I gather that this new JCT is both an ABZ (because lines coming from / going to disparate directions branch/join to be a single one) and a SPL (because single-track changes to/from double-track). -- Tuválkin 14:42, 4 June 2012 (UTC)
How does it compare with   (vKRZl-KRZru), considering their topology? Circeus names it DVG (from "diverge/divergieren"). Would it be possible/desirable to conflate these new names? -- Tuválkin 08:48, 5 June 2012 (UTC)
Then consider   (utvJCTgol) vs.   (utvSTRl-KRZo): in both cases the through line is above and the branch is to the left. Useddenim (talk)
We need a formal way to deal specifically with "sublines" silliness i.e. a regular-width line splitting into two twin lines and recombining. Previously there were only a few such things (mostly within the   (vÜST) family:   (vÜSTBl) up to   (exvÜSTu+r)). Circeus (talk) 20:40, 22 June 2012 (UTC)
Agreed. The BSicon naming system starts to break down when there are more than two features on an icon:
  •   split from above, split from left, crossing/curves;
  •   line through, line across, corners (although User:Maxima m (contribs) is to be applauded for his work in creating all the missing (kKRZ) icons);
etc. Useddenim (talk) 10:45, 26 June 2012 (UTC)

kKRZ: Naming conflict

(Another one…) I noticed that   (xkKRZlxr+r) shows a bridge, so I marked it for renaming to   (xkKRZolxr+r), and dind’t think much more of that mistake. (It was a mistake, yes?) -- Tuválkin 11:38, 11 June 2012 (UTC)

  (xkKRZxrl+r) now fixed. -- Tuválkin 15:35, 17 February 2013 (UTC)

However, I noticed that some of these kKRZ icons, with three (and four) corners, the order of the secondary (rather tertiary?) lines is not always rl+rl (with one missing, for 3 corners). Is there an underlying system I'm not getting, or this does need fixing? E.g., should   (xkKRZolxr+r) be   (xkKRZoxrl+r) instead? (I’ll be putting several tests in a table here) -- Tuválkin 11:38, 11 June 2012 (UTC)

  (kKRZul+lr) vs   (kKRZol+rl),   (kKRZor+rl) vs   (exkKRZoxr+xlr), etc. With two corners, but they could be similar cases.   (kKRZrl) vs   (kKRZulr), and   (kKRZo+rl) vs   (kKRZu+lr). I do not understand the difference of suffix (+)lr and (+)rl. Suffix (+)rl be renamed to (+)lr? --Maxima m (talk) 18:06, 11 June 2012 (UTC) ID prefix typo --Maxima m (talk) 18:09, 11 June 2012 (UTC)
moved from User_talk:Tuvalkin#File:BSicon xkKRZlxr+r.svg:

Only the track to the right is out off date, so the right name is File:BSicon xkKRZlxr+r.svg, i.e. the first name was correct! a×pdeHello! 12:02, 18 February 2013 (UTC)

The first name was NOT correct as it shown a bridge but included not "u" nor "o" — i.e. should show a flat cross. Me and Maxima cannot figure out the “correct”/expected order for the sufixes — is it "lr" or "rl"? (And — with or without "+", present or absent.) Can you explain? -- Tuválkin 22:03, 22 February 2013 (UTC)
You must have misstaken me, I was talking about   (xkKRZxrl+r), that has a level crossing. My point was the "xrl" part, which suggests that both l and r part are off use which they aren't. It should be "lxr", left in use, right off use.
The order should be: {lr}{x{lr}}{+{lr}{x{lr}}}
  1. to left/right (in use)
  2. to (ex) left/right (off use)
  3. from(+) left/right (in use)
  4. from(+) (ex) left/right (off use)
I hope this helps! a×pdeHello! 13:00, 24 February 2013 (UTC)
These two fixed now:
  •   (xkKRZxlr+r)
  •   (xkKRZlxr+r)
-- Tuválkin 21:04, 25 February 2013 (UTC)

P.S.: Conc. "lr" vs. "rl" - there is no "rule", but to have it uniformly I'd prefer alphabetical order, i.e. "lr". a×pdeHello! 13:02, 24 February 2013 (UTC)

Choosing "lr" instead of "rl" seems to be the usual practice — it should be spelled out as a rule, or else ppl will assume a given icon doesn’t exist when it doesn’t up show up if called by the equivalent name. Also necessary to fix the tables at en:Wikipedia:Route diagram template/Catalog of pictograms/compound junctions and rename any stray icons. -- Tuválkin 21:04, 25 February 2013 (UTC)
If we are using alphabetical order, then even more so that corner numbers should be in sequence. See this for Axpde's latest aberration. (If both 1 and 4 were ex, then it would be   (exABZ+14), not   (ABZ+x14). See also   (ABZ+1x4).) Useddenim (talk) 16:32, 6 April 2013 (UTC)
Further discussion split to Talk:BSicon/Renaming/ABZ#l & r order

I found among 559 k-icons nine using "rl" instead "lr":

  (kKRZo+rl)   (kKRZo+lr)
  (kKRZol+rl)   (kKRZol+lr)
  (kKRZor+rl)   (kKRZor+lr)
  (kKRZorl+l)   (kKRZolr+l)
  (kKRZorl+r)   (kKRZolr+r)
  (kKRZorl+rl)   (kKRZolr+lr)
  (kKRZrl)   (kKRZlr)
  (kKRZurl+r)   (kKRZulr+r)
  (kKRZurl+rl)   (kKRZulr+lr)

General renaming? -- Tuválkin 21:39, 25 February 2013 (UTC)

Hmmm, how about moving and leaving the redirects behind? And creating redirects where they're missing? a×pdeHello! 20:14, 27 February 2013 (UTC)
I think there’s no need for redirects here, as rthe usage is minimal and the naming convention is simple and firmly established. (I thought I replied this back then, then YLSS’s addition below draw in my attention.) -- Tuválkin 09:34, 20 November 2013 (UTC)
Also found & moved   (exkKRZuxlr+xr) &   (exkKRZuxlr+xlr). Getting rid of redirects: "lr" order has, I guess, become universal. YLSS (talk) 15:01, 19 November 2013 (UTC)

BSicon uCONT-f.svg & BSicon uCONT-g.svg

Can anyone explain why M0tty (talk · contribs) went and renamed these two files without any notification or discussion? AlgaeGraphix (talk) 21:51, 1 January 2013 (UTC)

Because someone has affixed the template {{duplicate}} to the page file, and that's part of expeditious procedures that do not require prior discussion. If it was a mistake on my part, I'm sorry. --M0tty (talk) 09:52, 2 January 2013 (UTC)
No; it appears that the error was on the part of Xeror (talk · contribs) who created the earlier version, but never bothered to add the new icon(s) to the proper page of the Wikipedia:Route diagram template/Catalog of pictograms. Useddenim (talk) 12:56, 2 January 2013 (UTC)

More about parallel stations

(Cf. Talk:BSicon/Renaming/Archive 3#Double lines with one-side-only stations.)

After generating the huge (and cullworthy!) table at en:Wikipedia talk:Route diagram template/Catalog of pictograms/parallel stations, what seems to be a few naming inconsistencies cropped up. One is this:   (vxSTR-eBHF) (from 2010) looks the same as new icon   (vexSTR-eBHF), and the latters' name seems to be better, as there's no sense in "xSTR" (or "eSTR"), single feature icons such as STR can only be "ex" or null, when it comes to status prefixes. I suggest   (vxSTR-eBHF) to be removed, after all its uses are changed to   (vexSTR-eBHF). Opinions? -- Tuválkin 17:47, 4 January 2013 (UTC)

Since the mal-named one is older, the proper procedure would be to tag vexSTR-eBHF as {{Duplicate}}, then rename vxSTR-eBHF. This would preserve the history (for anyone who cares — I don't, but I've had my knuckles rapped for doing it the easy way…) Useddenim (talk) 00:50, 5 January 2013 (UTC)
That's the proper way, I agree. -- Tuválkin 03:46, 5 January 2013 (UTC)
Or, even better, replace the image of "x" icons with what that name means (red disc on pink stroke) and change the usage to the "ex" icons. I started doing this. -- Tuválkin 19:46, 6 January 2013 (UTC)
As long as there isn't too much Global Usage… Useddenim (talk) 00:08, 7 January 2013 (UTC)
I type really fast now. ;-) -- Tuválkin 02:07, 7 January 2013 (UTC)

✓ Done. Replaced all usage to   (vexSTR-eBHF), nominated   (vxSTR-eBHF) for deletion with a request to merge as a previous version. So not my fault that it was plainly deleted. YLSS (talk) 09:43, 17 October 2013 (UTC)

Stations and stops interchange (BHF-X)

Without bringing up the fact that icons in Category:Icons for railway descriptions/stations and stops interchange are still very far from forming coherence, even those that seem to follow up-to-date naming patterns pose some questions. Those in question are:

  •   (KBHFa-L)  (KBHF-La)
  •   (KBHFxe-R)  (KBHF-Rxe)
  •   (KBHFxe-M)  (KBHF-Mxe)
  •   (xKBHFa-M)  (xKBHF-Ma)

All of these were originally uploaded with the titles to the right and later renamed to those on the left, if I understand correctly with the intention to bring suffixes away from "-X" and closer to "BHF" (I was unable to find any relevant discussion). However, there still seems to be a larger number of icons with lower-case suffixes following "-X". My own objection is that "KBHF-X" here is more of a single, indivisible root; that is, "-X" is a modifier of a higher priority than various a's, x's and so on. In any case, I guess a single pattern should be followed. YLSS (talk) 02:02, 10 February 2013 (UTC)

(comment) It seems the issue began here. YLSS (talk) 14:27, 17 February 2013 (UTC)

So what, no one opposes me moving these four back? YLSS (talk) 18:15, 15 February 2013 (UTC)
At first glance, you seem to be right, but we all want to hear the opinion of Useddenim, who made the renamings. -- Tuválkin 18:36, 15 February 2013 (UTC)
Three issues to be considered:
  1. Station type then connection vs connection then type;
  2. UPPER CASE vs lower case (see Interchange > Between modes);
  3. separator (-) vs no separator.
My preference (today, at least) is station type then connection; Upper case; with separator; but (unlike a certain admin) I am willing to accept whatever the group consensus is. Note a) these also affect the Cross-platform interchange; and b) even Circeus isn't consistent within his overall proposal. Useddenim (talk) 17:40, 17 February 2013 (UTC)
This certain admin prefers KBHF-Xyz, but that's just my opinion. a×pdeHello! 12:07, 18 February 2013 (UTC)
I didn't get to include as many icons as I would have liked in the proposal before I burned out on it, but I am curious as to what inconsistence you're talking about? Besides my getting confused at a later point about the difference between my proposed BHFR ("feature continues to the right") and BHF-R ("icon has only the right half of the feature"), aside. Circeus (talk) 15:59, 23 February 2013 (UTC)

Renamed the aforementioned four icons, as well as   (exKBHF-Re),   (exKBHF-Le),   (uKBHF-Ra). Solely for consistency sake, choosing a path of lesser difficulty. At least this page now looks OK. YLSS (talk) 14:18, 20 March 2013 (UTC)

Station middle, with no lines

I created   (KBHF-M) because I forgot about   (BHFm legende). Recording it here, for reference, neither name is really good. -- Tuválkin 13:58, 7 March 2013 (UTC)

AlgaeGraphix was fast to change   (dKBHF-M) to   (dBHFm legende), and had time to add some snark — too bad he could not find a couple more minutes to fix the icon’s use. After having done that myself, my reply to his question: Where’s the reason for "K"? It is exactly the same reason as for "legend": None. At least no logical and simple reason, though both can be justified by more or less convulated reasonings. Lets discuss.
And please, AlgaeGraphix and Useddenim and all (not talking with Axpde at this point) — don’t mistake my interest in consensus and others’ opinions with a freepass to walk all over me.
-- Tuválkin 22:44, 7 March 2013 (UTC)
IMHO   (lBHF-M) resp.   (dlBHF-M) suit best. Just my two ct. a×pdeHello! 12:29, 9 March 2013 (UTC)
Sorry, it wasn't snark, just meant as an honest enquiry to the possibility that you may have intended it to represent something else. (After all, who hasn't accidentally uploaded the wrong file?) And unfortunately no, I didn't have "a couple more minutes" at the time: my breaks at work are dependent on others' schedules.
My interpretation of the appropriateness of "legend": this icon is dependent on other (adjacent) ones for context, otherwise it's merely a brick red rectangle. {{Rename|File:BSicon_BHFm_legende.svg|File:BSicon_BRICK.svg}}?
AlgaeGraphix (talk) 21:34, 17 March 2013 (UTC)
Following this logic we had to rename   (BHF legende) to something like   (BIG RED DOT). Silly, isn't it? a×pdeHello! 12:09, 18 March 2013 (UTC)


Following up on Useddenim’s suggestion above, I uploaded some noew summit variations, using the new icon root "GIP" (from "Gipfel"). See here. -- Tuválkin 16:17, 7 March 2013 (UTC)

Experimental icons

I would suggest using an ! somewhere in the icon name (affix, or compound separator) to indicate that it is an experimental icon. I've uploaded a few –   (uhBHF!) for example – without incurring anyone's wrath. Useddenim (talk) 21:56, 15 February 2013 (UTC)

That’s what I do, too, when there is an opposition between an existing icon and a suggested change in its geometry, such as   (uhBHF!) vs.   (uhBHF), or when a consensually correct name is taken by an unmatching image, the filename with the "!" to be dully changed to its natural name as soon as the content of that name gets renamed (there have been a lot of such cases, see archive, apparently none current).
I’m not sure about using a "!" in a filename when the experiment is the filename itself, not the icon (the yellow horizontal end station above is undisputed in its geometry) — seems to go against the very notion of a naming experiment.
-- Tuválkin 04:57, 16 February 2013 (UTC)


see also: Talk:BSicon/Icon geometry and SVG code neatness#BHFCC & BHF+TUNNEL

We now have a consistent sequence:   (BHFCC)   (BHFCCa)   (BHFCCe)   (uBHFCC)   (uBHFCCa)   (uBHFCCe)
And some inconsistent:   (utBHFCCa)   (utBHFCCe) vs.   (utBHFa)   (utBHFe) vs.   (BHF+TUNNELa)   (BHF+TUNNELe).
Which one should be followed? YLSS (talk) 22:34, 23 February 2013 (UTC)

Open station Tunnel station
regular At start   (BHFCCa)   (uBHFCCa)   (tBHFCCa)   (utBHFCCa)
At both   (BHFCC)   (uBHFCC)   (tBHFCC)   (utBHFCC)
At end   (BHFCCe)   (uBHFCCe)   (tBHFCCe)   (utBHFCCe)
terminal At start   (KBHFCCe)  
BSicon .svg
BSicon .svg
  (tKBHFCCe)   (utKBHFCCe)
At end   (KBHFCCa)  
BSicon .svg
BSicon .svg
  (tKBHFCCa)   (utKBHFCCa)
transition At start   (utBHFa)
At end   (utBHFe)
regular At start   (BHFCCqa)   (uBHFCCqa)   (tBHFCCqa)   (utBHFCCqa)
At both   (BHFCCq)   (uBHFCCq)   (tBHFCCq)   (utBHFCCq)
At end   (BHFCCqe)   (uBHFCCqe)   (tBHFCCqe)   (utBHFCCqe)
terminal At start   (KBHFCCqe)  
At end   (KBHFCCqa)  
transition At start   (utBHFl)
At end   (utBHFr)
  (utBHFa) and   (utBHFe) should be redrawn as BSicon ulBHF.svgBSicon utSTRa.svg  and BSicon ulBHF.svgBSicon utSTRe.svg . (It doesn't show too clearly, but the tunnel portal spans the station, which is a not-uncommon occurrence. Useddenim (talk) 23:49, 23 February 2013 (UTC) ✓ Done. Useddenim (talk) 00:48, 26 February 2013 (UTC)
Thanks for clarifying! YLSS (talk) 08:41, 24 February 2013 (UTC)

BTW, you've created   (tBHFCC), while there had already been   (BHF+TUNNEL), which should have rather been moved to the former title. I've tagged the latter as duplicate, but I guess it will get deleted after a month... YLSS (talk) 15:37, 24 February 2013 (UTC)

I missed that icon. Hm, anyway not a month — the deletion request will be rejected because they are not exact duplicated, graphically, even though they are, for us, semantically identical. To be addressed at Talk:BSicon/Icon geometry and SVG code neatness#BHFCC & BHF+TUNNEL. -- Tuválkin 16:28, 24 February 2013 (UTC)

Somehow we missed terminal stations here, which bring two new patterns: "KBHFC" (note single "C") and "KDSTo". If this was discussed before, sorry, just wanted to clarify. So, we have:

  1.   (uKBHFCCe) - no questions here.
  2.   (KBHFCa) (x4 directions + ex),   (KDSTCa) (x4 directions + ex)
  3.   (uextKDSTao) &   (uextKDSTeo)
  4.   (KBHFa+TUNNEL) &   (KBHFe+TUNNEL)

-- YLSS (talk) 16:36, 15 March 2013 (UTC)

✓ Renamed as well. YLSS (talk) 14:10, 20 March 2013 (UTC)

v! icons

Moved from User talk:Tuvalkin.
Moved to Talk:BSicon/Renaming/SPL#v!_icons.


moved to Category talk:Icons for railway descriptions/crossing road#Renaming

More Grenzen

moved from Talk:BSicon/Icon geometry and SVG code neatness#More Grenzen
moved to Category talk:Icons for railway descriptions/experimental/borders#More Grenzen

Added icons

Moved from sv:Wikipedia Diskussion:Formatvorlage Bahnstrecke#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 xKBFlg.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)



moved from User talk:Axpde/Archive 1

BSicon CONTr BSicon CONTgq.svg versus exCONTr BSicon exCONTr.svg? Same with CONTl and exCONTl. Please consider fixing. -- 10:11, 6 February 2010 (UTC)

I don't agree with the naming suggestion. From File:BSicon KBHFr.svg, the "r" specifically mentions that it is the right end (with the track facing left). To keep consistency with the KBHF series, CONTl and CONTr can keep; the others need to be changed. Newfraferz17 (talk) 10:58, 2 April 2010 (UTC)
The 'r' indicates that the track continues to the right (seen in "forward driving direction", i.e. from top to bottom of the icon)! axpdeHello! 22:48, 2 April 2010 (UTC)
Wait...I take my words back. I'm confused now; it seems that File:BSicon_STRl.svg BSicon STRl.svg and File:BSicon_hSTRl.svg BSicon hSTRl.svg are different too. Which is the correct set?
  • Set 1: KBHFl, CONTl, hSTRl (track comes from the right)
  • Set 2: exCONTl, STRl (track comes from the left)
— Preceding unsigned comment added by Newfraferz17 (talk • contribs) , 3. April 2010, 01:14 Uhr (UTC)
File:BSicon STRl.svg shows the correct direction (to the left), but I have general objections to theses icons because of the inflationary use of the suffix 'l'. IMHO "STRl" should show this BSicon STRlf.svg (which is "STRlf", just to get rid of the 'f'/'g' system in tracks and junctions). Maybe we should introduce another new root as we did with "CONT" ... hmmm.
  1. Symbol support vote.svg Support KBHFl, exCONTl, STRl – track goes to the left (as seen in driving direction)!
  2. Symbol oppose vote.svg Oppose CONTl and hSTRl – track goes to the right (again seen top to bottom)!
axpdeHello! 09:20, 3 April 2010 (UTC)
I back this proposition. Wiebevl (talk) 08:39, 5 April 2010 (UTC)


moved from User talk:Axpde/Archive 2

Why did you exchanged CONTl and CONTr icons? Can you differ where's left or right? (talk) 21:05, 7 November 2010 (UTC)

It's about consistency. You look from an upside down perspective, so down is forward, up is back, etc. -mattbuck (Talk) 22:08, 7 November 2010 (UTC)
It's about stupid. Noone is really interesting WHERE FROM you turn left or right, but WHERE TO you turn: left or right. So it's just mess up. Anyway, this stupid illogical renaming screwed up thousands of route templates all over the wikis. And guess noone's gonna fix it. (talk) 20:02, 12 November 2010 (UTC)
It's always been the same: Looking in "driving direction", i.e. from top to bottom. It's neither stupid nor illogical, and least of all it's a "renaming", rather a "re-renaming". I don't know what you're going to do, but I've already changed dozens of route templates in a dozen different local projects! Blame whoever you like, but not me nor the original creators of the BSicons! axpdeHello! 08:17, 13 November 2010 (UTC)

Maybe we should enlarge the font of corresponding lines in the policies ... axpdeHello! 23:14, 10 November 2010 (UTC)


Since we have   (ENDEa) =>   (ENDExa), why do we have   (ENDEl) ≠>   (ENDExl) and   (ENDEr) ≠>   (ENDExr)? Should these two be swapped in places? If so, could someone with admin rights do this neatly? Thanks. YLSS (talk) 20:37, 22 March 2013 (UTC)

Oh, and also these, if I don't ask much:   (LENDEl) vs.   (LENDEr),   (exLENDEl) vs.   (exLENDEr),   (tENDEl) vs.   (tENDEr),   (extENDEl) vs.   (extENDEr),   (uextENDEl) vs.   (uextENDEr). Thanks again. YLSS (talk) 20:46, 22 March 2013 (UTC)

You're right,   (ENDEl) and   (ENDEr) show the wrong direction. It will be the same confusion as we had with   (CONTl) and   (CONTr), but it has to be done ... :( a×pdeHello! 22:54, 22 March 2013 (UTC)
Back in 2010 there already was a try to correct those icons, but this had been reverted the other day :( a×pdeHello! 23:03, 22 March 2013 (UTC)
Well, that is also an option, although a more time- and effort-consuming one. But I don't get it, should ENDE's be swapped as well or not? If not, then the whole thing is not worth it. YLSS (talk) 11:05, 23 March 2013 (UTC)
The   (CONTl) vs.   (CONTr) problem was handled the same way - and I still find railway diagramms with wrong files. But for the sake of a consistent naming scheme we need to go through it ... a×pdeHello! 12:39, 23 March 2013 (UTC)
But I still don't get it... If all   (KBHFl)'s go leftwards (i.e. come from the right) and you have reloaded   (ENDEl) to look the same, why should   (CONTl) go rightwards? YLSS (talk) 15:52, 23 March 2013 (UTC)
Well, it continues to the left! a×pdeHello! 00:35, 24 March 2013 (UTC)

Now that you've re-uploaded two ENDEs, a lot of templates across dozens of Wikipedias should be manually updated, and the same should be done with other ENDEs... Are you going to proceed with this? After all, you chose that option... If CONTs were switched as well, I could've let a hand, but otherwise I don't see the logic of bringing one thing to order but not the other. YLSS (talk) 11:27, 25 March 2013 (UTC)

connects to l/r
  (ENDEl)   (ENDEr)
ex-   (exENDEl)   (exENDEr)
-x   (ENDExl)   (ENDExr)
L-   (LENDEl)   (LENDEr)
exL-   (exLENDEl)   (exLENDEr)
t-   (tENDEl)   (tENDEr)
ext-   (extENDEl)   (extENDEr)
e.g.   (KBHFl)   (KBHFr)
CONTinues to l/r
  (CONTl)   (CONTr)
As you can see most ENDE icons are named consistently now. And as we did with the CONT icons we have to proceed with the ENDE icons, keeping in mind that we want to have them named consistently for that noone has to remember which icon is named wrong or not ... a×pdeHello! 18:42, 25 March 2013 (UTC)

Back to our rams, as we say in Russia. So what, maybe we should indeed swap CONTs as well? I can take a part in this. YLSS (talk) 09:57, 29 March 2013 (UTC)

Is that silent approval?   (CONTl)  (CONTr)? YLSS (talk) 19:06, 1 April 2013 (UTC)
I don't understand. The continuation icons have already been swapped and ok as they are now?! a×pdeHello! 21:45, 1 April 2013 (UTC)
It's based on the nature of the main feature (→). Useddenim (talk) 01:00, 2 April 2013 (UTC)
Yeah, and I don't understand that... But be that as it may. YLSS (talk) 12:47, 2 April 2013 (UTC)
It is also why probably all of us, when routinely creating diagrams, have to fix after previewing whenever CONTs are used, because, inspite of the clever rationale, they are simply backwards, compared with it is empirically expected, in subconscious analogy with BHF and ENDE.
(Also, the fact that this problem doesn’t emmerge for vertical continuation arrows, as there is both "g/f" and "a/e", is one more hint at the fact that "q" as a general quarter turn switch for the whole icon name is the best way to solve so many disparate icon naming problems.)
-- Tuválkin 01:46, 2 April 2013 (UTC)
Pardon, if I understand right you say all have a problem with seeing the BSicons in "direction-of-travel" therefore we have to quarter-turn the icon noone understands? Sorry, but that's unlogical! a×pdeHello! 13:35, 2 April 2013 (UTC)
Yes, people intuitively assume that arrowheads on a given end of an horizontal line   (CONTr) should be labelled the same way as discs   (KBHFr) and tacks   (ENDEr) — that’s what I said above and there’s no need to ask me to repeat it, as I might just do it. Also sorry that you don’t understand what a quarter turn is (just like you don’t understand Commons categorization), but cannot help you more. You are either incredibly stupid or deliberately sabotaging discussion with fake puzzlement, and I don’t want to engage with either of those. (Others please understand that I’m not complaining he doesn’t agree with me, but that he apparently cannot comprehend someone else’s explanation for a different opinion.) As for things that «noone understands», a good example was your mangling of the 45° ABZs, now again unusable without preview check as they may or may no have been afflicted by your addition of a "g" that… «noone understands». -- Tuválkin 14:33, 2 April 2013 (UTC)
Before the icon was turned around was a list of places using it saved? The list now points both to the correct and incorrect use. I saw that a number of articles got updated but there are still more to go. At this time or around the same time a gap started to appear between icons horizontally. Is this related or a separate issue? Maundwiki (talk) 20:05, 23 April 2013 (UTC)

Most regretfully, I still encounter a lot of cases when Axpde has failed to switch the ENDE icons, in nl.wp, fr.wp, ru.wp... And there are also uENDEs, about which nothing has been done even though they are on Bilderkatalog (I guess it gets quite inconsistent), and also other colours... YLSS (talk) 21:17, 30 May 2013 (UTC)

Til Axpde

moved from File talk:BSicon exENDEl.svg

Danish: Hej User:Axpde. Efter at du har spejl vendt billedet den 25. marts 2013 er der gået koks i skabelonerne på en helt masse jernbane artikler på den danske wikipedia. Blandt andet denne Aalborg-Hadsund Jernbane du bedes lige rette problemet. Da vi ingen forstand har på det. :) Vh --Søren1997 (talk // contributions) 19:48, 21 October 2013 (UTC)

Unfortunately, Axpde has updated only a small part of articles that use   (ENDEl) and related. I have encountered broken templates in ru.wp, fr.wp, no.wp and even de.wp. Moreover,   (uENDEl) and similar still show the older convention design. The only remedy is to manually update those RDTs that you notice: just replace ENDEl with ENDEr in code and vice versa. YLSS (talk) 20:37, 21 October 2013 (UTC)
I wouldn't say "only a small part". And there is no "older convention", just people ignoring the convention (which is as old as the BSicons themselves). a×pdeHello! 12:57, 4 November 2013 (UTC)
OK, not a small part, sorry, but still not a small part is left with ENDEs pointing the wrong way, and there is no easy way to find them now; and I'm only speaking about the "bahn" set. YLSS (talk) 13:37, 4 November 2013 (UTC)
Also, what would be your opinion about dropping "l"/"r" for ENDEs and renaming them   (ENDEeq) etc.? You once wrote that you "have general objections to theses icons [  (CONTl),   (STRl)] because of the inflationary use of the suffix 'l'. IMHO "STRl" should show this  "... YLSS (talk) 13:41, 4 November 2013 (UTC)

fq/gq & aq/eq

I guess this business deserves some postfactum remark. Following Axpde's incomplete attempt at swapping ENDEs (but not uENDEs), to which some ancient leftovers of CONT swapping are added, I decided to put an end to this chaos with an iron fist. The pattern is intuitive:   (CONTfq),   (CONTgq),   (ENDEeq),   (ENDEaq). Thus a distinction is preserved between a line that is actually on one side of an object (i.e. the line ends/starts at the object), and a line that continues past an object to some direction. Those files that contain a single design in their history, or those whose current design is the same as the original one, I renamed. Those that differ in their current design from the original file, I marked with {{COM:WPBS/obsolete}} (which places them into Category:Icons for railway descriptions/obsolete), and uploaded a new file with a new name. When all instances are replaced (if ever), original versions should be merged as older versions of my uploads to preserve attribution etc. So I request everybody: if editing an RDT containing either CONTs or ENDEs across, please update them. (I was glad to notice that these new files have already been used by other users in different Wikipedias!) YLSS (talk) 18:06, 13 December 2013 (UTC)

This note (or something similar) should probably be added to the relevant files, too. Useddenim (talk) 02:45, 14 December 2013 (UTC)
I like the way this gordian knot was finally untangled. -- Tuválkin 19:19, 27 December 2013 (UTC)

UPD: Some month ago, I finished up with the bahn-set ENDEs. YLSS (talk) 17:52, 30 September 2014 (UTC)

vHSTl vs. lv-HST

At the moment, the older   (vHSTl legende) is duplicated by newer   (lv-HST). (The latter should be tagged as duplicate later.) The title of the former is quite established (see en:Wikipedia:Route diagram template/BSicon-stations); however, since we're getting rid of "legende", what should the new title be?   (lvHSTl)? Or rather that same   (lv-HST)? For comparison, we have   (lvHSTc1),   (vHSTg legende),   (lBHFl),   (lBHF-L),   (BHFl). YLSS (talk) 19:55, 4 May 2013 (UTC)

The naming of parallel lines is as follows:
vROOT  indicates both lines:   (vSTR)
v-ROOT indicates the left line only:   (v-STR)
vROOT- indicates the right line only:   (vSTR-)
So, your answer is, “Preserve   (lv-HST).” Useddenim (talk) 22:07, 4 May 2013 (UTC)
'Tis just the answer I wanted. But that brings in another question:   (lvHSTc1) or *  (lv-HSTg)??   (lvHSTg) or *  (lHST-)?? And if the latter, then how the hell are we to call   (lvHSTc1)? Or if the former, then unstrike the previous question. YLSS (talk) 22:54, 4 May 2013 (UTC)
Since you raised the point, I now realize that the "v" in   (lvHSTc1) (et al.) is unnecessary, and should more clearly be named simply   (lHSTc1). Useddenim (talk) 12:40, 5 May 2013 (UTC)
(Well, I have no desire to move those 16 once again...) Let's then stick with   (lv-HST). So, what's with   (vHSTg legende)? What do the others think? YLSS (talk) 17:43, 9 May 2013 (UTC)
Answered to this question by myself having moved "vINTg legende" to   (lINT-). The main question for me was to include "q" or not; however, this is only relevant for e.g.   (BRIDGE-) vs.   (BRIDGEq-). For INT's overlay there is no difference, so it may be dropped. So, TBD:   (lHST-). YLSS (talk) 23:52, 24 May 2013 (UTC)
And please remind me, should it be   (exlv-HST) or   (lv-exHST)? Or, since there is only one feature,   (v-exlHST)? YLSS (talk) 17:58, 9 May 2013 (UTC)
  (exlv-HST). u|e|x only appear to the right of "v" when they do not apply to both lines. E.g.   (vuexKBHFa-eBHF). Useddenim (talk) 19:48, 9 May 2013 (UTC)

Ascents & locks

separated to Talk:BSicon/Renaming/Canals


Could someone rename BSIcon ugINT to the correct form? Thanks Deonyi 11:04, 18 June 2013 (UTC)

What does that even mean? -- Tuválkin 12:00, 18 June 2013 (UTC)
I guess he meant that there was capital "I" in "BSIcon". I have also renamed "ug" -> "g" as decided here. So,   (gINT). YLSS (talk) 13:20, 18 June 2013 (UTC)
Ah, I didn’t even noticed that (and I done worse in the past). I was not up to date on the ug/g/ugm kerffukle, so I didn’t change that, either. -- Tuválkin 15:45, 18 June 2013 (UTC)
BTW, Tuválkin, are you really going to re-upload all INT-interchanges? I thought that discussion only concerned the circle radius. The "extended" versions currently use either 52.smth or 50. (I've uploaded a couple using the latter.) YLSS (talk) 14:20, 18 June 2013 (UTC)
replied at Talk:BSicon/Icon geometry and SVG code neatness#INT circle radius.

Assymetric bridge

CONTg CONTg BSicon .svg
uexvSTR+l + kSTRgl
BSicon uexvSTR+l.svg
kBRKuf + uexSTRq-
BSicon kBRKuf.svg
uexSPLe + STRrg
BSicon uexSPLe.svg
kBRKuf + kABZql
BSicon kBRKuf.svg
uexSTRrf + STRlg
BSicon uexSTRrf.svg
(see here with >2 overlay support)

At en:User:Useddenim/Géofer there’s a can of worms including i.a. this apparently misdrawn bridge:   (BRÜCKE3a). At first sight, and based on its name, it maybe thought to be an overlay match for something like   (uexvSTRq-), but it doesn’t look good (→)   BSicon kBRKuf.svgBSicon uexSTRq-.svg (uexSTRq-kBRKuf) (ren.). Its usage(ren.) shows it to be an one-of overlay for   (kABZql), for which it looks good (→)  BSicon kBRKuf.svgBSicon kABZql.svg (kABZqlkBRKuf) (ren.) (it would work well also for  BSicon kBRKuf.svgBSicon kABZqr.svg (kABZqrkBRKuf) (ren.), of course, although for things like BSicon kBRKuf.svgBSicon eABZq+4.svg (eABZq+4kBRKuf) (ren.) it is not so good). Therefore, I suggest it should be redrawn to eliminate the thin white gaps and renamed to something like   (kBRKuf). -- Tuválkin 20:04, 2 July 2013 (UTC)

✓ Done -- Tuválkin 10:30, 4 August 2013 (UTC)

Misnamed bridge

At en:User:Useddenim/Géofer there’s a can of worms including i.a. this unusually named bridge icon   (xevKRZo). Since the double line (witch is supposed to be the main feature of the icon, as it goes vertically and the icon name includes the "v", and rightly so) goes under the simple line across, it should be named with the "u" suffix, not "o". Right? -- Tuválkin 20:27, 2 July 2013 (UTC)

Yes, but… We’re back to the “three lines on an icon” problem, and that can’t be fixed by simply having the prefix letters in the wrong order. Since the parallel lines are asymmetrical, the icon name should actually be parsed line by line (like the station icon below):   (vKRZu-xKRZu) is my suggestion. (But if you check the upload history of the icon, you’ll see that it was originally uploaded as a KRZo but Géofer (talk · contribs) changed it four months later, and his only explanation was the cryptic comment “Bad Icon”!) Useddenim (talk) 23:23, 2 July 2013 (UTC)
Renamed. Useddenim (talk) 01:18, 3 July 2013 (UTC)

Misnamed station

At en:User:Useddenim/Géofer there’s a can of worms including i.a. this unusually named station icon   (vuexKBHFe-BHF). Since it includes both u-blue and bahn-red, the former in the main (right side) position, it should be preffixed with "um", not just "u", right? -- Tuválkin 20:31, 2 July 2013 (UTC)

Um, I’m not sure. Take a look at en:WP:Route diagram template/Catalog of pictograms/parallel stations#Mixed: only   (mvBHF-exBHF) and   (umvexKBHFa-BHF) use the "m" prefix—everything else omits it (possible because the names are so specific). Useddenim (talk) 21:25, 2 July 2013 (UTC)
For that I would suggest   (umvexKBHFe-BHF) :) NoNews! 12:14, 2 August 2013 (UTC)


As I was working on uploading missing icons at w:Wikipedia:Route diagram template/Catalog of pictograms/junctions/crossings I noticed that   (mhKRZhl) seems to be misnamed. If I understand everything correct, it should be   (umhKRZhl), right? As it is currently named, the icon is used in 9 articles on 5 different projects, so I didn't want to just use the move tab at the top. -- Imperator3733 (talk) 06:53, 4 August 2013 (UTC)

✓ Done, but then it struck me that it should be   (umKRZhl) instead, as the main line (vertical) is not elevated itself! :-( It needs rerenaming. -- Tuválkin 10:51, 4 August 2013 (UTC)
✓ Done rerenaming, but there’s a lot of misnamed icons (and redirects) — just check at en:Wikipedia:Route_diagram_template/Catalog_of_pictograms/junctions/crossings#Grade_separated… -- Tuválkin 12:13, 4 August 2013 (UTC)
✓ Done cleaning up the remains (new   (mhKRZhl)). YLSS (talk) 20:13, 16 October 2013 (UTC)

Who deleted so many icons?????

See any page (such as en:Wikipedia:Route diagram template) and you will find there are a great number of icons that can't be shown normally.Who did that?????What happened on earth?????江漢思歸客 (talk) 15:41, 18 September 2013 (UTC)

I'm not seeing any missing icons on that page. Could it be your browser or ISP is blocking images? Vanisaac (talk) 16:35, 18 September 2013 (UTC)


moved to Talk:BSicon/Renaming/Canals#uLJUNC

xv-STRa vs. ev-STRa

After staring for a long while at these tables, I got an impression that we should swap   (xv-STRa)  (ev-STRa), as well as   (uxv-STRa)  (uev-STRa), right? Unless anybody wants to use this opportunity to rename them to something SPLitty. YLSS (talk) 19:37, 28 October 2013 (UTC)

Changing the preffixes so that the “main” line is the straight one? Good idea; I don’t know what I was thinking when I named those. As for SPL instead of STR, I’m all for it — plus, it makes the renaming easier, as no temporary name will be needed, making the whole renaming/relinking process ⅔s faster. -- Tuválkin 17:48, 29 October 2013 (UTC)
Not so that the "main" line is the straight one, but so that the left (IRL right) line is "main", like in   (evSTR) vs.   (xvSTR). Not as straightforward with splits, but staring for a long while at those tables made me realise that. YLSS (talk) 18:21, 29 October 2013 (UTC)
I see. Well, I trust you. :-) -- Tuválkin 01:01, 30 October 2013 (UTC)

Later on: Now it's   (ev-SHI2gr) &   (xv-SHI2gr). YLSS (talk) 21:33, 23 January 2014 (UTC)

Parallel lines across

DSTq- and -DSTq

I just saw   (DSTq-) and   (-DSTq), and was wondering if they should be normalized with   (vDST-) and   (v-DST) as vDSTq- and v-DSTq. Vanisaac (talk) 21:40, 29 October 2013 (UTC)

Nope. It was decided (at Talk:BSicon/Renaming/SPL#Conclusion? or earlier?) that icons for parallel tracks across that have two roots in their names (incl. a root + lacuna) should not have "v", just because it is useless. YLSS (talk) 22:16, 29 October 2013 (UTC)
Ok, so is there a good reason not to have   (vDST-) and   (v-DST) at DST- and -DST? Vanisaac (talk) 23:19, 29 October 2013 (UTC)
We will then have to rename all such icons to names without "v"; if you really want to do this, you may have a go. In contrast, icons with parallel lines across are less abundant, and a good deal of them have already been uploaded (or renamed) without "v". YLSS (talk) 00:45, 30 October 2013 (UTC)
Even simpler, lets ditch that rule and go for a simpler one: That preffix "v" means double lines always, regardless of their being horizontal, vertical, diagonal, curved, whatever. -- Tuválkin 00:51, 30 October 2013 (UTC)
I should say that I always found particularly silly that rule that says you recognize a horizontal double line icon from a vertical one by the absence of the "v" preffix, especially when suffix "q" exists for the same role. The fact that, according to some, "q" (with "v") means horizontal only in specific circonstances and that absence-of-"v" means horizontal only in a different set of specific circonstances makes it all even sillier. -- Tuválkin 00:51, 30 October 2013 (UTC)
I'm against such a move. First of all, there is no necessity in it: omission or inclusion of "v" does not lead to any naming conflict, as far as I can see. Secondly, there is a chance that some names would clash if we either drop "v" everywhere, or add it. In addition, this dual approach provides us with an additional naming pattern that can prove beneficial in comparison to other variants. YLSS (talk) 21:38, 30 October 2013 (UTC)
Yup, I can even provide an example that there should be a difference:   (vSTRl-) vs.   (STRl-) (as it should be named). Or the possible BSicon STRq-.svgBSicon SPLe+r.svg    (ABZq+r-ABZg+r) vs. BSicon v-STR+r.svgBSicon vSTR+r-STR.svg    (vABZq+r-ABZg+r) (leaving aside the matter of applicability of "SPL"). YLSS (talk) 13:27, 4 November 2013 (UTC)

Useddenim, maybe   (DST-DST) (not   (vDSTq)) should be   (DSTq-DSTq)? Or do you propose some other rule? YLSS (talk) 10:28, 4 November 2013 (UTC)

No reply, so renamed it. YLSS (talk) 20:53, 20 November 2013 (UTC)
No reply because I was away on vacation, and just saw your question now. Now the   (vSTRq-) &   (v-STRq) family need to be fixed. (Although, personally I feel that no v + q suffix is redundant.) Useddenim (talk) 02:06, 21 November 2013 (UTC)

Which POV to take?

See also: Talk:BSicon/Renaming/Archive 3#-v as suffix

We currently have a properly named   (tvKRZtq) (parallel tracks across crossing a single vertical), and also an equally properly named   (utKRZtv) (single vertical track crossing parallel across). I don't really think that it is necessary to choose a single way of naming them and get rid of the other. A better solution would be to create permanent redirects from both variations, right?. YLSS (talk) 21:38, 30 October 2013 (UTC)


Please have a look at Talk:BSicon/Renaming/SPL#SPL vs. SHI. YLSS (talk) 09:08, 27 November 2013 (UTC)

lhSTR et al.

What about simplifying the   (lhSTR) prefix+ROOT to ELEV? (As   (ELEVf) etc. were originally uploaded, but this one would now become ELEVaf). Useddenim (talk) 13:51, 29 December 2013 (UTC)

What about   (lhBHF),   (lhPSLm),   (lhLSTR) etc.? I would like to see them consistently named. YLSS (talk) 17:22, 29 December 2013 (UTC)
  (EBHF),   (EPSLm), etc. I.e. ELEV+suffix for basic structures and E prefix for anything else. Useddenim (talk) 17:31, 29 December 2013 (UTC)
Wouldn't it be just easier to stick to the current pattern? With two standard prefixes "l" & "h", no new root modifiers and no complication of "ELEV here, E- there"? After all, lhSTR is just one letter longer than ELEV. And more explicable:   (hSTRef) =>   (lhSTRef). YLSS (talk) 17:48, 29 December 2013 (UTC)
  (EDAMM)LELEV. (And no jokes about Washed-rind cheese.jpg (EDAM) please.) Explicable? maybe; but intuitive? I don’t know. I find it easier to think that ELEVelevated structure rather than (mentally) parse out l legend(e) h high STR stretch. Useddenim (talk) 18:06, 29 December 2013 (UTC)

Redlinked image

Moved from en:Template talk:Shanghai Metro/Line 6

@Circeus, Useddenim: File:BSicon utABZld.svg has been deleted from Commons, leaving a red link in this template and several others. This seems to be connected with a renaming initiative on Commons (User:Circeus/BSicon renaming/Simple junctions). What is the best way to fix these templates? -- John of Reading (talk) 09:55, 18 January 2014 (UTC)

The short-term fix is to recreate the redirect to   (utABZgl+l) (which I have already done). You will have to contact Fastily (the admin who made the deletion) to find out who made the Speedy Deletion request for the file, as the previous history disappeared when the original was deleted. Useddenim (talk) 17:28, 18 January 2014 (UTC)
Actually, that was a lapse of attention on Fastily's side. Sameboat had tagged the file with the wording "this should be made into a redirect to File:BSicon utABZgl+l.svg" (AFAIR). YLSS (talk) 18:07, 18 January 2014 (UTC)
Thank you for sorting this out. -- John of Reading (talk) 21:28, 18 January 2014 (UTC)