Talk:BSicon/New icons and icon requests/Archive 4

Continuation on curves

File:BSicon uCONTfl.svg uCONTfl	File:BSicon uexCONTfl.svg uexCONTfl	File:BSicon uexCONTfl !.svg uexCONTfl_!	uexCONTfl!
uCONTfl!	uCONTfl_!	ABZ-type w/ new arrow

WRT recent uploads by Vanisaac, e.g.  (CONTfr),   (uCONTgl),   (fCONTrg) (category):

1. Although a consistent naming scheme within this separate class is evident, I'm uneasy with its correlation to the established ones:   (CONTlg) &   (CONTgl) vs.  (STRlg)... I would rather have STR → CONT, e.g.  (STRrf) →  (CONTrf) &  (STRrg) →   (CONTrg), with "q" used for rotating 90° to get the other direction:  (CONTrf) →   (CONTrfq or CONTqrf).
2. What about an alternative design to the right? (File:BSicon uexCONTfl.svg) So that the geometry is consistent with other CONT's.

-- YLSS (talk) 10:12, 24 August 2013 (UTC)

1. Yeah, I tried to adapt the STR nomenclature but got nowhere. Ok, I'll freely admit that those names don't make a lick of sense to me in the first place. So I just treated them like a combination of existing continuation arrows, eg  (CONTl) +  (CONTg) =   (CONTlg). "q" codes might be a way around it, but I think it might be horribly confusing, especially since the ostensible goal of matching the STR turns would be lost.
2. I'd prefer to see something closer to the 90 degree turn than your redesign, and there is some room for a larger arrowhead in the existing design. I do agree that the heftier arrow does show a bit better at rdt size. Vanisaac (talk) 11:44, 24 August 2013 (UTC)

1. Yeah, "q" is always confusing (or rather requiring brain-work), but as yet I haven't seen no other solution for the inherent problems of direction-of-travel paradigm. And it's gradually becoming more universal. Another scheme that I can come up with is to use the more "modern" "r/l/+r/+l" suffixes, and to prepend them with "f" or "g" for forward/backward arrow. Like this:  (CONTfr),   (CONTgr),   (CONTf+r),   (CONTg+l) etc.
2. How about the second variant (File:BSicon uexCONTfl !.svg)? YLSS (talk) 14:27, 24 August 2013 (UTC)

File:BSicon uCONTfl.svgFile:BSicon uexCONTfl.svgFile:BSicon uexCONTfl !.svg

I've re-built all of the files to match the second alternate File:BSicon uexCONTfl !.svg and uploaded them, but I'm a bit concerned at how crowded the arrow is. Check them out in the diagram, below left, and let me know. In the mean time, I've included another alternate, above, and we'll maybe see how it looks. Vanisaac (talk) 10:44, 26 August 2013 (UTC)

When placed on top of STR, the thinner variant is certainly superior, so if anybody uploads ABZs with arrows (no idea how to elegantly name them), it would be better to use that design. In case of plain curves, both are more or less OK to me (although both have deficiencies). YLSS (talk) 13:22, 26 August 2013 (UTC)

Your new design () is even better: the golden mean. YLSS (talk) 19:53, 27 August 2013 (UTC)

I was trying to keep the "heft" of the continuation arrows, but shortened the point to give room for the curve to actually show when overlapping a straight. I've also mocked up an ABZ-type with the new arrowhead, and I've added it to the diagram to see how it looks at 20px, but I don't know. Maybe it's folly trying to design for the unexpected. Vanisaac (talk) 22:56, 27 August 2013 (UTC)

I think the comparison should be made with ABZ, not STR:

(ABZgr)	(ABZgl)	(ABZg+l)	(ABZg+r)	(ABZqr)	(ABZql)	(ABZq+r)	(ABZq+l)
(CONTfr)	(CONTfl)	(CONTgl)	(CONTgr)	(CONTlg)	(CONTrg)	(CONTlf)	(CONTrf)

Useddenim (talk) 16:12, 24 August 2013 (UTC)

Heh, ABZs as you listed them combine the "deprecated" pattern (lf, rg) and the modern one (l, +l). I alt'ed them to be consistent (I hope you don't mind); and yes, with g's, since in any case  (CONTl) is occupied. YLSS (talk) 16:31, 24 August 2013 (UTC)

I'm good with your fix, but there is another question that hasn't been addressed yet, namely: Are these new icons needed? Useddenim (talk) 20:40, 24 August 2013 (UTC)

Legend Single column diverging line, using O1= Double column diverging line not suggesting connection to above ABZ-type Optional arrowhead designs

I can't speak to necessity, and I'd be pretty hard pressed for the vast majority of BSicons on that basis anyway. All I can speak to is the design impetus - namely indicating a diverging line without adding an extra column to the width (See rdt at right) Vanisaac (talk) 22:21, 24 August 2013 (UTC)

Well, that one is certainly better than "the German way", i.e. ABZs without any arrows, IMHO ;) YLSS (talk) 23:40, 24 August 2013 (UTC)

I didn't think about this when I came up with the names, but I could see someone making ABZ-style extensions, and the question is whether the names would hold up for that. What do you think about changing these to "base icon"+CONT. So  (STRrf) +  (CONTr) =  (STRrf+CONTr). You could then have ABZ-type arrow icons, like ABZlg+CONTr for the icon in the second row of the table, with ABZlg+CONTf and ABZlg+CONTg for arrows in the other directions, and maybe even ABZlg+CONTrg / ABZlg+CONTgr with multiple arrows. Vanisaac (talk) 00:54, 25 August 2013 (UTC)

Unnecessary. Overlays work just fine, and the extra variations (one or the other of the two branches out of use) would just add even more icons. Let's just keep them as CONTs and work out a rational scheme for the suffixes. Useddenim (talk) 02:23, 25 August 2013 (UTC)

And maybe that's true right now. I know that I don't want to expand beyond single arrows, but I'm not prepared to make an unequivocal statement about future need. For example, a  (uABZld) built out of  (uSTR),   (uCONTgl), and   (uCONTfl) might be too crowded with larger arrowheads. We have a class of lCONT arrowheads with a naming scheme that gives us something to start with and extend to other curves. So the question is how would you take the pre-existing icon nomenclature and adapt it to something new; 'cause that's our opportunity here. Which would this be if we wanted to be both transparent to editors and accommodate future expansion?  (CONTfr),  (CONTrf),  (STRrf+CONTr),  (STRrf^r), or  (something else)? Vanisaac (talk) 06:59, 25 August 2013 (UTC)

I've got it figured out!

(CONTr)  (CONTr+g)   (CONTr+f)

(CONTl)  (CONTl+g)   (CONTl+f)  (CONTl+4)

(CONTf)   (CONTf+r)   (CONTf+l)

(CONTg)   (CONTg+r)   (CONTg+l)

Useddenim (talk) 00:05, 27 August 2013 (UTC)

Can I ask what the semantics of the "+" are supposed to be? Pretty much all of them look backwards to me (CONTr+g looks like it should be CONTr+f, and vice-versa). Vanisaac (talk) 06:18, 27 August 2013 (UTC)

"+" usually means "out of", and so it does in Useddenim's proposal AFAIU, if "f" and "g" are taken to mean top and bottom of the icon, right? However, I still have the same uneasiness with it in that this way of thinking produces different results from the more or less established patterns:   (CONTg+r) vs.  (STR+r). "f" & "g" have already been used with CONTs to mean "forward " & "backward" direction (as indeed they are supposed to mean, Fahrtrichtung und Gegenrichtung), namely in  (uCONTf) +  (uCONTfa) etc. Indeed, "CONT+ABZ" is another instance where there is a potential clash of "g" = Gegenrichtung and "g" = geradeaus. Maybe we should indeed employ some other suffixes to mean directions? YLSS (talk) 07:31, 27 August 2013 (UTC)

↓ = f (forward/Fahrtrichtung), and ↑ = b for backward, or z for (de) zurück (or simply "last")? Is  (CONTl+4) any clearer? Useddenim (talk) 11:58, 27 August 2013 (UTC)

Aaaargh, you're blowing my mind! Please have a pity on me! Yet another well-established BSscheme, when both points are stated explicitly. BTW, in this case there is even no need for direction suffix: it's either "l+4" or "4+l". I give up. It's impossible to have these curved arrows named coherently unless we rename all the BSicons coherently. P.S. We should also find a way to name this one: File:BSicon ulCONT1f.svgFile:BSicon v-STRq.svg . YLSS (talk) 19:56, 27 August 2013 (UTC)

What's the problem?  (CONTl+4);  (CONT4+l). You know well enough that the name parses out as [ROOT]·[to]·[from]. We don't need to rename everything (but you're welcome to try) as long as each group is internally consistent. And your wild and wonderful doesn't need naming beyond {{bso|l-CONTffq|v-STRq|ulCONT1f|uvSTR+1-}}. Useddenim (talk) 00:30, 28 August 2013 (UTC)

So how would you name this ? Vanisaac (talk) 03:59, 28 August 2013 (UTC)

 (uCONTl+fg): underground CONT to left from forward & backward. Useddenim (talk) 12:15, 28 August 2013 (UTC)

The "g" question: how would you then differentiate  (*uCONTl+fg) from File:BSicon uCONTfl.svgFile:BSicon uCONTgl.svg ? YLSS (talk) 16:11, 28 August 2013 (UTC)

See below Vanisaac (talk)

So, I'm looking for actual feedback here, because I'm still a little confused. Why is this not right?

(CONTr)  (CONTr+f)   (CONTr+g)

(CONTl)  (CONTl+f)   (CONTl+g)  (CONTl+4)

(CONTf)   (CONTf+l)   (CONTf+r)

(CONTg)   (CONTg+l)   (CONTg+r)

Vanisaac (talk) 08:28, 28 August 2013 (UTC)

Because the "natural" direction is as a hypothetical train moves down the page from top to bottom. Take  (CONTl+4) as an example: it breaks down as CONTinuation icon, pointing to the left, coming from (+) corner 4. Got it now? Useddenim (talk) 12:15, 28 August 2013 (UTC)

You described the one example I didn't alter since it already makes sense; I want to know about all the others. Your system seems to indicate the exact opposite side it's actually "from". Vanisaac (talk) 12:37, 28 August 2013 (UTC)

4	g	1
r	✳	l
3	f	2

These are the cardinal and ordinal points used for BSicons:
The accepted naming of CONT icons is that the suffix indicates the direction the arrowhead is pointing. Also accepted (originally for STR curves going in odd directions, but since expanded to ABZ and other groups) is that the + symbol followed by a letter or number indicates where the line is coming from. Because directionality is not only implied but explicit with CONTs, the normal top-to-bottom convention is superseded. Perhaps this table is clearer?

Ok, that's a lot clearer. The problem I was having - and a persistent problem I see with this scheme - is that it breaks the semantics of fahrtrichtung and gegenrichtung. Vanisaac (talk) 03:26, 29 August 2013 (UTC)

(CONTr)  (CONTr+g)   (CONTr+f)

(CONTl)  (CONTl+g)   (CONTl+f)

(CONTf)   (CONTf+r)   (CONTf+l)

(CONTg)   (CONTg+r)   (CONTg+l)

(KRWr)  (KRW+r)  (KRWl)  (KRW+l)

(KRWgr)  (KRWg+r)  (KRWgl)  (KRWg+l)

I would also suggest reading Talk:BSicon/Renaming and its archives. Useddenim (talk) 22:59, 28 August 2013 (UTC)

Formalizing proposal

Which goes back to my earlier thought. What's wrong with  (uABZld^l) and File:BSicon uCONTfl.svgFile:BSicon uCONTgl.svg  (uABZl+l^l)? Just have the standard icon name, suffixed with a caret, and the arrow directions, in a set pattern, maybe f g l r 1 2 3 4, so   (ABZlf^fl) and  (KRZ^gr). Parallel lines would be f g l r -f- -g- -l- -r- and the order would resolve ambiguity; so r-l has the top left and both right arrows, l-r has both left arrows and the bottom right, rl- has bottom left and both right, and lr- has both left and top right. CONT would be reserved for half-length,center-terminating continuation arrows, and lCONT for bare arrowheads. Vanisaac (talk) 22:45, 28 August 2013 (UTC)

(STRrf)  (STRrfVr)   (STRrfVg)

(STRlf)  (STRlfVl)   (STRlfVg)  (STRl+4Vl)  (STRl+4V4)

(STRrg)   (STRrgVl)   (STRrgVf)

(STRlg)   (STRlgVr)   (STRlgVf)

* edited to use "V" as arrow suffix.

(STRrf)  (STRrfW)   (STRrfN)

(STRlf)  (STRlfE)   (STRlfN)  (STRl+4E)  (STRl+4Nw)

(STRrg)   (STRrgE)   (STRrgS)

(STRlg)   (STRlgW)   (STRlgS)

* alternate using compass points.

For one thing, they're NOT  (STR)! ( (STRf),  (uSTRg) etc are used for lines with a superimposed direction.) Useddenim (talk) 22:59, 28 August 2013 (UTC)

Well, that would be a problem with the names of  (STRrf),  (STRlf),  (STRrg), and  (STRlg), not the arrow scheme. None of the above codes conflict with either  (STRf) or  (uSTRg), so I'm not sure what your actual objection is. "STR" is an abbreviation of "Strecke" which means "route, road, track, distance, line, section, stretch, reach, way, run" and has nothing to do with "straight", despite the English mnemonic. Vanisaac (talk) 04:58, 29 August 2013 (UTC)

Wikipedia:Article titles#Special characters discourages the use of "Characters resembling quotes or accent marks". 128.205.248.219 20:25, 30 August 2013 (UTC)

A) it's not an article title. B) that page lists ʻ ʾ ʿ ᾿ ῾ ‘ ’ “ ” ^c and combining diacritical marks over a space character - none of which include a caret. C) you could use any character - the caret just seemed the most arrow-like. Vanisaac (talk) 21:44, 30 August 2013 (UTC)

I think you're deliberately ignoring the point 128.205.248.219 is making. And if you want to get technical, Commons:File naming states that one should “Avoid "funny" symbols (control characters, unneeded punctuation, etc.) that might be significant in future wiki markup.” It continues, “It is a good idea to stick to graphemic characters, numbers, underscore (space), ASCII hyphen/minus/dash, plus, and period (dot).” and uses this definition of graphemes: “A fundamental unit of a writing system corresponding to letters in the English alphabet.” (My emphasis added.) Except for the use of ! in experimental files, AFAIK all BSicon names conform to the preceding standard. Useddenim (talk) 22:10, 30 August 2013 (UTC)

BTW, ˆ is used as a diacritical mark in French. Useddenim (talk) 22:14, 30 August 2013 (UTC)

No, I read the en.wiki policy and legitimately thought the IP was, although commenting in good faith, distinctly mistaken in the applicability of the cited policy. And while the haĉek / circumflex shape (erroneously called a "caret" in ASCII / ISO 8859 standards, and the derived Unicode code charts) is used as a diacritic in many languages, the "combining diacritical marks" of the policy are a actually the range of Unicode characters (general category = Mc - mark, combining) in the ranges U+0300..U+036F, U+1DC0..U+1DFF, U+20D0..U+20FF and U+FE20..U+FE2F. I do, however, take your point about conflicting with possible future wikimarkup as being a compelling reason to opt against operator/punctuation characters in icon names.

What I am distinctly disappointed in is that every comment so far has persistently ignored the actual idea that arrow icons are going to be easiest to use, and most useful and applicable to any future-made icon if they are named as a combination of standard icon names, followed by a suffix indicating the location and direction of superimposed arrows. Like I said, there is nothing special about the caret, it just looks kind of like an arrow, so it's nice mnemonically, but it is otherwise just a random way of indicating arrow codes follow. If it would make things easier, we could use + N S E W Ne Se Sw Nw –N- -S- -E- -W-, or use ARR + f g l r -f- -g- -l- -r-, or V (another nice arrow shape) + f g l r -f- -g- -l- -r-. The idea still remains the same, stick a suffix on the regular icon name to indicate added arrowheads. Vanisaac (talk) 00:13, 31 August 2013 (UTC)

"Docks"

Please comment at Talk:BSicon/Renaming/Canals#"Docks". (Just in case not everybody has it in watchlist.) YLSS (talk) 17:02, 15 October 2013 (UTC)

"Background"

Category:Icons for railway descriptions/background. 500 × 1,500. Well, since it is labelled "testing", let's wait. YLSS (talk) 10:20, 17 October 2013 (UTC)

One Two Three more copycats (or great minds think alike)

moved to Talk:BSicon

FADE

split from Talk:BSicon/Icon geometry and SVG code neatness#Tunnellücken

Back to the topic, here's my suggestion to the new design of LUECKE with opacity gradient:   (sameboat001). This is actually an obsoleted design for CONT set. Unlike the current LUECKE. It requires f/g/r/l/1/2/3/4 suffix to indicate the direction the tracks face toward. -- Sameboat - 同舟 (talk) 05:58, 14 December 2013 (UTC)

I like that design! I always wondered why  (FADEq) remains unused. If this idea is established, we should choose what to use: "f"/"g" or "e"/"a". BUT: that thing is suitable for branchings, continuations etc., that is, Lücken used in the French way. However, the original idea of interruptions is a part of a line that is not presented with due elaboration; and such fading icons are not suitable for a longer stretch of Lücke that eventually reconnects to a normal line. YLSS (talk) 10:19, 14 December 2013 (UTC)

Check  (MFADEf),  (MFADEg),  (MFADEfq),  (MFADEgq). I tested them at ru:Шаблон:Шаля — Екатеринбург, both with red lines at the top & the bottom, and with green tunnel lines at the bottom (unless this will be removed by conservative rupedians). YLSS (talk) 12:27, 17 December 2013 (UTC)

I used mask in my opacity gradient sample in case of changing background color, but I admit this is the easiest option to achieve fading effect. -- Sameboat - 同舟 (talk) 13:21, 17 December 2013 (UTC)

Certainly non-masked icons for basic colours need to be uploaded if the idea is given a go. I only uploaded masks so as not to create such icons for every possible colour (I needed an f-green in a diagram). BTW, initial response at ru.wp seems to be positive. YLSS (talk) 15:04, 17 December 2013 (UTC)

Ah...I think you mistook me. I mean the masking of SVG which only allows the "masked" area to be painted. For Шаблон:Шаля — Екатеринбург, I think the original arrow CONT is sufficient. en:Template:North London Line is one of the maps that actually justifies both fading LUECKE and arrow CONT because the middle interrupted sections are too long to be connected by the dotted LUECKE. Anyway, I think we can and should develop the FADE set instead of changing the current dotted LUECKE. -- Sameboat - 同舟 (talk) 01:23, 18 December 2013 (UTC)

Need your expert help again regarding rail pictograms

Moved from en:User talk:Sameboat

Hello sameboat, Would you please help me with some pictograms for conceptual route map designs of Riverline?
I need this pictogram as well as this one as svg format. Can you be of assistance?
If so, I will also require a twin platform station to go in between these two pictograms. Left side: heavy rail (red) in use but station platform not in use. Right: Light Rail (blue), line not in use or platform (light blue)

I think I may of found it.... unless there are alternatives I'm missing? Wiki ian 09:17, 17 February 2014 (UTC)

I don't blame you for not being a participant of the BSicon project. You can have the png images under your own temporary user category, but adding BSicon category to png files will make someone else furious. I ask YLSS to help you because he knows better of BSicon naming rules. -- Sameboat - 同舟 (talk) 11:16, 17 February 2014 (UTC)

 (xmSPLa). Useddenim (talk) 12:17, 17 February 2014 (UTC)

 (vSHI1+l-uexSHI1+r) &   (vSHI1l-uexSHI1r). I usually try not to touch those multi-coloured icons, because their naming is far from being settled, and just because I don't like like them. But I already thought once about uploading one of such splits, so here you are. PS. Wiki ian, if you don't have a needed icon, you can usually employ overlaying. In this case, just type uexv-SHI1+r|O1=vSHI1+l- to place  (vSHI1+l-) on top of  (uexv-SHI1+r). (Aargh, Useddenim, what are you doing?! Whose icon is up to deletion now?) YLSS (talk) 12:51, 17 February 2014 (UTC)

Well, we already have   (mvSTRe) uploaded 25 May 2011 and   (umvSTRe) from 2013-02-10 (both of which should actually be renamed as vSPLes), and I beat you to the punch. Useddenim (talk) 19:14, 17 February 2014 (UTC)

Verily you do ;) But that's because I was trying – as usually! – to understand what an amalgam of prefixes should be used for such an icon. 1) I would like to see it  (muxSPLa), because there are both red and blue colours (recollecting the unfinished discussion at Talk:BSicon/Colors). 2) Some icons use the dazzling "uxm" order; so should it be "mux" or "mxu" here?! 3) "x" is used for parallel lines when the main line is out of use, that is the left one; but "m(u)" vs. "um" is used for parallel lines when the left line is red – not the main line! So should it be "mux" or "umx"?! To summarise: <screaming in fear> aaah! Please don't make me do that! Really,  (vSHI1+l-uexSHI1+r) is more straightforward, even if longer... YLSS (talk) 19:49, 17 February 2014 (UTC)

I forgot about the mixed parallels. I just simply stuck the “m” prefix onto  (xSPLa). Perhaps we should be considering something like

(SPLa)	(SPLaxr)	(SPLaxl)	(exSPLa)
(SPLe)	(SPLexr)	(SPLexl)	(exSPLe)
similar to
(KRWlr)	(KRWlxr)	(KRWrxl)	(exKRWlr)

Useddenim (talk) 22:45, 17 February 2014 (UTC)

Mheh... Didn't I suggest from the start that we use "SHI1lr" instead of "SPLa"? That would have been similar to KRW. For SPLs, such "l"/"r" suffixes are misleading:  (SPLar) ><  (SPLaxr).

That said, is SHI1uxlr a possible name for  (vSHI1+l-uexSHI1+r)? YLSS (talk) 14:23, 21 February 2014 (UTC)

Useddenim, I don't understand your actions, and I'm totally against your moving   (vSHI1l-uexSHI1r) to that "xmSPLe"! First of all, why "xm"??? Color prefixes go first: "ux", not "xu"! And secondly, it would be better to call it "muxSPLe", or maybe even "umxSPLe"! I would have reverted your move if there was such a possibility... YLSS (talk) 14:23, 21 February 2014 (UTC)

I have to agree that interpreting a SPL as vSHI-SHI (or SHI+SHI), while possible and formally correct, is in most cases an unnecessary cluttering of the icon name. In this case, any variation of mSPLa seems to be the simplest approach. -- Tuválkin ✉ 23:20, 21 February 2014 (UTC)

Which one? That's the question. YLSS (talk) 23:41, 21 February 2014 (UTC)

See en:Wikipedia » Route diagram template » Catalog of pictograms » junctions » 2-way » Mixed for an existing (accepted) group. Useddenim (talk) 00:08, 22 February 2014 (UTC)

I know of it (even though I'm not happy with it), but you linked to non-parallel mixed icons. For them, the "main" track is the same both for "ex"ness and for "(u)m"ness:  (ABZlf) →  (eABZlf),  (ABZlf) →  (mABZlf). But what we have here?  (SPLe) →  (eSPLe) but not  (SPLe) →  (mSPLe).

Secondly, at Talk:BSicon/Colors#g-Green, we more or less agreed that two colour prefixes are better than a single "m", and what now?

Lastly, most other icons at Category:Icons for railway descriptions/set mixed/parallel railways have been moved from e.g. mvSTR to  (vSTR-uSTR). Why do you two stick with SPLs??

And also an interesting historical excursion. In July 2012, Tuválkin proposed and Useddenim implemented moving i.a.  (vBHF-uexKBHFa) to mvBHF-exKBHFa. Afterwards, "base color indicator "u" in the middle of the name" became more common, and in July 2013, Tuválkin proposed renaming  (vuexKBHFe-BHF), but Useddenim checked him, because the only icons that used the "m" prefix were those that he/they had moved to those titles previously. And only recently, I have renamed some of those station to their original titles, and presented them in a neat and useful table, for which Useddenim even thanked me. I fail to understand the logic now...

-- YLSS (talk) 08:47, 22 February 2014 (UTC)

If I recall correctly, the thinking back then was that there were too many variables involved with parallel stations (lines: in & out, used & unused, metro & heavy rail; and type: BHF, DST, INT, ACC) to try and develop any simplifying shortcuts, but that the ABZ icons with their two lines and two colours were OK with the m/um shorthand applied to the underlying –/e/x/ex states. And the renaming of xmSPLa was to make it fit into catalog tables. (BTW, did you see the new template {{en:WP:RDT/BSa6x}}?) Useddenim (talk) 18:49, 23 February 2014 (UTC)

Yes, I saw it, a good one. And yet another proof (though we both know that already) that catalogue pages can be generated for any series of icons with names of any complexity, they just need some rules of naming.   (vSHI1l-uexSHI1r) and similar can easily be presented with {{en:WP:RDT/BSa4x2m}}; umxSPLe vs. muxSPLe would require creating a new such template (not that that's a reason against choosing such a scheme). YLSS (talk) 20:12, 23 February 2014 (UTC)

Thankyou, could you help some more?

See also: Category:Icons for railway descriptions/legende.

Thankyou very much for the help :-) I have another problem - I dare say this is a good question. When applying train stopping types in route maps, I can designate passenger or freight stations. And yet, when using the rint template (or incorporating directly into the map), there are only passenger-related connections (bus, ferry) to choose from. does it not make sense to have a cargo ship and a truck pictogram? or do they already exist and I'm not looking in the right place? I hope I didn't cause a fight about naming guidelines :-( Wiki ian 14:34, 21 February 2014 (UTC)

I’m sorry, but I have no idea what are you talking about. What is the {{Rint}} template? -- Tuválkin ✉ 23:20, 21 February 2014 (UTC)

implies land-only connection (i.e. road) implies a harbour

@Wiki ian: No-one’s ever asked for them.
@Tuvalkin: {{Rail-interchange}} at en:WP:Template:Rail-interchange. Useddenim (talk) 00:08, 22 February 2014 (UTC)

Upon further thought, see the sample diagram to the right. IMHO, there’s no need for the interchange icons you suggest. Useddenim (talk) 00:24, 22 February 2014 (UTC)

A few more

Looking to get   (hKRZh3+1) and   (hKRZh2+4).

Do you mean  (hKRZ3+1h) and  (hKRZ2+4h)? Useddenim (talk) 22:53, 5 March 2014 (UTC)

YES! Lost on Belmont (talk) 13:51, 7 March 2014 (UTC)

And since I'm here, is there an icon to represent a rail yard? Thanks in advance. Lost on Belmont (talk) 05:28, 26 February 2014 (UTC)

Uhm, what do you mean precisely? There are   (hKRZ3+1o) &  (hKRZ3+1ho). YLSS (talk) 05:38, 26 February 2014 (UTC)

Ah. I still haven't got the conventions of these things down yet. (Looks like I need a second h in there someplace...) I'm looking for this  (hKRZh) kind of crossing, but at these angles:  (KRZ3+1) and  (KRZ2+4). Lost on Belmont (talk) 13:19, 26 February 2014 (UTC)

Hmmm... You know, I've tried creating them, but here's the thing. All "elevatedness" in the top-right and bottom-left quarters (as viewed) degrades into two tiny spots, while the formations in the top-left and bottom-right quarters can be drawn either with a straight junction or as a curved line; which one is better? If the latter, you can get it straight away: File:BSicon lhSTR-L+1.svgFile:BSicon lhSTR-R3.svg (KRZ3+1※ lhSTR-R3※ lhSTR-L+1)  & File:BSicon lhSTR-L2.svgFile:BSicon lhSTR-R+4.svg (KRZ2+4※ lhSTR-R+4※ lhSTR-L2) . YLSS (talk) 14:59, 26 February 2014 (UTC)

And I suppose you will also need these in adjacent cells:   (lhSTR-R+c4),   (lhSTR-R+c3),   (lhSTR-L+c2) &   (lhSTR-L+c1). YLSS (talk) 15:55, 26 February 2014 (UTC)

That should work just fine. Thanks! Lost on Belmont (talk) 23:38, 26 February 2014 (UTC)

 (uPSL※ unSTR)  if you don’t want to use  (uDST). Useddenim (talk) 12:14, 26 February 2014 (UTC)

Thanks. Lost on Belmont (talk) 13:19, 26 February 2014 (UTC)

And a few more...  (uexhBS2c1),   (uexhBS2+lr),  (uexhBS2c4), and   (uexhBS2lr). I tried playing around with formation overlays, but proper ones for this application don't exist (or I wasn't diligent enough in hunting them down). Or perhaps I can just get the formation pieces for greater applicability via overlays since there seem to be virtually no elevated pieces for column shifts. Lost on Belmont (talk) 14:17, 1 March 2014 (UTC)

 Done. It appears that there had been only 1½ attempts to create elevated column shifts before. YLSS (talk) 11:43, 4 March 2014 (UTC)

Also looking to get these two:  (hKRZ2+4ho) and  (uhKRZ2+4ho). Lost on Belmont (talk) 14:17, 1 March 2014 (UTC)

 Done. YLSS (talk) 10:08, 4 March 2014 (UTC)

(As a philosophical note...) It's quite interesting to note that   (lhSTR-L2) and   (lhBS2c1) look very similar, and quite sad to note that they are different enough to justify creation of both. If elevated formations were placed not 130px away from the center of the track, but 125px, it would be possible to re-use many of them for parallel tracks etc. Currently,  (lhSTR-L※ STR-R)  look just a bit crooked if paired with  (hSTR) in the adjacent row. YLSS (talk) 11:54, 4 March 2014 (UTC)

Laflin Marshfield

Thanks for the above. Unfortunately I'm beginning to notice all sorts of quirks like that. (Something else I really don't get is why certain bits of this page are being archived after being up for less than a month while others are still here from three years ago...) In fact, both of the formation icons look like they could possibly work for the situation at right, but in fact neither does.

To finish out this project I'd like to either get the elevated branchings for  (uexSHI2gl) and its mirrors/whatnot or the remaining formation pieces that aren't in the diagram. Lost on Belmont (talk) 19:49, 5 March 2014 (UTC)

I archived those where everything seems to have been done, and left those where something is still to be done, or where I have thoughts about yet something more that can be done. Do you need a sharp-pointed junction of elevated sidings at that place or maybe a curved one? (Commons still does not support more than one level of overlaying.) YLSS (talk) 23:29, 5 March 2014 (UTC)

My apologies. I assumed that the archiving here, like at en:wp, was done by a bot. I was expecting a sharp-pointed junction, however the curved one you've provided works and is probably better if it can be applied to more than this kind of junction. Thanks. Lost on Belmont (talk) 13:51, 7 March 2014 (UTC)

No, my name is not Миша (Misha/Misza), although I often feel myself nothing more than a bot. Beep. YLSS (talk) 16:14, 7 March 2014 (UTC)

Staying ahead of the curve

Someday these bad puns are going to catch up to me…
I just realized that there are a whole set of KRX icons (  etc.) that are analogous to the KRZ set ( (KRZur) et al.) As I see it, there are three possibly ways to designate the curves:

Curve
Left/right	l+l	+lr	r+r	lr
Corner Nº	2+1	23	3+4	14
Compass pt.	e	s	w	n

Which is preferable? Useddenim (talk) 13:01, 2 March 2014 (UTC)

As a purely theoretical exercise (at least so far), how would you name e.g.   under the first and second proposals? And how to differentiate it from  ? YLSS (talk) 16:22, 2 March 2014 (UTC)

•    KRXul+lr+r KRxu2+13+4 KRXew
•    KRXulr+lr KRXu1423 KRXns

which is why I prefer the compass points, but that means four more suffixes (although they are already in use with the RP icons).

However, upon further thought, the l/r suffixes should be:

+ll	lr	+rr	+lr

giving    KRXu+ll+rr and    KRXu+lrlr. Useddenim (talk) 18:58, 2 March 2014 (UTC)

Maybe, in order to simplify these really long names (imagine an analogue of  (KRZlr+lr)) and to stay within the bounds of the existent suffixes (for railway icons), we can postulate that for such icons we can turn our head by 45° counterclockwise? Since, as we have agreed, the "main" line is from "4th corner" to "2nd corner". So that:

+l	+r	r	l

Unless, of course, one can image how "l" & "r" can be used in a more appropriate way with KRXes. YLSS (talk) 21:40, 2 March 2014 (UTC)

I agree. Worse come to worse, we swap in the numbers:

+2	+4	4	2

Circeus (talk) 23:31, 19 March 2014 (UTC)

Request for new pictograms

Moved from en:Wikipedia talk:Route diagram template

Can someone please release the following 2 pictograms to this catalog?

• Freight truck
• Freight/container ship

I have asked before and been told that its not needed. I struggle with this logic - Why can we go into intricate detail with passenger stations and not freight stations/hubs? Wiki ian 23:16, 4 March 2014 (UTC)

Why don't you just include something like [[File:Sinnbild LKW.svg|20px|link=Intermodal freight transport]] () into the text column? Useddenim (talk) 11:59, 5 March 2014 (UTC)

Probably because I wasn't aware of its existence.... Got another a freight ship up your sleeves too?

Also, what if I need a grey version of the truck? (resenting not operating) Wiki ian 18:04, 5 March 2014 (UTC)

I just created File:Sinnbild LKW grau.svg which is grey. --Redrose64 (talk) 18:45, 5 March 2014 (UTC)

Thanks heaps. A freight/container ship would also be great. Wiki ian 18:57, 5 March 2014 (UTC)

If you can find an existing .svg file that is not grey, I can turn it grey. It's basically a case of opening up the file in a plain text editor (such as Windows Wordpad), altering all the fill:black to fill:#646464 saving under a new name and uploading. --Redrose64 (talk) 19:33, 5 March 2014 (UTC)

Two possibilities are the US DoT symbol [[File:Aiga watertransportation.svg|x16px]] and [[File:Ferry.svg|20px]]. Useddenim (talk) 01:33, 7 March 2014 (UTC)

OK, I've created File:Aiga watertransportation grey.svg and File:Ferry grey.svg - both are grey. --Redrose64 (talk) 16:49, 7 March 2014 (UTC)

Not to be too fussy, but the standard grey colour for out-of-use BSicons is      (#aaaaaa), not      (#646464). Useddenim (talk) 18:42, 7 March 2014 (UTC)

Oh. I looked at  (BHF black) vs  (exBHF black) --Redrose64 (talk) 19:47, 7 March 2014 (UTC)

There’s also  (BOOT) and  (exBOOT). Useddenim (talk) 23:45, 7 March 2014 (UTC)

I lightened all three from   #646464 to   #aaaaaa. The "File history" entries aren't very good; the "File changes" box, despite its size, won't accept templates, and doesn't like an Interwiki prefix for links either. I wanted to include the Interwiki prefix so that when you view the file description page on Wikipedia, the links will come here instead of to the non-existent w:Talk:BSicon/New icons and icon requests#Request for new pictograms. --Redrose64 (talk; at English Wikipedia) 10:27, 8 March 2014 (UTC)

Multicolorverse

May I congratulate you with the first ever three-coloured icons:  (vfmKRZu-umKRZu),  (vumKRZu-fmKRZu),  (vfmKRZo-umKRZo) &  (vumKRZo-fmKRZo). (At least I don't recollect any to have existed before.) YLSS (talk) 18:33, 10 March 2014 (UTC)

What about  (xKRZu)? That's got three colours. --Redrose64 (talk; at English Wikipedia) 17:41, 12 March 2014 (UTC)

I meant three colour sets, without taking into account any exness or subsidiary features. Otherwise, even  (vuINT-eINT) has four colours (five if incl. white). YLSS (talk) 17:49, 12 March 2014 (UTC)

Black and White and Grey are not colours.^{[citation needed]} User:Deonyi 05:20, 13 March 2014 (UTC)

So if you disregard "exness", these also fail then:  (veBHF-uBHF)  (vuBHF-eBHF)  (veHST-uHST)  (veBHF-uexBHF)  (vuexBHF-eBHF)  (veHST-uexHST)  (vuexKBHFa-eBHF)  (vuexKBHFe-eBHF) --Redrose64 (talk; at English Wikipedia) 16:05, 13 March 2014 (UTC)

I'm afraid you completely misunderstood me... My initial "congratulations" were actually full of sarcasm and of spite. I have a strong distaste for multicoloured icons (i.e. those with prefix "m" etc.) and I always dreaded the day when an icon is uploaded with more that two colour schemes. And that day has come... God save us. YLSS (talk) 19:25, 13 March 2014 (UTC)

Mixed Junction request

Hi everyone, I wanna ask you if it's possible to have a modified version of  (umABZlg) and  (umABZrg), but with the "red" color levels over the "blue" ones (heavy rail over the light rail). I looked for them but seems nobody needed them before me :) Thanks a lot in advance! --Alex10 (talk) 20:56, 14 March 2014 (UTC)

 Done.   (umABZlg1) and   (umABZrg1). Vanisaac (talk) 21:24, 14 March 2014 (UTC)

Wow, really really quick!!! Thanks so much Vanisaac! :) --Alex10 (talk) 22:24, 14 March 2014 (UTC)

It's actually incredibly simple. I just downloaded the two files, opened them in a text editor, and cut and paste the two curves in the opposite order. It took longer to get all the licensing and categories in the upload form than it did to actually create them. Vanisaac (talk) 22:33, 14 March 2014 (UTC)

Yes, that is easy, but the result is really bad if you do not pay attention to what are you dealing with! Both the original files and those you made are hideous (no offence, just constructive criticism). The lines are not uniformly 100px thick, there's a lot of non-integer values and even more inkscape junk etc. Next time, choose some small and neat files, like  (uSTR) and  (uSTRrg), and combine their code.

But that's the easy part, really. The difficulties begin when you try to invert a name for such an icon that would fit the established patterns. Appending an "1" to an existent name is a thing that should never, ever be considered. The only more or less explicable names for these icons that I was able to come up with are   (uSTR+STRlg) &   (uSTR+STRrg).

@Alex10: I would advise you to use overlaying next time. It's easier, quicker, and poses less problems. I have edited that diagram, you can check the syntax (near the top). Also, don't use 5= and similar for text fields: that is really inconvenient when you deal with different BSn templates in one diagram, and will create quite a lot of hindrance if ever those diagrams are converted to Lua. YLSS (talk) 10:21, 15 March 2014 (UTC)

YLSS I saw your edit in that diagram, thank you for it, especially for the overlay syntax explanation (I thought it wasn't possible to use this technique with the it.wiki BSn templates). Ok also for the text fields advice!

Vanisaac also thanks for your explanation, I'm pretty much inexpert with the vectorial graphic :). --Alex10 (talk) 12:27, 15 March 2014 (UTC)

Indeed, it wasn't possible at it.wp until I rewrote those templates. Since Template:Percorso_fer is protected and everybody ignored my requests at 1 & 2, use Template:Percorso_fer1. YLSS (talk) 14:54, 15 March 2014 (UTC)

The topic of light vs. heavy rail hierarchy was discussed here three years ago, so I’m surprised that the mABZ icons were never updated. (Also, according to current naming practices, isn’t this the correct geometry for these names:  (uSTR+STRlg)  &  (uSTR+STRrg) ?) Useddenim (talk) 13:36, 15 March 2014 (UTC)

No, those would be  (uSTRq-STR+r)  &  (uSTRq-STR+l)  (hyphen, not plus). YLSS (talk) 14:54, 15 March 2014 (UTC)

Back for more elevated icons

Okay, so this time I'm really focused on continuations. I'd like to get   (uCONT-r) as   (uhCONT-r). (I've tried mashing code from two different icons together and it was a complete failure.) Additionally, I'd like to get uh versions of this type of CONT  (CONT4+l) but 1) with the line originating at the bottom and pointing to the upper right hand corner of the box and 2) with the line originating at the top and pointing to the lower right hand corner of the box.

As a side note, I've "successfully" created the u version of   (DABZlf) (it renders properly in my browsers) but whenever I attempt to upload it to commons, I get an error message about a "corrupted file" or somesuch. Recreating the file results in the same message. Any and all help is appreciated. Lost on Belmont (talk) 04:11, 29 March 2014 (UTC)

Your code should look something like this:

Click to open

::<?xml version="1.0" encoding="UTF-8" standalone="no"?> <svg xmlns="http://www.w3.org/2000/svg" height="500" width="500"> <title>uDABZlf</title> <g stroke="none" fill="#80a080">  <path d="M 150,75 150,25 50,50 Z"/>  <path d="M 150,175 150,125 50,150 Z"/>  <path d="M 150,275 150,225 50,250 Z"/>  <path d="M 150,375 150,325 50,350 Z"/>  <path d="M 150,475 150,425 50,450 Z"/>  <path d="M 455,17.5 354,30 371,76.6 Z"/>  <path d="M 482.55,45 470,146 423.4,129 Z"/>  <path d="M 455,482.5 354,470 371,423.4 Z"/>  <path d="M 482.5,455 470,354 423.4,371 Z"/> </g> <g stroke="#003399" stroke-width="100" fill="none">  <path d="M 250,0 V 500"/>  <circle cx="500" cy="0" r="250" /> </g> </svg>

Apparently someone’s gone and changed something in the uploader code (again), and it no longer accepts the <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> declaration. Useddenim (talk) 13:19, 29 March 2014 (UTC)

  (uhCONT-r) uploaded. Ignore my previous comment, as this icon does contain the !DOCTYPE declaration. Useddenim (talk) 13:40, 29 March 2014 (UTC)

Ah! This was the problem:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg xmlns="http://www.w3.org/2000/svg" height="500" width="500">

I downloaded the existing file and only changed the color values to what I needed. I guess the original file has some antiquated code. Swapping what was there for that has made my second "iconbashing" attempt  (hHSTACC) work. Thanks!

Interesting to note how much simpler your code is versus that in   (DABZlf). As a side note, I realized I could get the u version by overlaying instead of using an entirely new icon about 8 seconds after making my initial post... Lost on Belmont (talk) 14:37, 29 March 2014 (UTC)

Also there are issues regarding this that have come to my attention. As of now we have three u icons for the same direction, a standard, h, and ex. Unfortunately, these are how the icons are named:   (uCONT-r),   (uhCONT-r), and   (uexCONT+gq). Which is the appropriate naming convention?

Also, the elevated sections on   (uhCONT-r) are thinner than standard and therefore don't align properly with other icons. Lost on Belmont (talk) 03:50, 30 March 2014 (UTC)

I proposed renaming uexCONT-r to   (uexCONT+gq) here, as a more explicable name (and without the confusing l/r!). So the other icons should follow that. WRT geometry: while the current design is a pretty idea at 500px, it doesn't really work at 20px: I only see plain "elevated sidings" that just terminate at some midway point. Maybe something similar to  (uhCONTfq) would be better? YLSS (talk) 08:51, 30 March 2014 (UTC)

Also, Lost on belmont, what design did you have in mind for "uh versions of this type of CONT  (CONT4+l)"? Something dotted? Or like this: File:BSicon ulCONT1f.svg (ulCONT1f※ uhSTR+1)  & File:BSicon ulCONT2f.svg (ulCONT2f※ uhSTR2) ? YLSS (talk) 08:51, 30 March 2014 (UTC)

So far all of the elevated continuation arrows use dots and, as such, I was expecting dots for these arrows as well. (As a side note, the geometry of  (uSTR+1) looks a lot better than that of  (CONT4+l).) I personally like the dots as it serves as a transition from "there" to "not there" and with the arrowhead suggests exactly what it should. I find that I really like the visual cues of the new icon, where the elevated portions add to the negative shape of the reverse arrow, but for consistency's sake think we should stick with dots for elevated continuations. Lost on Belmont (talk) 13:34, 30 March 2014 (UTC)

I redrew the icon with dots, but extending past the end of the coloured centre line in order to preserve the negative space. I also merged the last two dots (at the connecting edge) to emphasize the directionality. Useddenim (talk) 18:34, 30 March 2014 (UTC)

So I see. Looks excellent! Lost on Belmont (talk) 00:19, 31 March 2014 (UTC)

Any headway on the straight/corner CONT pieces? Lost on Belmont (talk) 01:33, 13 April 2014 (UTC)

Recent uploads

These don't appear to be legitimate BSicons (neither by naming nor usage):

•   (BusSIT MetroMed)
•   (BicycleParking MetroMed)
•   (Info)
•  (SUBWAY-CHN alt)

(Note that the first three were all uploaded by the same individual.) AlgaeGraphix (talk) 22:37, 29 March 2014 (UTC)

The first three now renamed, one is pending a deletion request. The fourth,  (SUBWAY-CHN alt), could be kept as a BS icon, though. -- Tuválkin ✉ 00:23, 30 March 2014 (UTC)

Rolling-lift bridge

Moved to Talk:BSicon/Icon geometry and SVG code neatness/Drawbridges

Halved stations on parallel lines across

Useddenim has recently introduced a brand new class icons which I have grouped in Category:Icons for railway descriptions/half width/parallel lines/stations and stops/BHF/halved. While I understand their purpose (so that one can construct e.g. KBHFxeq-KBHFeq), I'm not happy with their naming (sorry for being such a douche). First of all, all of them require "q"s after each BHF part of the name, since by dropping "v" we only change the way we divide the icon field and not the way we name the icons (as I have explained here). Secondly, those of them where there is only one line still require another BHF in their names (something like  (dBHF--L) should show only a station on the upper line and nothing at all in the lower half of the icon), so probably it should rather be   (dBHFq-lBHF), but I'm not sure… And lastly, something should be settled with the "L"/"R" suffixes. Some time ago I renamed  (BHF-Lq) (from a title with "t"/"b"), and nobody seemed to protest. Deriving from this, and also from this discussion, BHFq-KBHFeq-R should show a rotated version of  (vBHF-KBHFa-R)... On the other hand, other examples of "halved" stations are  (BHFl) and  (lBHFl)… So I'm quite at loss how to name them properly, maybe some innovative pattern is required... YLSS (talk) 20:39, 6 April 2014 (UTC)

To be honest, I didn’t have any real idea either as to how they should be named. (As YLSS rightly points out, they are a new class of icons.) So I opted for the simplest naming possible; by all means go ahead and change them to something better. I used -L and -R suffixes since l and r tend to be used for movement or direction ( (BHFlf),  (STRlf) etc.) I don’t suppose that anyone would believe that I created them solely to have a legitimate xBHF icon? Useddenim (talk) 21:30, 6 April 2014 (UTC)

Upon re-reading YLSS’ comment above, isn’t BHFq-KBHFeq(-R) a rotated version of  (vKBHFe-BHF)(-R)? Useddenim (talk) 21:38, 6 April 2014 (UTC)

Also (not that I would want to see the diagram that would require it), we need a way to differentiate between the left and right halves of this compound icon, and a connection to left (top) or right (bottom) adjacent. Useddenim (talk) 21:41, 6 April 2014 (UTC)

We have the h suffix for half (as in  (STR2h+4), so what about dhlBHF and dhrBHF prefixes for the left and right halves, which leaves the suffix available for connection to adjacent? Useddenim (talk) 21:50, 6 April 2014 (UTC)

The prefix h is reserved for high level tracks. a×p_de^Hello! 19:37, 7 April 2014 (UTC)

Oh, yeah. Got a better suggestion? Useddenim (talk) 00:31, 8 April 2014 (UTC)

How about  (dvBHF-Fq) and  (xdvBHF-Gq-)? That is, we are adding -G/-F (corresponding to -L/-R) and d- to what would be the correct name of the rotated corresponding through station ( (vBHFq) and the hypothetical  (xvBHFq-) , respectively). Circeus (talk) 17:45, 12 April 2014 (UTC)

Good idea. (Although, wouldn’t this be  (xvBHF-) ? hence  (xvBHFq-) .) Useddenim (talk) 00:21, 13 April 2014 (UTC)

I aways assumed that we rotated icons 90° clockwise and in any case,  (vSTR-) and  (STRq-) (why do the rotated icons lack the v- prefix, anyway?? This is a mess waiting to happen) don't exactly leave a lot of room for interpretation... Hence  (xvBHF-)  →  (xvBHFq-)  →  (xdvBHF-Gq-). Or am I overlooking something? Circeus (talk) 01:08, 13 April 2014 (UTC)

If anything,  (dvBHF-Fq) &  (xdBHF-Gq-) (no "v" for the second one), but I'm not sure about the suffixes... And, as I wrote before, there would be a confusion between and   if we do not use a second BHF... So possibly dxBHF-Gq-lBHF-G or dxBHFq-lBHF-R, but all this is really bizarre... Maybe better exSTRq-+vBHFgq?? YLSS (talk) 02:19, 13 April 2014 (UTC)

Or we could just go straight for my old idea of using + for untranslatable name that simply connect "overlaying icons".  (exSTRq-+lvBHFq) . This works at least as long as the corresponding icons don't change names. This results in  (exSTRq-+dvBHF-Gq). It's not elegant, but it's 100% unambiguous. And pray tell why the fuck, excuse my French, should rotated icons NOT use v- when they are nothing but rotated v- icons?? (This is the sort of shit that we spent days talking about fixing later on!) Circeus (talk) 02:57, 14 April 2014 (UTC)

Hm, I was under impression that this was first proposed back in 2011. I provided some recent justification for this here. YLSS (talk) 04:55, 14 April 2014 (UTC)

↓ regular direction, lines listed 1|2; → q direction, lines listed  . Useddenim (talk) 03:32, 13 April 2014 (UTC)

I have NO idea how that is supposed to translate into any mistakes in my names. Circeus (talk) 02:57, 14 April 2014 (UTC)

Maybe because you were listing the elements bottom-to-top (i.e. right WRT direction of travel, then left, rotated)? And it was decided either vICONq if the icon has rotational symmetry of is unambiguous, or else ICON^top-ICON_bottom (no v). Capisce? Useddenim (talk) 03:38, 14 April 2014 (UTC)

Conundrum

moved to Talk:BSicon/Renaming/SPL#.../parallel railways/uw/double

Elevated KRWs

I've been doing some partial track diagrams (for station infoboxes) and as always, I need some new elevated icons. What I'm looking for is either  (uhKRWgl+l) and  (uhKRWgr+r) or (what I assume would be)   (lhKRW+l-L),   (lhKRW+r-R),   (lhKRWr-L), and   (lhKRWl-R) for overlays. I attempted to create the overlay icons, but I wasn't successful.

I'm also still looking to get the curved elevated continuation pieces (set u) pointing to corner 1 and to corner 3.

As a side note, would anyone be able to explain why I get the generic railway line legend instead of the track legend for the stations I've been doing? It works when I switch "track" for others (canal, etc.) but not the one I need. See en:18th (CTA station) for the track/railway line issue and for the icons I'm looking to get in case I've gotten the syntax wrong for the overlay icons. Lost on Belmont (talk) 21:51, 4 May 2014 (UTC)

I added the four corner variants of   (lhSTR-Rlg) to en:18th (CTA station), and it doesn’t look bad. I’d argue that, by making a smooth curve, it looks even better than the pointy meeting of the formations, as in . -- Tuválkin ✉ 03:43, 5 May 2014 (UTC)

WRT legend: use {{BS-map}} with inline=1 instead of {{Infobox rdt}}. YLSS (talk) 05:59, 5 May 2014 (UTC)

 Done, but if you’re not happy with the geometry, you may prefer to use the constructs shown below:
File:BSicon lhSTR-Lrg.svgFile:BSicon lhSTR-Llf.svg (lhSTR-R※ uKRWgl+l※ lhSTR-Llf※ lhSTR-Lrg)   (lhJCTfq※ uKRWgl+l) 
File:BSicon lhSTR-Rlg.svgFile:BSicon lhSTR-Rrf.svg (lhSTR-L※ uKRWgr+r※ lhSTR-Rrf※ lhSTR-Rlg)   (lhJCTgq※ uKRWgr+r)  Useddenim (talk) 18:13, 5 May 2014 (UTC)

Thanks to both of you. It's weird. Every time I need pieces of an elevated icon like these, I seem to test every other potentially applicable icon but forget (or assume I've already tried) pieces like   (lhSTR-Rrf). Lost on Belmont (talk) 23:25, 5 May 2014 (UTC)

I’ve also added  (lhJCTf) et al. to simplify the overlaying. Useddenim (talk) 01:24, 6 May 2014 (UTC)

Why JCT and not e.g. lhABZgl+l? This doesn't look like the only series of icons that currently uses the JCT root,  (utvJCTgol) et al. Did you mean  (TEEl)? If yes, then there's the question of curved corners vs. pointy corners...^{Oops, missed  (lhTEEfq) & co.} Or was it  (uJUNCld) ?? YLSS (talk) 08:03, 6 May 2014 (UTC)

JCT for generic junction, since it can be used with  (lhJCTfq※ ABZgl+l) ,  (lhJCTfq※ KRWgl+l) ,  (lhJCTfq※ ugJUNCld) , etc. Useddenim (talk) 03:40, 8 May 2014 (UTC)

That’s what I thought, yes. Besides, seems that things like  (ABZlg) or  (KRWg+r) would be better served with a combo of round and square formation edges:

•  (lhABZg+r※ exKRWg+r) 
• File:BSicon xABZrg yellow.svg (lhABZg+l※ xABZrg_yellow) 
•  (lhABZgr※ fKRWgr) 
• File:BSicon ABZlf cerulean.svg (lhABZgl※ ABZlf_cerulean) 

-- Tuválkin ✉ 04:48, 8 May 2014 (UTC)

Agreed. And, a lo-o-o-ong time ago I started to change the offside corners of  (uhABZq+r) etc. from round to square. Useddenim (talk) 11:37, 8 May 2014 (UTC)

Huh, I always wondered why nobody created these overlays... And apparently I was too lazy to upload them myself. Well, at last! ;) YLSS (talk) 21:36, 9 May 2014 (UTC)

OK, let it be JCT. But why such suffixes? I supposed we settled at least on  (TEEa), so why  (lhTEEf) &  (lhJCTf) ?? And, as I wrote in that same discussion, in case of TEEs it may indeed be preferable to have "l" & "r" (or not?..). YLSS (talk) 21:36, 9 May 2014 (UTC)

Oh, I dunno… it may have something to do with your suffix changing, which I seem to lose track of. I don’t have any ojections one way or the other, but if you want lhTEEl and lhTEEr, then it should also be  (lhTEEf) and  (lhTEEg) for consistency, not lhTEEa and lhTEEe. Useddenim (talk) 23:26, 9 May 2014 (UTC)

JPG

OMG, real JPGs, not even PNGs! File:BSicon RP2uRP4.no2edit.JPG & File:BSicon RP2wnRP2no2edit.JPG. Tuválkin, do you need them?.. YLSS (talk) 15:26, 29 May 2014 (UTC)

(Ew…) No, I don’t — these should be nuked on sight, I think. -- Tuválkin ✉ 11:21, 20 July 2014 (UTC)

uCONT icons

{{BS2|STR|O1=ENDEe~L|ENDEe~R|O2=STR}}} {{BS3|dSTR|dENDEe|dENDEe|}}} {{BS3|d|O1=STR|d|O2=ENDEe|STR|}}}

Looking to get   (uhCONT+g),   (uhCONT+f), and   (uCONT+fq). I also need (what I assume would be)  (uCONTg-R),  (uCONTg-L),  (uCONTf-R), and  (uCONTf-L) (which should be the corresponding CONT pieces for this  (uSTR-R) type.) Lost on Belmont (talk) 12:41, 30 June 2014 (UTC)

Here you are:   (uhCONT+g),   (uhCONT+f),   (uhCONT+fq). WRT halved icons, it's actually simpler to either use half-width icons, or to use "shifted" overlaying, see the example. YLSS (talk) 15:24, 30 June 2014 (UTC)

Huh, I also realised that your March request was left unanswered, so, if you still need them:  (uhCONT1+f) &  (uhCONT2+g). (Had to calculate sin 15° & cos 18° for these. Did you know that ((393 − 250) / (1 − 1 / √2) − 130) × (1 / √2 − 1) + 120 gives 15.1, while on the other hand ((393 − 250) / (1 − 1 / √2) + 130) / √2 + 393 − (393 − 250) / (1 − 1 / √2) / √2 gives 484.9 = 500 − 15.1 ? I didn't!) YLSS (talk) 16:13, 30 June 2014 (UTC)

BTW, those The Loop templates of yours are really impressive! And a good test ground for all elevated formations ;) I would also suggest using elevated k-curves in those places where there are no junctions, like in {{AirTrain (SFO)}}. YLSS (talk) 17:02, 30 June 2014 (UTC)

Thanks! Although in all honesty, I have no clue (even after looking at your example) of how to get the shifted overlay I want. An example is en:Racine (CTA Blue Line station). (I am trying to make a better version of what epicgenius did with CSS but with BS icons.)

Thanks for  (uhCONT1+f) &  (uhCONT2+g)! But shouldn't they be in elevated/uw/continuation instead of just "elevated/continuation"?

As for the Loop templates, I have already begun to switch some of the curves to k-curves per your suggestion. (I may leave the former Tower 8 area—lower left corner—as uws as a subtle suggestion of the junction once there.) If you have any suggestions for improving the 3/4 grand junction in the upper left corner in the more contemporary templates, I'd greatly appreciate it. As it is, it's functional, but clunky. Lost on Belmont (talk) 02:03, 1 July 2014 (UTC)

At the top of en:Racine (CTA Blue Line station), the middle track has no ending, what do you need there? -- Tuválkin ✉ 03:54, 1 July 2014 (UTC)

Is this what you wanted with Racine? I didn't understand want you meant, so if I guessed wrong, feel free to revert. Also, I was unable to find a place for a pointer; maybe the unused lines could terminate one row sooner? WRT overlaying: there's a couple of examples at my talk page, maybe you'll find them helpful... YLSS (talk) 14:25, 1 July 2014 (UTC)

The middle track at the top of Racine, as Tuvalkin noted, is the place where I wanted an arrow, but that line (which I had intended to replace) is made of two "side" pieces. This is why I wanted the half piece arrows, or, to overlay an arrow in the middle. Instead of cluttering this page with ideas on how to correct this, I'll go to YLSS's talk page. Thanks everyone. Lost on Belmont (talk) 22:07, 1 July 2014 (UTC)

All elevated with corners

I have recently created a set of icons I have long coveted: elevated straight pieces with elevated corners! (I am lazy and loathe multiple overlays for simple concepts.) This is the initial result:  (uxhSTR+hc1)  (uxhSTR+hc2)  (uxhSTR+hc3)  (uxhSTR+hc4). I'm holding off in creating the remaining pieces until I get at least the first of two things resolved.

1) Should the naming structure have the "h" for the corner pieces come at the beginning or the end? For instance, hSTR+hc1 or hSTR+c1h. Lost on Belmont (talk) 03:12, 17 July 2014 (UTC)

h following a number is a special construct that indicates half (width) stroke at corner number #, as in  (STR3h+1h) or  (STR2h+r) (vs.  (STR3+1) and  (STR2+r)). Useddenim (talk) 03:48, 17 July 2014 (UTC)

You know... I think we can live without an additional "h" in this case, i. e.  (uxhSTR+c1). If anyone liked to have an elevated track + non-elevated corner in a single icon (let's hope no one ever will), that one could be called uhSTR+STRc1 (or uSTR+hSTRc1. YLSS (talk) 09:36, 17 July 2014 (UTC)

Agree. Useddenim (talk) 11:36, 17 July 2014 (UTC)

If I have learned one thing from my life, it is that hoping that something won't happen is almost always a precursor to that very thing happening. (And that always seems to be the case with BSicons.) I would rather assume that it will happen (maybe not today, maybe not tomorrow, but some day) and then prepare for that instance (even if it never happens). Given that, your proposed uhSTR+STRc1 scheme wouldn't be consistent with the icons I just created or with their non-elevated counterparts. That leads me to two possibilities: either we keep the icons as they are now (STR+c1 and hSTR+hc1) with other variants being named hSTR+c1 and STR+hc1 or we rename the existing icons now including the STR for the corner piece  (STR+STRc1). Lost on Belmont (talk) 12:02, 17 July 2014 (UTC)

That's the intention: these elevated-here-but-not-here icons won't be consistent with either  (uSTR+c1) or  (uhSTR+c1), and it's not necessary. But feel free to choose the name you want, as the inventor of the series. (Move any icons you think is better.) YLSS (talk) 18:23, 17 July 2014 (UTC)

2) If someone could supply me the correct path placement numbers for useddenim's new formation scheme (in order to save creating new versions for each). The straight pieces are an easy one, but I'm no .svg wizard and I still have no idea what the numbers specifically convey. Lost on Belmont (talk) 03:12, 17 July 2014 (UTC)

50px lines @ 125 & 375. Useddenim (talk) 03:48, 17 July 2014 (UTC)

Yup, like in this one:  (uhSTR+c1). YLSS (talk) 09:36, 17 July 2014 (UTC)

Changing the values of "120" to "125" and "380" to "375" will also take care of the corner section(s)? Lost on Belmont (talk) 12:02, 17 July 2014 (UTC)

See also Talk:BSicon/Icon geometry and SVG code neatness/Formations#Diagonal + curve for diagonals. YLSS (talk) 18:23, 17 July 2014 (UTC)

The problem with that is that while the values are specified, I have no idea how to use them in this set of icons. I don't fully understand the way .svg files are coded (obviously I can hack my way through some of it) but I have a lot of other projects I need to work on and I don't have the time to learn the ins and outs of coding .svgs. Lost on Belmont (talk) 15:15, 19 July 2014 (UTC)

It’s just a lot of math: geometry & trigonometry. Useddenim (talk) 03:59, 21 July 2014 (UTC)

Lost on Belmont, you can start (and finish) here. -- Tuválkin ✉ 10:42, 21 July 2014 (UTC)

I risk saying some things that you already know, but the most common operations you need are:

• Flipping the image horizontally: just "reverse" all x-coordinates, i. e. subtract them from 500 (for full-width icons) or 250 (for half-width) etc., e. g. 125 → 375, or -35.4 → 535.4
• Flipping the image vertically: reverse all y-coordinates
• Flipping the image along the diagonal from the top left corner (#4 in the BSworld) to the bottom right (#2): swap x-coordinates with y-coordinates (and replace H operators with V operators, and vice versa; they are followed by x- & y-coordinates, respectively)
• Transpose the image by some amount horizontally, vertically or diagonally: just add or subtract the needed amount from respective coordinates. For example, to calculate that elevated sidings in corner: (the middle of) a siding is 125px from (the middle of) a line, so if the line is at the 1st corner (500, 0), the siding is 125px from it diagonally, or 125 / √2 ≈ 88.4px from it along the x-axis, and as much along the y-axis, i. e. M 411.6, 88.4. That's the midpoint; to know where to draw the line from and where to, just add enough to get outside the borders of the icon, e. g. 200px: then you get M 211.6, -111.6 L 611.6, 288.4.
• For circular arcs, the first two values are not coordinates but the radii (should be equal for circles), and should not be touched in the above cases. However, the fifth value — usually either "0" or "1" — should be reversed for each "flipping".

That's pretty much everything you need for deriving an icon from an existent one. Creating some new geometrical shape would require some more serious calculations, although, as Useddenim said, with geometry & trigonometry you can achieve pretty much everything. YLSS (talk) 17:21, 21 July 2014 (UTC)

Thanks, this is exactly what I needed! Lost on Belmont (talk) 02:15, 22 July 2014 (UTC)

@Lost on belmont: Tuválkin provided a link above (at 10:42, 21 July 2014); that's quite a large collection of docs. The ones that I find most useful include:

• The circle element
• The ellipse element
• The line element
• The path element and its subcommands:
  • A/a (elliptical-arc)
  • C/c/S/s (curveto)
  • L/l/H/h/V/v (lineto)
  • M/m (moveto)
  • Q/q/T/t (quadratic-bezier-curveto)
  • Z/z (closepath)
• The polygon element
• The polyline element
• The rect element
• Fill Properties
• Stroke Properties

I typically take an existing image file that's close to what I need, and add or remove elements as needed, and then adjust coordinates, colours etc. --Redrose64 (talk; at English Wikipedia) 18:00, 25 July 2014 (UTC)

(Just to think of it... Just a couple of months ago things like  (STR+c1) were pretty transcendent, unknown & unused. And now we deal with their "xh" versions. Things change... YLSS (talk) 09:36, 17 July 2014 (UTC))

Oh yes, means we’re finally on the right track! -- Tuválkin ✉ 10:42, 21 July 2014 (UTC)

Icon for waterfall

Hi, we are at least two users in Sweden who miss an icon for waterfall in a river. I have used the icon WASSER in the map at https://sv.wikipedia.org/wiki/Karl_IX:s_kanal The other user has used WWEIRg in https://sv.wikipedia.org/wiki/Trollh%C3%A4tte_kanal Neither of us is happy with these icons. Best, Peterappelros (talk) 20:57, 29 July 2014 (UTC)

And what's wrong with  (WWEIRg)? For me, it pretty much suggests a waterfall. A weir is a small waterfall, after all. Also, there is  (uWEIRe), but it suggests more of some artificial construction. YLSS (talk) 22:40, 29 July 2014 (UTC)

WWEIRg (especially the black elements) suggests some form of man-made dam. It has also similarities with the lock icon. I rather prefer to use the WASSER icon, which suggests some "wildness". But I would prefer something still better. Peterappelros (talk) 05:58, 30 July 2014 (UTC)

Does this meet your needs:  (WFALLf)? (Although, unfortunately, the masking went slightly awry.)^{Fixed. Useddenim (talk) 22:17, 1 August 2014 (UTC)} Useddenim (talk) 04:12, 1 August 2014 (UTC)

Yes, it does, thank you very much! You can see it in use here: https://sv.wikipedia.org/wiki/Mall:Kanalkarta_Karl_IX:s_kanal

I think it would be fine if it were available in 90, 180 and 270 degrees as well.Peterappelros (talk) 12:59, 1 August 2014 (UTC)

Coming right up. Useddenim (talk) 22:17, 1 August 2014 (UTC)

Tunnel to elevated

Okay, looking to get an icon depicting a tunnel transitioning to elevated to corner 3, set u. Basically this is an elevated version of  (utSTR3e).

  (uhTNL3e). Useddenim (talk) 02:35, 6 August 2014 (UTC)

Most excellent. Thanks! Lost on Belmont (talk) 13:50, 6 August 2014 (UTC)

Just found this: You made great efforts to change "TUNNELa" to "tSTRa" and so on but now you introduce a new icon root "TNL"? This is inconsequent! Even more, half of the icon the track is in tunnel, the other half elevated, maybe someone demands to get back to the old "-ELEV" suffix? I'd say we have to think about this ... a×p_de^Hello! 17:27, 13 November 2014 (UTC)

ACC across even-number multiple lines

Also, thanks to Useddenim, we now have  (lINTACC-M) and  (lINTACC-Mq). Both of these icons work great for instances of odd numbered lines. For even numbers, we may have a problem. I attempted to use the horizontal icon as an overlay of the half-width blank cell. It positioned correctly, but half of the icon was covered over by the piece on the right. Is there a way around this or do we need two icons that are split in half? The same thing for verticals. Is there a way to branch between rows like with columns? Lost on Belmont (talk) 22:31, 5 August 2014 (UTC)

"Is there a way around this": at en.wp, no. In other Wikipedias, an overlaid icon would also cover the base icon in the cell to the right (but not its overlays), which I find very handy. At en.wp, the syntax of BS-overlap was changed some time ago so that all icons are actually overlaid on top of an empty cell, and this trick doesn't work. So you need either something like  (lACCr), or some  (ldINTACC-M) placed between  (dINT-L) &  (dINT-R), or maybe something else (better provide a link to the diagram in question). "Is there a way to branch between rows like with columns?": only at no.wp. I plan to implement the same thing in {{Routemap}}, but as yet, no. YLSS (talk) 06:07, 6 August 2014 (UTC)

I must begin by objecting to ‎your comment, Tuvalkin, this is not a chat channel, pls. use heading for easy/future reference and splitting the section. I clearly labeled the previous section Tunnel to elevated and INTACC overlay to encompass both parts of my request.  (lINTACC-M) and  (lINTACC-Mq) are both INTACC overlays as would be the INT versions of  (lACC-R) et al. if it was determined that it needed to be created for this instance. Lost on Belmont (talk) 14:24, 6 August 2014 (UTC)

While I erred for not noticing that the heading you chose did reflect the content, it is still true that two unrelated subjects should not share a thread, even if correctly labelled. It is enough for your momentary interest, but doesnt allow for, say, future splitting or simple referencing according to subject. No offense intended, please do not take any. -- Tuválkin ✉ 22:57, 10 August 2014 (UTC)

That said, "[i]n other Wikipedias, an overlaid icon would also cover the base icon in the cell to the right (but not its overlays)" was exactly what I was expecting to find at en.wp. Alas. The template in question is one of my Loop templates. I was stating with the current one and would fix the others as applicable. Washington/Wells and Library are the two stations in question. Washington/Wells should be like an ACC version of Adams/Wabash while Library should be like a two line version of Clark/Lake. Lost on Belmont (talk) 14:24, 6 August 2014 (UTC)

(Which reminds me of the bizarre  (HFNt) &  (HFNb)... YLSS (talk) 17:25, 6 August 2014 (UTC))

 (lINTACC-L) &  (lINTACC-R). Useddenim (talk) 02:01, 7 August 2014 (UTC)

Thanks. Can I get the "Lq" and "Rq" versions as well? Lost on Belmont (talk) 12:10, 10 August 2014 (UTC)

You mean  (lINTACC-Rq) &  (lINTACC-Lq)? I don’t see why not. Useddenim (talk) 21:30, 10 August 2014 (UTC)

Great! Thanks. Lost on Belmont (talk) 00:54, 13 August 2014 (UTC)

File:BSicon BOOT.svg

JaJaWa (talk · contribs) uploaded a noticeably different version of this file, apparently without discussion. Any thoughts? AlgaeGraphix (talk) 13:42, 16 August 2014 (UTC)

Regardless of any merits of the changed design over the original one, such change cannot be accepeted without discussion. A detailed explanation should be the first stop for that. This upload should be reverted ASAP. -- Tuválkin ✉ 21:57, 16 August 2014 (UTC)

Done. Lost on Belmont (talk) 01:16, 17 August 2014 (UTC)

FYI: At my request JaJaWa's version was separated to  (FERRY). Also, I uploaded File:Ferry symbol.svg to be used via {{Rint}} and similar. YLSS (talk) 10:16, 2 November 2014 (UTC)

Icon request: BSicon ebvWSL-BS2lr.svg in light rail blue

Hello,
I search this  (ebvWSL-BS2lr) in blue for light rail, but I couldn't find it. I need it for this Wikipedia page: de:Benutzer:U-Bahnfreund/Stammstrecke 3 (Stadtbahn Dortmund). Could anyone upload this?
Thank you, --U-Bahnfreund (talk) 14:03, 22 September 2014 (UTC)

You can use    instead, right? -- Tuválkin ✉ 17:30, 22 September 2014 (UTC)

I don't know... This is with overlay, right? I once tried this (Overlay) in the German wikipedia, but failed. Maybe I'm doing it wrong or it doesn't work on German wikipedia. --U-Bahnfreund (talk) 18:20, 22 September 2014 (UTC)

Ah, yes, w:de doesnt do overlay, sadly so. You can use these two side-by-side:

•  (uBS2l+uexSTRlf)
•  (uBS2r+uexSTRrf)

I think that splitting in two halves things like  (ebvWSL-BS2lr) is a good idea, as each half is more productive (see example diagram →) than the combo. -- Tuválkin ✉ 19:10, 22 September 2014 (UTC)

Thank you, I'll use these. --U-Bahnfreund (talk) 19:24, 22 September 2014 (UTC)

Hm, since we're going into the unorthodox area here, let's use modern naming patterns. Plus, I think it's better to spell out the "ex" element first and then non-"ex", as that's how they are actually drawn. So,  (uexSTRl+uSHI2l) &  (uexSTRr+uSHI2r). But I totally agree that such combined icons are more useful than the double "b" ones. YLSS (talk) 20:04, 22 September 2014 (UTC)

Agreed about the renamings, of course, and thanks! (Not sure about the stacking order, but we’ll sort that out some other day,) -- Tuválkin ✉ 20:13, 22 September 2014 (UTC)

exTUNNEL

split from Talk:BSicon/Obsolete and deletions#e/xTUNNEL

I uploaded  (exlTUNNEL) to indicate a former tunnel. I used a dashed line as we don't have an “ex” colour for formations. Useddenim (talk) 22:55, 7 November 2014 (UTC)

That raises the question of the semantics of our two special colors —  formation   and  black  , and why one has an  ex-color  , and the other does not. This should be discussed someday, surely, but so far I'm unconvinced with dotted formations, though. -- Tuválkin ✉ 11:56, 8 November 2014 (UTC)

I think these dashed formations should go below the track:  . That was actually my first idea, to overlap  (STR※ TUNNEL1)  (but then I recalled that de.wp lacks overlaying), but with the portals "broken" that looks even better. But I can't say that I like the name. Also: 50px lines now, and narrower portal; I tested things at  (tLSTRa). YLSS (talk) 12:36, 8 November 2014 (UTC)

After thinking long about this, let me vote against these dotted portals — sorry, guys! I think the semantics "location of a former tunnel entrance" is best conveyed with  (STR※ TUNNEL1) , like YLSS thought at 1st — it looks better at small sizes (such as 20px) and cannot be confused with established meanings of dotting (lücke/interruption , which it is not — and that’s one bad choice of a filename prefix, and lines in tunnel , very confusing). -- Tuválkin ✉ 23:49, 12 November 2014 (UTC)

Despite the semantics (and the fact I designed it), I still think the intent of  (STR※ exlTUNNEL)  is clearer than  (STR※ TUNNEL1)  at 20px (and also   vs.  ). Useddenim (talk) 19:04, 13 November 2014 (UTC)