Talk:BSicon/Renaming/Archive 4

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
						-- Tuválkin ✉ 09:49, 20 February 2013 (UTC)
						-- Useddenim (talk) 13:43, 21 February 2013 (UTC)
						-- AlgaeGraphix (talk) 02:09, 27 February 2013 (UTC)
						a×pdeHello! 19:58, 27 February 2013 (UTC)
						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" ... axp_de^Hello! 00:32, 4 June 2011 (UTC)

I love the idea of a substitute for _GRENZE _LEGENDE^{Oops, 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! axp_de^Hello! 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:! axp_de^Hello! 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. axp_de^Hello! 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. axp_de^Hello! 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×p_de^Hello! 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×p_de^Hello! 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×p_de^Hello! 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×p_de^Hello! 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×p_de^Hello! 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×p_de^Hello! 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×p_de^Hello! 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		KRZo		AKRZo
K	Terminal station (Kopfbahnhof)		BHF		KBHFa
L	Interruption (Lücke)		STRlf		LSTRlf
MW	Motorway		STR	File:BSicon MWSTR.svg	MWSTR
S	Suburban/commuter (S-Bahn) station		BHF		SBHF
T	split-level station (Turmbahnhof)		BHF		TBHF
W	Water/Wasser		BRÜCKE		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×p_de^Hello! 21:57, 4 July 2011 (UTC)

FOOR FOORq FOOL FOOLq FOO FOOq

FOOR FOORq FOOL FOOLq

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×p_de^Hello! 10:41, 5 July 2011 (UTC)

Legend uBHFll BHFlr ¦ BHFll BHFrf BHFlf BHFrg BHFlg uBHFrr 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.)

but...

descriptions are still referenced from top-to-bottom travel (↓).

Legend FOOR FOO+Rq or FOO-Lq FOOL 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)

Legend uBHFll BHFRl ¦ BHFLl BHFRf BHFLf BHFRg BHFLg uBHFrr BHFRr ¦ BHFLr

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×p_de^Hello! 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		DBK	} the swing bridge is the main point of interest
uxmKRZqusw		xDBK
umKRZusw		DBKq	swing bridge runs across

Regards a×p_de^Hello! 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		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×p_de^Hello! 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 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×p_de^Hello! 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×p_de^Hello! 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×p_de^Hello! 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×p_de^Hello! 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×p_de^Hello! 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×p_de^Hello! 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×p_de^Hello! 12:09, 18 March 2013 (UTC)

Summits

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)

BHFCC & BHF+TUNNEL

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)

Station type	Tunnel mouth	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)    (exKBHFCCe)  (KDSTCCe)    (exKDSTCCe)	(uKBHFCCe)  (uexKDSTCCa)	(tKBHFCCe)	(utKBHFCCe)
	At end	(KBHFCCa)    (exKBHFCCa)  (KDSTCCa)    (exKDSTCCa)	(uKBHFCCa)  (uexKDSTCCa)	(tKBHFCCa)	(utKBHFCCa)
transition	At start		(utBHFa)	—
	At end		(utBHFe)
Across
regular	At start	(BHFCCqa)	(uBHFCCqa)	(tBHFCCqa)	(utBHFCCqa)
	At both	(BHFCCq)	(uBHFCCq)	(tBHFCCq)	(utBHFCCq)
	At end	(BHFCCqe)	(uBHFCCqe)	(tBHFCCqe)	(utBHFCCqe)
terminal	At start	(KBHFCCqe)     (exKBHFCCqe)   (KDSTCCqe)     (exKDSTCCqe)	(uKBHFCCqe)
	At end	(KBHFCCqa)     (exKBHFCCqa)   (KDSTCCqa)     (exKDSTCCqa)	(uKBHFCCqa)
transition	At start		(utBHFl)	—
	At end		(utBHFr)

 (utBHFa) and  (utBHFe) should be redrawn as   and  . (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)

Offtopic veer: click to open

Renaming

Working independently, me and YLSS took care of the two renamings suggested above by Useddenim. Please compare:

• Special:GlobalUsage/BSicon_BHF+TUNNELe.svg, moved by me, with zero instances of (relevant) global usage
• Special:GlobalUsage/BSicon_BHF+TUNNELa.svg, moved by YLSS, with five instances of (relevant) global usage: The route diagrams for nl:Lijn C (metro van Lyon), en:Kwun Tong Line, ko:수도권 전철 1호선, no:Västra stambanan, and zh:新加坡地铁南北线 are, as I type, distorded and made unreadable as they point to a meanwhile renamed image file.

Can we please fix global usage IMMEDIATELTY after a moving/renaming is done? Thank you. -- Tuválkin ✉ 13:35, 24 February 2013 (UTC)

No we can't, unfortunately. Files are not moved immediately after they are tagged, and personally, I can't just sit and wait for them to be moved. Sometimes a day may pass. But in my opinion, there is no hurry here: most articles are not high-traffic. YLSS (talk) 15:33, 24 February 2013 (UTC)

I see there’s a misunderstanding here, then. The fact is that I was able to rename BSicon_BHF+TUNNELe.svg and leave no article pointing to it (thus no damaged diagrams), while you renamed BSicon_BHF+TUNNELa.svg and five articles started showing mseed up diagrams. If I can do it, so can you. It is hard work, but there’s no other way. -- Tuválkin ✉ 16:28, 24 February 2013 (UTC)

Aaaarrgh! I know what’s up! I have file mover rights and YLSS doesn’t (not yet, at least). That means that when I move/rename a file it gets renammed immediately, while he can only flag a file to be renamed, whenever an admin notices. I’m sorry for this misunderstanding, and for my harsh words! :-( -- Tuválkin ✉ 16:35, 24 February 2013 (UTC)

v! icons

Moved from User talk:Tuvalkin.

Moved to Talk:BSicon/Renaming/SPL#v!_icons.

Roads

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:

File:BSicon [email protected]

File:BSicon [email protected]

File:BSicon xKBFlg.svg

File:BSicon [email protected]

File:BSicon [email protected]

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×p_de^Hallo! 23:43, 15. Mär. 2013 (CET)