Talk:BSicon/Icon geometry and SVG code neatness

From Wikimedia Commons, the free media repository
Jump to: navigation, search
alt= link=
Archive 1 Archive 2 Archive 3
See also: Talk:BSicon/Icon geometry and SVG code neatness/Formations

INT circle radius[edit]

moved from User talk:Axpde/Archive 3#INT circle radius

There are (or had been) some uncertainties with the correct measurements of the width and stroke-width of the circle. From what is calculated, the total radius of the circle = (width) + (1/2)*(stroke-width) and this value is expected to be 150 to match that in the BHF icon. The syntax is given by:

<circle cx="250" cy="250" r="___" stroke-width="___"/>

where "r" represents the width (or radius, without the stroke border). There are several measurements used in the INT files:

Width value Stroke-width value 1/2 Stroke-width value Total radius Sample BSicon Comments
123.853 52.2936 26.1468 149.9998 uINT BSicon uINT.svg Currently used on most INT icons, with a few changes in decimal places in the stroke-width for certain files.
120 60 30 150 utKINTr BSicon utKINTr.svg Closest rational values, but with a rather thick border.
123.5 53 26.5 150 Possible set of measurements (1) with close resemblance to the first one.
124 52 26 150 Possible set of measurements (2) with close resemblance to the first one, if integer values are desired.
120 60 30 150 DST DST used by all DST-type BSicons
120 60 30 150 TokyoMita TokyoMita used by all (13) Tokyo Metro special BSicons

It is actually not advisable to use smaller values for the width of the circle itself, because of the use of the INTACC icons involved. What is your take regarding this - do you intent to standardize the measurement for all INT icons? Regards, NoNews! 12:34, 21 May 2011 (UTC)

Well, a good question. Actually I never cared for those special icons created by w:en:, it was enough effort to ensure a consistent naming scheme at least for those icons used by w:de:. If you want to hear my thoughts about it, I'd suggest to use the same parameters as all DST-type BSicons do. Regards axpdeHello! 18:12, 21 May 2011 (UTC)
I just fixed this one   (fINT) (misnamed as BHF tr, meanwhile renamed (-- Tuválkin 14:07, 3 August 2012 (UTC)), too). -- Tuválkin 00:22, 30 November 2011 (UTC)

Interchanges too?[edit]

moved from Talk:BSicon/Renaming#ugINT

BTW, Tuválkin, are you really going to re-upload all INT-interchanges? I thought that discussion only concerned the circle radius. The "extended" versions currently use either 52.smth or 50. (I've uploaded a couple using the latter.) YLSS (talk) 14:20, 18 June 2013 (UTC)

I assumed the above applies to all INTs. I see avdantages:
  1. They look better together: BSicon INT.svgBSicon INT-L.svgBSicon INT-R.svg vs. BSicon uINT.svgBSicon uINT-L.svgBSicon uINT-R.svg (blues were not modified yet).
  2. The current icons, regardless of the measures, are messy, with sloppy SVG causing rendering issues — they could use a rehaul.
  3. The same values for both round and pillbox shapes allow for combinations both like this BSicon lINTl.svgBSicon lINTr.svg to look identical to this BSicon lINT.svg, and like this one BSicon lINTl.svgBSicon lINT-R.svg to look identical to this other BSicon lvINT.svg, just like we do routinely with DSTs and BHFs.
Of course, while this change is being done, some icon pairs will look crooked. -- Tuválkin 17:26, 18 June 2013 (UTC)

Diferent design[edit]

ulDSTr + lDSTr
BSicon ulDSTr.svg
lDSTr + ulDSTr
BSicon lDSTr.svg
c ulDSTr

Just an aside: Icons   (lDSTr) and   (ulDSTr) should be identical except for line color but, even if both use stroke thickness of 60 nominal pixels, the different curve type (quadratic bezier v.s ellipse) gives slightly different results (red is thicker), which is not acceptable. There may be more cases like this -- Tuválkin 04:42, 30 June 2014 (UTC)

The issue is not with circle vs. circular arc in path (which do indeed produce different results, but just on the verge of noticeability at 500px), but in that   (lDSTr) has the radius of 125 instead of 120. So it's a singular mistake, not a trend. YLSS (talk) 08:05, 30 June 2014 (UTC)
Ugh 125 > 120 indeed, I should have noticed the obvious! Thanks, YLSS! -- Tuválkin 15:57, 10 July 2014 (UTC)
Urm, but you did pretty much the contrary. Better replace that with a circle, and don't forget   (lDSTl) ;) YLSS (talk) 16:09, 10 July 2014 (UTC)
I just ✓ did that, after some coffee… :-) -- Tuválkin 16:20, 10 July 2014 (UTC)


BSicon .svg KBHFa
BSicon .svg INT
BSicon .svg BHF
BSicon .svg KBHFe

Is it currently now standard for the INT borders to be 60 or 50? The current version as seen here:   (gINT) looks and feels too small when placed next to standard BHFs. In fact, one would possibly propose that the size of the interchange icon to be slightly increased simply due to the fact that when placed along with other icons, it looks far too small, tiny and unimposing. 22:28+22:25+22:24, 18 June 2013‎ Deonyi

It may be like this as INTs have a black border which recedes into the grey. However, it seems the thinning of the border also helps alleviate this issue. 22:28+22:25+22:24, 18 June 2013‎ Deonyi

Small DST & INT[edit]

What are the standard values for "small" DSTs and INTs, those with the total radius = 125? r="100", stroke-width="50", right? As in   (uvKDSTe-STR) &   (uvINT-STR). YLSS (talk) 00:50, 22 October 2013 (UTC)

Why blue and red with different designs for the same topology?[edit]

moved from Talk:BSicon/New icons and icon requests#Why blue and red with different designs for the same topology?
merged to #Elliptical curves

Houses sizes and number of windows[edit]

moved from File talk:BSicon lBLG-L.svg#Unneeded
lBLG-L + vSTR-
BSicon lBLG-L.svg
BSicon .svg
lBLG-R + uv-ENDEa
BSicon lBLG-R.svg
Overlay on (one of) parallel tracks
lBLG-L + vDST-
BSicon lBLG-L.svg
lBLG-R + utv-STRa
BSicon lBLG-R.svg
Looks like small and big
houses at the same scale
SHI1+r BSicon .svg utSHI1+l
BSicon BUILDINGr.svg
BSicon BUILDINGl.svg
Looks like the same house
at different scales
BSicon BUILDINGr.svg
BSicon .svg
BSicon BUILDINGl.svg
Overlay on regular track

This icon   (lBLG-L) is similar to, and appears to duplicate the function of   (BUILDINGr). What was the purpose of creating it? Useddenim (talk) 00:34, 24 November 2011 (UTC)

(I made   (lBLG-R), too, as usual with messy names.) I knew about   (BUILDINGr) and   (BUILDINGl), of course, but I still made this new one (from   (ueMILL) — by the way, this tool is great to upload/mark derivatives) for two reasons:
  • Its size and placement were thought to pair up overlays with (incomplete) double lines (while   (BUILDINGr)&  (BUILDINGr) are meant for overlays on regular track):
    •   (lBLG-R) with   (v-STR),   (uv-STR),   (v-STR+1), etc.
    •   (lBLG-L) with   (exvSTR-),   (uvSTR-),   (vSTR+r-), etc.
  • Its bigger window makes it a much better looking same-size match for   (BUILDING) (while   (BUILDINGr)&  (BUILDINGr) are just downscaled versions of it).
I see now that the name should include a "v" preffix and a "-", too.
-- Tuválkin 17:59, 24 November 2011 (UTC)
But I don't think it will need the l/r (lower or uppercase). Clearly the building icon can only be on the side opposite the rail, so   (lBLG-R)/  (lBLG-L) ->   (lv-BLG)/  (lvBLG-) (assuming lv- is the correct order...). FWIW, they are l2BLG and l1BLG in my scheme. Actually that wouldn't work: vBLG would be a vertical v- form of the current   (uxHSTRbm). So easy to forget about non-rail stuff. Ultimately, though, I think r/l are good enough (-L/-R means that you only have "half" the default form). Circeus (talk) 18:25, 26 November 2011 (UTC)
Lets consider, then, also   (uxHSTRbm),   (uxSTRbm), and   (uxHSTRbu) — the more the merrier! -- Tuválkin 02:36, 27 November 2011 (UTC)

As I see it, we have three different topologies here, regardless of the lil’ house geometry being identical in all cases or not, and/or identical to   (BUILDING) or not:

  •   (uxSTRbm)   small house on the track/canal
  •   (lBLG-L)    small house on the opposite side of either   (v-STR) or   (vSTR-)
  •   (BUILDINGr) small house on either side / both sides of a regular line   (STR) (this includes   (uxHSTRbu))

Once we agree that these three situations are all needed and different, we can discuss their names (moving to Talk:BSicon/Renaming, please!) and their possible common and distinguishing aspects. Agreed? -- Tuválkin 02:36, 27 November 2011 (UTC)

Agree. I hadn't considered the size/scale aspect. Useddenim (talk) 00:24, 28 November 2011 (UTC)

Lines in tunnel[edit]

BSicon tCODING.svg

Ideally, the background should show through everywhere on an icon, except where the line actually is; as shown by the green example:

<path d="M 45,-25 V 575 M 105,-25 V 575" 
   stroke="#color" stroke-width="40" stroke-dasharray="50" fill="none" />

However, this is not always possible (particularly with curved paths), and oftentimes editors have resorted to a 100px dashed line overlaid by a 20px solid line, illustrated in red. (Note that the default background colour for BS icon route diagrams is   f9f9f9  , not   white  .)

A better result can be obtained if the masking is contained within the track line, depicted here in blue:

<g stroke-width="100" stroke-dasharray="50" fill="none">
   <path d="M 250,-25 V 575" stroke="#colour" />
   <path d="M 250,-25 V 575" stroke="#f9f9f9" stroke-width="20" />

where the group element defines the overall colour and dash array, and the mask contains its own specific overrides.

Hopefully this is helpful and of interest. Useddenim (talk) 01:13, 28 December 2011 (UTC)

Yes, it is. -- Tuválkin 02:09, 30 December 2011 (UTC)

Design of the gapped lines at icon edges[edit]

extSTR extSTR utSTR utSTR
extKRWl+l extKRWr+r utKRWl+l utKRWr+r
extSTR extSTR utSTR utSTR
xtKRWgl xtKRWg+r
uetKRWgl + uetKRWg+l
BSicon uetKRWgl.svg
uetKRWgr + uetKRWg+r
BSicon uetKRWgr.svg

I think I understood that the ideal design of these tunnel icons is to have the 50px blocks cut in half (25px on each side) when lines cross icon edges at 90°, is that right? Meaning all icons showing otherwise are unperfectly design and should be fixed sooner or later? -- Tuválkin 03:01, 15 January 2013 (UTC)

This point illustrated on this mock diagram →, with pink one being correct and the blue one needing a fix in the curve in order to look smooth. (Of course the center of the pink icons needs to be worked on to match, maybe changing 50 to slight more, or less.) -- Tuválkin 04:42, 15 January 2013 (UTC)
Yep, stroke-dasharray="46.875" does the trick. Will fix. -- Tuválkin 04:54, 15 January 2013 (UTC)
Even better, stroke-dasharray="53.125" unclutters the middle of the crossing (i.e. the icon edge where the line meets not orthogonally) and is exactly the same deviation from 50 as above. Will fix now. -- Tuválkin 05:21, 15 January 2013 (UTC)
Basing on this, I overwrote (and expanded) all simple KRW-junctions, e.g.   (xtKRWgr). I used stroke-dasharray="50,56.75", because it is easier to have all strokes 50px long, and to variegate the length of gaps. It is really quite fortunate that in contrast to ÜW-junctions, here we can have perfect crossings and perfect shifts at the same time. YLSS (talk) 23:50, 30 October 2013 (UTC)

Curves in tunnel[edit]

Btw, there is a section above #Lines in tunnel for the similar matter, but I hope a new section would be more helpful.
tSTR BSicon .svg BSicon .svg tSTR
tSTR2 tSTRc3 tSTRc2 tSTR3
tSTR2+4 + tSTRc2
BSicon tSTR2+4.svg
tSTR3+1 + tSTRc3
BSicon tSTR3+1.svg
BSicon .svg
tSTR+1 + tSTRc1
BSicon tSTR+1.svg
tSTRl+4 + tSTRc4
BSicon tSTRl+4.svg

Since the number of 45° icons have been growing fast, and I notice there are more tunnel versions of them emerging, I think I should take a chance to document what I have learnt from creating curved tunnel icons.

First, it is actually possible to not add the little white segments between dashes. This effect was actually done by masking in SVG to not to render the middle strip of curve. Check out the code of   (tSTR2) if you are interested. However, since the wiki renderer is not perfect about the syntax of masking, I had been trying for a few times to make things right.

Second, unfortunately there are no standard way to dash the track so far. This is further complicated by the fact that the curves are unlikely to have lengths of multiple of 50, which works perfectly for straight tunnels. For example, the ÜW curve of   (tSTR2) "M250,0 C250,250 375,375 500,500" has a length of approximately 577.75719 from edge to corner. The diagonal line of   (tSTR2+4) has a length of approximately 707.10678. When I first created tunnel versions for ÜW, I simply used 577.75719/12 = 48.146 for its dasharray, and, later when the diagonal track appeared, spent some hard time to figure out what kind of dashes would look natural. Yet, for icons from other authors, they could have some other geometries that would not fit nicely. My advice for new authors is to find out the actual numerical length of the Bézier curves or circular arcs, and decide what dasharray and dashoffset would be suitable.

Anyway, I could just be too picky on the dashes, and I don't think there are urgent needs to convert all the existing ones to a standard. I only want to share my experience when I made those tunnel ÜW icons and hope the future ones would fit better. Peterwhy (talk) 18:50, 10 March 2013 (UTC)

tSTR2 + tSTRc2
BSicon tSTR2.svg
tSTR3 + tSTRc3
BSicon tSTR3.svg
tSTR+1 tSTR+4
tSTR+1 + tSTRc1
BSicon tSTR+1.svg
tSTR+4 + tSTRc4
BSicon tSTR+4.svg
intersect at coloured dash
extSTR2 extSTR3
extSTR2 + extSTRc2
BSicon extSTR2.svg
extSTR3 + extSTRc3
BSicon extSTR3.svg
extSTR+1 extSTR+4
extSTR+1 + extSTRc1
BSicon extSTR+1.svg
extSTR+4 + extSTRc4
BSicon extSTR+4.svg
intersect at transparent dash
utSTR2 utSTR3
utSTR2 + utSTRc2
BSicon utSTR2.svg
utSTR3 + utSTRc3
BSicon utSTR3.svg
utSTR+1 utSTR+4
utSTR+1 + utSTRc1
BSicon utSTR+1.svg
utSTR+4 + utSTRc4
BSicon utSTR+4.svg
intersect at coloured dash
utSTRlf utKRZt tKRZt tSTRq
(compare with tKRZt)
(and utKRZt)
uextvSTR2- uextv-STR3 d uextdSTRc2 uextv-STR3
with 20px gap
uextvSTR+1- uextv-STR+4 uextvSTR+1-
uextdSTRc4 + extv-STR3
BSicon uextdSTRc4.svg
extvSTR2- extv-STR3
d + extvSTR+1-
BSicon d.svg
extdSTRc2 extv-STR3
extvSTR+1- extv-STR+4 extvSTR+1- extdSTRc4 d
with 50px gap
utABZ23 c
uextSTR + utABZ23
BSicon uextSTR.svg
c utABZg23
utABZ23 vs. utABZg23
Peter, thanks for this. I will surely be coming back to this section over and over whenever I need to (re)create a tunnel icon and need an accurately drawn model.
One question: Which do you consider better —   (extSTR2) or   (utSTR2)? While the stub end is good (half a dash), the corner end of these two is different (slight difference in dasharray), resulting in different central “keystones” where they meert. It is important that this is identical for all icons for smooth matching. -- Tuválkin 01:29, 12 March 2013 (UTC)
IMHO,   (extSTR2). Useddenim (talk) 14:52, 12 March 2013 (UTC)
Same,   (extSTR2), but only without the corner piece overlaid. The right ones are with overlay corners. Peterwhy (talk) 16:17, 13 March 2013 (UTC)
I've redrawn   (utKRZt) with "perfect" corners at the crossing, for comparison. Useddenim (talk) 13:29, 14 March 2013 (UTC)
Here I actually think   (tKRZt) one is better, and a simpler code means easier to code and more consistency (hopefully). Peterwhy (talk) 14:22, 14 March 2013 (UTC)

Peterwhy, you're a genius! x="-100" y="-100" width="1200" height="1200" is a good workaround for librsvg bug that frustrated me so much! And also a note for those who would wish to use masking: make sure that mask="url(#smth)" stands in another element (possibly at an outer level) from any stroke-dasharray's & stroke-dashoffset's. In   (uetABZgr+r) I used both masking and Redrose64's suggestions below. YLSS (talk) 19:36, 13 October 2013 (UTC)

uextvSTR2- uextv-STR3 d uextdSTRc2 uextv-STR3
uextvSTR+1- uextv-STR+4 uextvSTR+1-
uextdSTRc4 + extv-STR3
BSicon uextdSTRc4.svg
extvSTR2- extv-STR3
d + extvSTR+1-
BSicon d.svg
extdSTRc2 extv-STR3
extvSTR+1- extv-STR+4 extvSTR+1- extdSTRc4 d

Basing upon the discussion above, I decided to experiment and now present you with two options. The "uex" curves to the right intersect at a tight spot with 20px between the coloured strokes (just like in Useddenim's "ex" version above). When this is used only for a shift, without intersection, this doesn't look as good, and this is perceptible even at 20px size. Below are new "ex" versions, in which the gap at corner is the standard 50px and the "shift" is perfect; in case of intersection, the result is the same as   (tKRZt) rotated by 45°. (In this case the "extÜWc#" degenerate into two tiny triangles, less than a pixel in size at 20px scale and possibly omittable.) I prefer the second option slightly more than the first; what do others think? YLSS (talk) 21:47, 19 October 2013 (UTC)

Anybody? I'm dying to re-upload them with a common design! YLSS (talk) 21:33, 22 October 2013 (UTC)
Personally, I prefer the “perfect” corners of (uextvÜW) with 20px gap, but since the 50px gap is the accepted design for the 90°   (tKRZt) crossings we should probably use (extvÜW). Useddenim (talk) 00:13, 23 October 2013 (UTC)
Well, let's then consider this matter settled: tSTR#s should have their last stroke terminating at 25px before the corner, measured diagonally, while tÜWc#s should look like two tiny ears  . YLSS (talk) 23:51, 7 November 2013 (UTC)

Next issue. In   (utABZ23) I used stroke-dasharray="50,55.7" to achieve the result described above, and everything looks fine. When I added a vertical track in   (utABZg23), the over-shifted strokes of the curves came into dissonance with the strokes of   (utSTR), and the result didn't look fine. In order to compensate this, I used stroke-dasharray="50,50,50,50,50,50,50,59,55,59.4,55", so that the first four strokes are 50px long with 50px gaps, and afterwards - when the curve deviates enough from the vertical - the gaps are 59px long, and the strokes are 55px long. IMHO, this looks better; check pt:Linha Azul (Metropolitano de Lisboa). However, this bring another question: Tuválkin, AFAIK, is a proponent of the idea that an icon should look exactly the same as the result of overlaying its parts, but in this case the strokes won't overlap. Is that OK? In the end, this is the ultimate purpose of creating complex icons rather that satisfying one's self with |O1= ... |O15= .... YLSS (talk) 23:51, 7 November 2013 (UTC)

✓ Done with (uextÜW) series (except for some icons with portals which still puzzle me). YLSS (talk) 11:32, 4 May 2014 (UTC)

✓ Ditto with (utÜW) series. YLSS (talk) 14:21, 10 July 2014 (UTC)


was uextSTR14lra
was uextSTR14lr
BSicon uextSTRc23.svg was uextSTR14lrl
BSicon uextSTRc1.svg BSicon uextSTR14lr.svg BSicon uextSTRc4.svg

I guess these three were intended to work together, but remain unused. The middle one has full rights to live, but at 20px there is no perceptible difference between   (uextSTR14lrr) vs.   (uextÜWc1) and   (uextSTR14lrl) vs.   (uextÜWc4). Deletion candidates? YLSS (talk) 20:02, 9 April 2013 (UTC) (Added uextSTR14lra. If the central one is redrawn, this one can be salvaged as   (uextÜWc23). YLSS (talk) 21:17, 9 April 2013 (UTC))

Symbol support vote.svg Support. And   (uextSTR14lr) should probably be redrawn to use the standard geometry of   (uÜWu4) and   (uÜWu1). Useddenim (talk) 20:08, 9 April 2013 (UTC)
✓ Done Useddenim (talk) 01:20, 13 April 2013 (UTC)
✓ Done uextSTR14lra →   (uextÜWc23) as well. YLSS (talk) 10:13, 13 April 2013 (UTC)
uextSTR2+4 uextSTRc23 uextSTR3+1
utSTR2+4 + uextSTRc1
BSicon utSTR2+4.svg
uextSTR14lr + utSTRc23
BSicon uextSTR14lr.svg
utSTR3+1 + uextSTRc4
BSicon utSTR3+1.svg
utSTRc1 utSTR14lr utSTRc4

Check this example: → I think Useddenim drew the corners of   (uextSTR14lr) slightly incorrectly, not a perfect match as continuation of the curve past the portals, as intended. I created   (utSTR14lr) with the tunnel bits taken from   (utSTR3+1) and   (utSTR2+4) (minor incorrections as the the tunnel stretches are straight, not curved). The result is not a perfect match, though, because many tunnel icons were not drawn well enough to match, as discussed elsewhere. -- Tuválkin 19:27, 20 May 2013 (UTC)

Okay, I changed the tips of the tunnel track at the corners and made the portals round in   (utSTR14lr), and it is now reflected in the diagram at the right (clear cache!). Opinions? -- Tuválkin 14:48, 11 July 2014 (UTC)
WRT corners, top notch! WRT portals, moved everything here. YLSS (talk) 17:51, 11 July 2014 (UTC)

Tunnel geometry on 90-degree curves[edit]

tABZq+l tABZq+r
tABZql tABZqr
extABZq+l extABZq+r
extABZql extABZqr
uextABZ+lr uextABZr+r
uextABZl+l uextABZlr

For some time I've found the appearance of some of the tunnel icons (those like   (tSTR) etc.) unsatisfactory: there are inconsistencies in several characteristics, such as the mark length and the mark/space ratio (both controlled by the stroke-dasharray property), and the mark offset (the stroke-dashoffset property}. For example, on   (tABZql), the straight track has stroke-dasharray:48 and there is no stroke-dashoffset. This means that at one end, there is a full mark 48px long; at the other is a partial mark 20px long - less than half the size of a full mark. The four icons in red at right show some of these inconsistencies.

Many of the tunnel icons use stroke-dasharray:50;stroke-dashoffset:25 in the straight track which gives a half-size mark at each end flanking four whole marks - it's neat and symmetrical. With this in mind, I've calculated optimum measurements for icons like   (tSTRlf). Given that the cell width is nominally 500, and the quarter-circle is thus radius 250, it can be shown that the arc length is 392.699 - this is quite close to 400, so with five marks and five spaces along the straight track, a quarter-circle should have four marks and four spaces. The inner ring of dashes (radius 220) is stroke-dasharray:43.197;stroke-dashoffset:21.598; and the outer ring (radius 280) is stroke-dasharray:54.978;stroke-dashoffset:27.489; Using these measurements, I've redrawn   (extABZql) and created   (extABZqr)   (extABZq+l)   (extABZq+r) which didn't previously exist. The four icons in pink at right demonstrate the improvement. Opinions? --Redrose64 (talk; at English Wikipedia) 17:11, 12 October 2013 (UTC)

Great thanks, this has long bugged me! I can only add that one digit after the point would be more than enough (OK, two for dasharray) (43.2, 21.6, 54.98, 27.5 respectively); and that if it is desired to use #F9F9F9 masking for the central line, the numbers are stroke-dasharray:49.09;stroke-dashoffset:24.5 (392.699 / 4 ≈ 49.09, 49.09 / 2 ≈ 24.5), see the "uex" group to the right. BTW, do not test such things in Chrome, it is somewhat buggy; Mediawiki's librsvg, IE and Firefox seem to be OK. YLSS (talk) 19:50, 12 October 2013 (UTC)
One decimal place of decimal would give an error of 0.4 pixel on the complete circle, and two decimal places would give an error of 0.08 pixel, with the 3-o'clock mark being too small by that amount. By contrast, three decimal places would give an error of -0.012 pixel, so the 3-o'clock mark is a tiny bit too large. Either way, it's not much, but I like to get as close as possible without going to extremes: there's an infinite number of decimal places on the exact calculation, since the exact mark size would be 250*π/16 on a 250px circle.
Leaving that aside, I saw the post of YLSS 19:36, 13 October 2013 (UTC), and it's helped me with my original intent - I couldn't get the <mask> element to work, now I see that you need a big white rectangle to make everything opaque that is not masked. Accordingly, I've redrawn   (extABZql) again, using two paths instead of four, with masking to give a clear space down the middle of both paths even where the strokes overlap. There's a subtle change to the shape of the marks which make up the two circles, that makes them even neater. --Redrose64 (talk; at English Wikipedia) 14:12, 14 October 2013 (UTC)
Much better! (I've also been having a hard time making tABZ icons look good.) Useddenim (talk) 00:04, 15 October 2013 (UTC)
No complaints, so I've redrawn the other three pink icons so that there is a complete transparent circle in the middle group at right.
I did all of this in a plain text editor, checking the results in Firefox; after I finished, I loaded one of them into Inkscape - but with strange results. It recognises the fill="white" (opaque) part of the mask, but not the stroke="black" (transparent) part. --Redrose64 (talk; at English Wikipedia) 17:40, 17 October 2013 (UTC)
All this masking, though handy, requires a lot of double- and triple-checking. I have now encountered another bug (?) in that sometimes a mask renders invisible a large section of the object it is applied to, far more than intended, and this shows up in Chrome, Firefox and IE. The workaround is to add an additional e.g. M 500,0 at the beginning of d in the path element (see e.g.   (uextvSTR+1-)); this solves the issue everywhere except in Firefox. Possibly this isn't a bug, but some coordinate conversion? YLSS (talk) 18:18, 17 October 2013 (UTC)
uetABZgr+r utABZ3x2

A related question. I've been uploading icons with the following notion: when in junctions a normal track crosses an unused one, not only it is drawn "on top" of it, but also it is not affected by the transparent middle of latter. That is, the unused track is affected by two masks (from both tracks), but the normal track is affected only by its own. Is that OK? YLSS (talk) 18:18, 17 October 2013 (UTC)

etKRWgl c
(by Useddenim)
uetABZg2 c
(by Xeror)
That’s interesting. I’ve been taking the opposite approach (where possible). Useddenim (talk) 04:03, 18 October 2013 (UTC)
Well, I wouldn't call that an opposite; cf. Xeror's ÜW-junctions. YLSS (talk) 16:55, 23 October 2013 (UTC)
My own feeling is that where lines are the same colour - as with   (extABZql) - there should be a clear gap along both lines. Where lines are different colours, the "primary" colour (red in the case of e icons, or dark blue in the case of ue icons) should have a normal-looking appearance, and the "secondary" colour (pink or light blue) should be broken as necessary to give a clear gap along the centre of the primary; this is illustrated by   (uetABZgr+r) where the light blue is masked but the dark blue is not. --Redrose64 (talk; at English Wikipedia) 18:14, 23 October 2013 (UTC)
My 2¢ worth is that I prefer the out-of-use line showing through the masking (  (etKRWgl), but I can certainly live with out-of-use masked by both (  (uetABZgr+r). Useddenim (talk) 02:19, 24 October 2013 (UTC)

For the record: 90° curves in tunnel were mostly finished up by Sameboat in January 2014. YLSS (talk) 16:23, 11 July 2014 (UTC)

Transparency/masking in elevated icons[edit]

uSTR3+1 + hSTR2
BSicon uSTR3+1.svg
uSTR3+1 + hSTRl+4
BSicon uSTR3+1.svg
BSicon .svg BSicon .svg BSicon .svg
STR3+1 + uhSTR2
BSicon STR3+1.svg
STR3+1 + uhSTRl+4
BSicon STR3+1.svg

Also,   (hSTRl+4) has the gap filled with mask color while   (hSTR2) has true empty gaps — compare BSicon uSTR3+1.svgBSicon hSTRl+4.svg (hSTRl+4uSTR3+1)  and BSicon uSTR3+1.svgBSicon hSTR2.svg (hSTR2uSTR3+1) . I’m not sure which is better, but we need to decide which is (or, if both are good, then develop parallel namings for each elevated icon with and without mask.) -- Tuválkin 00:03, 31 March 2012 (UTC)

Don't we usually use a separate mask icon? I mean, since we're already overlaying anyway at this stage! Circeus (talk) 05:41, 31 March 2012 (UTC)
Yes, but this is tricky. On one hand we agree (I think) that the gap between the track/line and the bridge rail or the elevated “formation” marker paralel to it is really a void and that the background color should show through, even when it is not the default (and thus using masks may cause unexpected results in diagrams with non-default background colors).
On the other hand we agree (I think) that other lines/tracks crossing under another should not show through the said the gap — meaning it is not transparent.
Seems that these two assumptions are irreconcilable and should be reevaluated: Either it is transparent and thus both non default background colors and under-crossing tracks show through, or it is non transparent, solid on the default background color. Neither option is clean, and both would mean extensive fixing of existing icons if taken to perfect exactitude.
-- Tuválkin 19:49, 15 April 2012 (UTC)
There are already some icons without track where   (FRM) (FoRMation) has the background mask, and a matching   (NUL) version is transparent. Useddenim (talk) 00:05, 16 April 2012 (UTC)
I noticed, but I assumed that was random variation. But if that is intentional, if there’s a qualitative difference between masked and non masked elevated trackbeds (and bridges), does that mean that there should be separate sets of masked and non-masked icons with track? (I hope not, but still asking.) -- Tuválkin 00:23, 16 April 2012 (UTC)
I forgot to note this, but most (if not all) of the older (leer) icons are also transparent. Useddenim (talk) 10:34, 17 April 2012 (UTC)

Shape of zeros[edit]

BSicon .svg
num0l + num0r
BSicon num0l.svg
BSicon .svg
BSicon .svg
numOl + numOr
BSicon numOl.svg
BSicon .svg

Why are   (num0l) and   (num0r) shaped so differently? They should be identical, right? Here’s on the right for compare they both, and the pair of ohs from the same series. The difference is not very big but it shows big when the icon is resized to 20 px — which is actually the most used size. -- Tuválkin 08:38, 30 April 2012 (UTC)

Replacing white masks with dashing[edit]

moved from Category talk:Icons for railway descriptions#Replacing white masks with dashing
vÜWBl uvÜWBl
All good if the background is white anyway
exvABZq+rl + vÜWBl
BSicon exvABZq+rl.svg
exvABZq+rl + uvÜWBl
BSicon exvABZq+rl.svg
Overlaid on other icons, white shows.
vÜWBl uvÜWBl
On funky background, white shows.

Please compare newly modified   (vÜWBl) with (still) untouched   (uvÜWBl), for instance, or the many other icons with bridges which use a wider white path/shape under the above-track to “hide” the under-track in the bridge gaps.

Ditching this white mask and creating actual gaps in the under-track using SVG style stroke-dasharray is the way to go to make these icons clean and usable on any background — both in terms of diagram background color but also to allow underlaid icons to be seen through.

It will take lots of work, though…

--Tuvalkin (talk) 06:04, 3 September 2011 (UTC)

The background colour on diagrams is actually hex f9f9f9:
Useddenim (talk) 11:11, 3 September 2011 (UTC)
One more reason to avoid white as faux transparent. --Tuvalkin (talk) 11:49, 3 September 2011 (UTC)

The trick is to use the bridge strokes to cover the often untidy “cuts” that occur when the two lines cross not orthogonally — extreme example is   (vKRZl-KRZru). --Tuvalkin (talk) 11:49, 3 September 2011 (UTC)

Dash-array is a very good method to get rid of whitened areas, I started using this at least three years ago, e.g. File:BSicon WBRÜCKE.svg. Regards a×pdeHello! 12:16, 3 September 2011 (UTC)

And you wanted to keep it a secret, huh? ;-) --Tuvalkin (talk) 12:41, 3 September 2011 (UTC)
Ähm, nö. I thought every knew by the t-BSicons ... :-} a×pdeHello! 22:11, 3 September 2011 (UTC)


“Funny” how   (vÜWBr) is again showing a white mask (defeating the whole argument above), and its history doesn’t even show a revertion… -- Tuválkin 08:29, 5 June 2012 (UTC)

Doh, sorry about that. The guinea pig for dasharraw was   (vÜWBl) instead. Very sorry! -- Tuválkin 08:34, 5 June 2012 (UTC)

Dash-array with commas, not spaces[edit]

In spite of the SVG stroke-dasharray specs, Wikimedia likes it only when the dash-array arguments are comma-separated, not space-separated. Cf. this discussion.--Tuvalkin (talk) 11:49, 3 September 2011 (UTC)

Bridges need white space[edit]

(From talk on one bridge) Bridges need white space otherwise when overlapping on other roads it looks wrong. Examples are:

Old versions (see history of this and G2u) were correct. But after some moment after some useful changes white space disappeared which makes impossible some things. So adding white space is profitable. If it makes something wrong in real templates - please show real example (of real road). If it exists, the correct way is create second version of such icons, for example with suffix 'w' to handle both real cases. MUR (talk) 19:55, 30 September 2012 (UTC)

Arguments for version with white space: in the picture above: when added white space:

  • it is added too widely, it is incorrect, White space only needed in the place, where real bridge exists.
  • If to see on the bridge: some pink thing is seen thru bridge, but the railway under bridge is NOT! It is not physically correct - either both must be seen (and red railway ON above of that pink) or none of them.

MUR (talk) 20:01, 30 September 2012 (UTC)

Read the arguments above explaining how faux “white” masks instead of actual transparency is a bad idea. What I see so far is someone who adds it to established icons with no prior discussion, then undoes the reversion that fixed the affected icons, again without discussion.
Stop at once. Discuss instead. Discussing means hearing what others have to say, and pose your questions, not just making demands. Damands like this, which go against established practices and which as presented in the way you did, are not going to be met with the acceptance you presume.
Concerning the matter you raise, and after puzzling at your unwholesome linking as done above to find out it is one and the same RDT (ru:Шаблон:Кубинка_I_—_Михнево), I think I understand that you mean situations such as those in Калужское шоссе, an overlap of   (SKRZ-G2u) on   (eABZ2). Something like is as as single icon (as opposed to two stacked icons in separate diagram rows — remember a diagram is not a map) should be made with a new icon, to be named   (eABZ2+G2qu). (As for Киевское шоссе and Никольский пр., that seems just wrong. NB that this diagram is riddle with mistakes, such as KRW instead of STR/ABZ in the level cross next to Бекасово-1.)
-- Tuválkin 21:55, 30 September 2012 (UTC)
As for links. Second link is Шаблон:Икша — Кубинка I, it is different. There is usage of G4 in it. As for new icon   (eABZ2+G2qu) - I think you understand that it is impossible to do all combinations in all cases - it will lead to huge multiplication of variants. So for rare cases Overlapping is created, and these are rare cases. With just these white-space bridges I can use many variants of road under bridge w/o creating new file each time (moreover creating of such new files every time is very time-consuming, I'm not professional or even novice in graphical editors, but I want to spend my time on creating real templates w/o creating new images- overlappings help me a lot in this).
Please answer my question - give example of real road, where effect of transparency is needed. If it exists (or maybe even not exists but there will be no consensus by some reason), it is logically natural to create just separate icons that will not disturb all schemes that use old variant.
>NB that this diagram is riddle with mistakes, such as KRW instead of STR/ABZ in the level cross next to Бекасово-1.
Yes, there was mistake (because initially there was scheme w/o BUE, then I inserted it and forgot to change to ABZ/STR, and it is not seen by simple view) - thank you, I have corrected it. Do not know what is 'riddle'... MUR (talk) 22:14, 30 September 2012 (UTC)
>(As for Киевское шоссе...
With this I show that bridge is widened and rail line on it is separated BEFORE it left the bridge. If there is another icon(s) to show this thing nicer, please give it and I can use them. MUR (talk) 22:19, 30 September 2012 (UTC)
There is a full set of icons (  (BRIDGE), (  (BRIDGElr), (  (BRIDGEq) etc.) that all have a mask. They are at en:Wikipedia:Route diagram template/Catalog of pictograms/others#Bridges, portals, overpasses and other formations. If you still canot create what you need with them + overlays, please let me know what you need. Also, you are trying to push too much information together into too small a space – use more rows in complicated areas. Useddenim (talk) 23:28, 30 September 2012 (UTC)
Oh, thank you, I did not know that they have a mask (Isn't it incorrect according to Tuvalkin's concept?) - I'll try to use them with overlapping of a road (the only problem may be that all kinds of road - at least G2 and G4 are to be fit inside these bridges). Yes, I'm trying to push real information. But maximum width is BS9 by documentation, so I should fit it. Bu also I followed an implicit rule that main line must be in the middle, I'm going to cancel this and shift it left in Bekasovo to insert some BUEs (they occupy a whole cell though they are small comparing to the whole sorting station) and bridges across STR+RP1 (this will occupy two cells, but I do not know a better way except overlapping one of two parallel lines (making single to such only to go under bridge) AND new RP1 that is shifted to the place of other parallel line). MUR (talk) 07:03, 1 October 2012 (UTC)
The BRIDGE icons were created specifically for use with overlays. I will add some v-width ones when I have the time. Also, have you considered using half-width (d-series) icons? (One example of mixing regular and narrow icons is at en:Template:Crewe Works—note particularly the traverser row—and most RDTs on nl:Wikipedia use them exclusively.) The catalog pages are at en:Wikipedia:Route diagram template/Catalog of pictograms/narrow icons/straight, en:Wikipedia:Route diagram template/Catalog of pictograms/narrow icons/junctions, and en:Wikipedia:Route diagram template/Catalog of pictograms/narrow icons/stations. Useddenim (talk) 10:53, 1 October 2012 (UTC)
I will look at 'd'-series. But from first glance it is restricted: it has not all icons (does not have "generic roads" for example) and normal icon can not be overlapped on two d-icons. And for example if I want to make bridge with rail+road under it, it is from first glance not simpler than overlapping normal icons. Of course, when I want to draw more than 9 lines in width - d-icons may help. MUR (talk) 17:04, 1 October 2012 (UTC)
I have changed both my examples, where 2-line roads are on the bridge, it works, thank you! (though similar bridges look differently (at least q-versions) - maybe mask bridge needs change:   (SKRZ-G2u)   (BRÜCKEq legende). I forgot where I've seen 4-line road which needs this trick, but I will definitely need it in one railroad cross near "Детково" in my first example (there are two bridges now, but real situation is one bridge with line separating under bridge). With such bridges it is easy to create wide bridges - just move/rotate them. MUR (talk) 19:34, 1 October 2012 (UTC)
  (vBRIDGE),   (BRIDGEv),   (vBRIDGEq) and   (BRIDGEvq) added. Useddenim (talk) 03:39, 2 October 2012 (UTC)


Too realistic, axis-dependent, and too cluttered for 20px.

I’m not really convinced that   (HBKq) has an acceptable geometry as it is right now. A non-q version of it (as needed and asked-for here) makes this even more evident. I’d rather see a variation of   (WBRÜCKEq), with some stylized difference. -- Tuválkin 23:51, 29 June 2012 (UTC)

The design came from this:
France road sign A6.svg
The problem stems from the fact that the bridge's movement is along the z-axis, whereas the icons are on the x-y plane. Got any better suggestions? Useddenim (talk) 12:12, 30 June 2012 (UTC)
I dont have any good suggestions, and I’m not sure whether those I have are any better. Anyway, your analysis is spot-on and I think it agrees with my critique. -- Tuválkin 15:25, 30 June 2012 (UTC)
Also, I come to notice that the same critique applied to other also-cluttered unusual bridge icon,   (DBK). -- Tuválkin 15:50, 30 June 2012 (UTC)
BSicon c.svg
d + dLSTRq
BSicon d.svg
Hm, my only suggestion that fits my own criticism of the current design: Make an regular bridge icon with the track line interrupted in the middle with a single lücke-style spot (like the one here at the right → but transparent instead of dark blue, in the middle). It can be colored (black, formation color, or line color) or reshaped (disc, square, diamond?) to reflect any possible variants (drawbridge, swing bridge, lift bridge).
The idea behind this is to use clear design differences that can be seen at 20px based on non-naturalist iconic stylization — after all, since real stations   (BHF) are not round, funny bridge icons don't have to look like they real life counterparts, right?
-- Tuválkin 15:50, 30 June 2012 (UTC)
BSicon BRK!.svg
Does   (BRK!) and   (uBRK!) fit the bill? (And yes, I just realized that the first one is a q version…) Useddenim (talk) 03:11, 1 July 2012 (UTC)
While I was fleshing up in these ideas, I was not the only one doing it! ;-) Meanwhile, we all want to look at this Category:Animations of bridges — not only because it is cogent (limiting all these to those used for rail), but so we know we’re not the only ones creating useful and fun images for Wikipedia! -- Tuválkin 05:06, 1 July 2012 (UTC)

I just found out (here) that there are other designs in use for this:   (uAKRZuba)   (uALIFTu)   (uASWINGu)   (ugLIFT)   (ugSWING)   (uHSWING)   (uKRZuyba)   (uKRZuysw)   (uLock5SWING) and more. -- Tuválkin 23:44, 8 July 2012 (UTC)


So, my idea is to have icons for “conditional bridges” (swing, draw, lift) that look good at 20px and match the existing icons better than current   (HBKq) and   (DBK). I propose the design of two gaps in lücke style on an otherwise unchanged   (WBRÜCKE), with the three ersatz dots colored to denote the status of feature unused (i.e., line in use on formely conditional bridge stuck in the open-for-rail position) and/or any of said dots colored   formation  to denote assymetry of the bridge arrangement (or emphasize symmetry), as deemed necessary.

Proposed: Replace?      Proposed: Replace?      Proposed: Replace?
BSicon HBK(!).svg (eqv. triv.) BSicon eHBK(!).svg (eqv. triv.) BSicon exHBK(!).svg (eqv. triv.)
BSicon HBK(!)q.svg BSicon HBKq.svg BSicon eHBK(!)q.svg BSicon eHBKq.svg BSicon exHBK(!)q.svg BSicon exHBKq.svg
BSicon HBK(!)m.svg BSicon DBK.svg BSicon eHBK(!)m.svg BSicon eDBK.svg BSicon exHBK(!)m.svg BSicon exDBK.svg
BSicon HBK(!)e.svg (no eqv.) BSicon eHBK(!)e.svg (no eqv.) BSicon exHBK(!)e.svg (no eqv.)
BSicon HBK(!)a.svg (no eqv.) BSicon eHBK(!)a.svg (no eqv.) BSicon exHBK(!)a.svg (no eqv.)

Will add a sample mock diagram for realistic testing. Opinions?-- Tuválkin 05:53, 1 July 2012 (UTC)

Other advantages of this porposed design:
  • It is trivial to create additional icons matching other types of bridges, such as   (BRK3),   (BRÜCKE2),   (BRÜCKE1), and, particularly —   (BRÜCKEa),   (hSTR), and   (BRÜCKEe).
  • It is trivial to create additional icons showing other types of crossed body, as said — not only   (WASSERq), but also   (RP2q),   (uSTRq), and even   (STRq) or   ( ).
  • It is trivial to create additional icons for   (vSTR) (I recomend using formations on adjacent icon cells for these.)
-- Tuválkin 06:36, 1 July 2012 (UTC)
Really, I do not really think a differentiation between normal and moveable bridges is needed; if one wishes to learn more, they can look at the bridges article, or failing that, add a note.User:Deonyi 05:33, 1 April 2014 (UTC)


Maybe   (eHBK(!)) is more intuitive if the line is not broken, as in BSicon STR.svgBSicon eHBK(!).svg (eHBK(!)STR) ? On the other hand it is less visible like this…? -- Tuválkin 10:51, 1 July 2012 (UTC)

I'm sorry, but those varied patterns of gaps and spots of different colours don't suggest "movable bridge" to me, let alone indicating how the bridge moves. I don't see anything fundamentally wrong with our existing icons for a bridge swinging in a horizontal plane, such as   (umKRZuswq). Changing these to something less intuitive just doesn't make sense. We do have two different systems for a bascule bridge orientated left-right, namely   (HBKq) and   (uKRZuyba), but I think we should settle on one or the other and not invent something else. All that we really lack is something for a bascule bridge orientated top-bottom instead of left-right. See Talk:BSicon/New icons and icon requests#Rolling-lift bridge. --Redrose64 (talk; at English Wikipedia) 19:28, 31 March 2014 (UTC)
It looks bad. User:Deonyi 05:33, 1 April 2014 (UTC)


The examples above should have a "W" preffix, sorry about that. Since these are realistically needed only for such bridges over water, all icons should either have a "W" preffix, as said, for rivers (or any body of water in rail diagrams), or a "um" preffix for canal (diagrams). Icons with neither of these would mean (and show) a conditional rail bridge over another rail line (lightrail, if with "u" preffix), an unusual situation. -- Tuválkin 05:53, 1 July 2012 (UTC)

Also, there is no need for an "o" suffix, as these are inherently about the bridge that goes over. -- Tuválkin 06:03, 1 July 2012 (UTC)

The "(!)", of course, is meant to go. -- Tuválkin 10:51, 1 July 2012 (UTC)

SVG of branches[edit]

Most 90° branch icons still have sloppy SVG code (from Inkscape or Corel) and some even have messed geometry (stuff like 98.967 instead of 100.000). One, at least, is however top spec — that’s   (uABZrg). -- Tuválkin 18:41, 19 August 2012 (UTC)


Following the discussion at Talk:BSicon/Renaming#BHFCC & BHF+TUNNEL

Portal location for tunnel entrance at icon edge[edit]

moved to Talk:BSicon/Icon geometry and SVG code neatness/Formations#Portal location for tunnel entrance at icon edge

Transition stations’ design[edit]

[Transition stations] should be drawn as BSicon ulBHF.svgBSicon utSTRa.svg  and BSicon ulBHF.svgBSicon utSTRe.svg . (It doesn't show too clearly, but the tunnel portal spans the station, which is a not-uncommon occurrence. Useddenim (talk) 23:49, 23 February 2013 (UTC)

I agree with the proposed semantics, but the portal probably shows poor contrast for most track colors, surely so for the current lines’ colors as shown above (and not less so for BSicon uexlBHF.svgBSicon uextSTRa.svg  and BSicon exlBHF.svgBSicon extSTRe.svg ). Maybe draw it with white #f9f9f9 outlining to make the station show through, akin to the unusual (but necessary) special icons   (TBHF-Mu) and   (BHFgl+l)? -- Tuválkin 14:20, 24 February 2013 (UTC)
Agreed. Useddenim (talk) 17:59, 24 February 2013 (UTC)


new old
BSicon uextKACCe.svg BSicon uextKACCa.svg
BSicon utKHSTACCa.svg BSicon utKHSTACCe.svg
BSicon utKINTACCa.svg BSicon utINTACC.svg

Strangely enough, there are no ACC icons with neat and clear code (at least, I was unable to find one). The current version of   (lACC) uploaded by Useddenim is more or less close; however, it also has no less than three digits after the point, and relies heavily on Bézier curves where circle arcs would do better. I have uploaded three new icons with code created anew by myself using only Notepad++ (managed to keep them below 1 KB, sans bloated title). These can be seen at the first column; the difference with their already existent counterparts to the right is negligible. So I propose that hereafter the following code should be used (corrections are of course welcome):

 <circle cx="250" cy="250" r="150" fill="#034EA2" />
 <g fill="white">
  <path d="M 199,294 A 57.4,57.4 0 1 0 293,235 L 296,210 A 79.1,79.1 0 1 1 187,319" />
  <circle cx="275" cy="150" r="22" />
 <g stroke="white" stroke-linecap="round" fill="none">
  <path d="M 277,193 268,254.5 H 198 L 164,322" stroke-width="26" stroke-linejoin="round" />
  <path d="M 215,216 H 272" stroke-width="21" />

For HST and INT, 2/3 size seems perfect (currently different icons use different scaling...):

 <!-- for HST -->
 <circle cx="250" cy="250" r="100" fill="#034EA2" />
 <g transform="matrix(0.667, 0, 0, 0.667, 83.3, 83.3)">
  <g fill="white">
 <!-- for INT -->
 <circle cx="250" cy="250" r="120" stroke-width="60" stroke="black" fill="white" />
 <g transform="matrix(0.667, 0, 0, 0.667 83.3, 83.3)">
  <g fill="#034EA2">

--YLSS (talk) 23:03, 11 April 2013 (UTC)

Useddenim has now managed to make things even simpler using stroke-linecap="round" and stroke-linejoin="round", as can be seen at   (lACC). I've updated the code above accordingly. YLSS (talk) 20:32, 25 June 2013 (UTC)
Just checked the new lINTACC BSicon lINTACC.svg uploaded by Useddenim, which has radius 123.5 and stroke-width 53. We are sticking to these values (I believe this is only for the INTACC subset), right? NoNews! 04:34, 9 November 2013 (UTC)
Dunno, I've been uploading with radius="120" stroke-width="60", as discussed above, e.g.   (tINTACC). However, I'm ready to review that. And I would prefer radius="125" stroke-width="50", if so. YLSS (talk) 10:46, 9 November 2013 (UTC)
(FYI. I use radius="125" stroke-width="50" now. YLSS (talk) 12:48, 7 February 2014 (UTC))


moved from Talk:BSicon/New icons and icon requests/Archive 1#Pale ACC icons

For some reason, the ACC series of icon were not originally designed to include pale forms (i.e. the e- and ex- forms), as a result only the ex- series use the dark color on ex- line: this is the x- form! A fair amount of them may need to be adjusted, ranging from   (uexKACCe) to   (exCPICArr). Circeus (talk) 17:47, 7 September 2011 (UTC)

#034EA2 #6281C0 #6592C5 #72A5DF
BSicon uxHSTACC.svg BSicon ueHSTACC.svg BSicon uexHSTACC.svg BSicon exHSTACC.svg

I don't know whether this was ever discussed, but it doesn't feel right that we use the same colour both for regular accessible station and for unused ones. As yet I know of two attempts to break this custom:   (uxHSTACC) &   (ueHSTACC) by Imperator3733 (who used   #6281C0  = uex for exACC colour) and   (exHSTACC) by Newfraferz87 (who used   #72A5DF ). If we apply the standard method to ACC's   #034EA2 , we actually get   #6592C5 . So I uploaded   (uexHSTACC), as well as   (exlHSTACC) &   (exlACC). What do you think, is it worth overwriting existent icons with this colour? (That is, moving them to "xACC" titles and uploading new files instead of redirects at the "exACC" titles.) Cf. en:Template:WMATA Silver Line. YLSS (talk) 12:48, 7 February 2014 (UTC)

Before we go too far down this road (track?), how do we differentiate between a closed accessible station, and a station that is open but is not currently accessible? Useddenim (talk) 13:36, 8 February 2014 (UTC)
Literally, common sense, judging from the state of track. I remember this is the reason that Axp complaint about the existence of   (xBHF) which may or may not make sense. -- Sameboat - 同舟 (talk) 15:07, 8 February 2014 (UTC)
A compromising proposal would be changing the base color of the ACC accordingly to the usual track and station set so there is no concern of creating new set of color. -- Sameboat - 同舟 (talk) 15:11, 8 February 2014 (UTC)
How about   (uxACC), with the same background color for both circle & line? (I propose a black bar for   (xACC).) Useddenim (talk) 17:41, 8 February 2014 (UTC)
For such intricate wheelchair icon to have another big slash over it is difficult to read when downsized. -- Sameboat - 同舟 (talk) 07:02, 9 February 2014 (UTC)
I also consider that red bar extraneous. It's at odds with the whole BSicon philosophy, IMHO. And it looks as if it represents a ban on wheelchairs... That said, I don't ever use ACC icons by myself and voted against using them at ru.wp; so you can disregard my words ;).
However, I generally support the idea of differentiating between an existent station that is going to become (or was previously) accessible, and a non-existent station that will be opened as an accessible one (or was one before its closure). However, we would need a new method of naming such icons, because it would only be consistent to have BSicon exSTR.svgBSicon lACC.svg  at (xACC)! Either we should use something like (ACCx) for what you represented by   (xACC) (in which case   (exHSTACC) will have to be renamed to (exHSTACCx), if we do everything properly); or we resurrect Circeus's proposal:   (ACC) → (BHFA). An existent station with non-existent facilities for disabled could then be called   (BHFxA).
And I like the idea of dropping that #034EA2 background for ACCs and simply marking a station with a wheelchair (like in Useddenim's design, but without the bar). YLSS (talk) 15:55, 9 February 2014 (UTC)
I like the idea for the A/xA suffix. But that still doesn’t really resolve how to show accessible status that is different from the station overall. Useddenim (talk) 16:53, 9 February 2014 (UTC)
I don't think that showing the accessibility status for a non-open station is helpful. If the station is not open, there are often locked gates, fences or other barriers preventing entry by all persons, not just those with accessibility needs. Even if there are no barriers, trains will not be calling and so the station's owners will not be under an obligation to provide accessibility for intending passengers. There are thus three cases: (i) station open and accessible; (ii) station open but not accessible; (iii) station not open. --Redrose64 (talk; at English Wikipedia) 23:48, 9 February 2014 (UTC)
Totally agree. If the editor still wants xACC/xBHFA, s/he should look somewhere else rather than BSicon. -- Sameboat - 同舟 (talk) 00:53, 10 February 2014 (UTC)
You know, purely theoretically, I agree with you. However, you can see by the usage of   (uexACC) and others that people consider these icons useful, so I think we should not proscribe them. Going around and replacing   (uexACC) with   (uexBHF) would be returning to the philosophy of "this thing is impossible, so we should delete it". YLSS (talk) 07:45, 10 February 2014 (UTC)

I'm not against exACC (closed accessible station). The problem is that I don't want to invent new rules to differentiate the availability of ACC over both BHF and exBHF (e.g. BHFxA, existing station without disabled-accessibility). If the ACC is not available to the station, the usual BHF icon suffices perfectly. -- Sameboat - 同舟 (talk) 09:22, 10 February 2014 (UTC)

I'm with sameboat here. For the purpose of diagrams, it seems inappropriate to distinguish between a current station that was never disabled-accessible and one that once was. Circeus (talk) 20:20, 20 February 2014 (UTC)

Red roads[edit]


While on the topic of theses, now might be the right time to raise the issue of their colour and width:

red yellow red yellow
Set red
Set yellow

These changes are illustrated with the existing on the left, and standard colours on the right:

Useddenim (talk) 00:23, 18 June 2013 (UTC)

I’m neutral about changing the colors, but against changing the width — because complex junction icons such as   (MWABZlgu) or   (MWEXrfu) would have to be redrawn from sctatch to match 100px thick roads. -- Tuválkin 12:15, 18 June 2013 (UTC)

Elliptical curves[edit]

moved from #Why blue and red with different designs for the same topology?

While some have been justified, some don’t seem to have a reason to be, such as   (exSTR+r-ABZg+r) vs.   (uSTR+r-ABZg+r) (and maybe others to come to here) — cp.   (exvABZaq+r) vs.   (uvABZaq+r). Why? --Tuvalkin (talk) 14:22, 1 October 2011 (UTC)

I didn't like the curvature of the original, so I made a new design with rounder curves that are closer to   (uSTRlg). I don't see any conflict, as they're not both used in the same diagram. Useddenim (talk) 16:14, 1 October 2011 (UTC)
Part of the "issue" is that blue icons are also created and designed independently by the Canal project members, leading to conflicted designs. Circeus (talk) 17:32, 1 October 2011 (UTC)
In my opinion, all icons should share the same basic geometric “style”; one of the elements of that style is that curves should be (and mostly are) as wide as possible within the icon boundaries, therefore   (exSTR+r-ABZg+r) is right and   (uSTR+r-ABZg+r) is wrong. The fact that some icons tend to be used more for a given subset of of diagrams (either by usage or by language version of wp) is immaterial and justify stylistic variation based on it defeats the goal of centralizing these icons under a single family in commons. --Tuvalkin (talk) 19:10, 1 October 2011 (UTC)
I'm not justifying, I'm explaining. Similar issue plague the AKRZ icons becaus eof different u- designs. Circeus (talk) 19:33, 1 October 2011 (UTC)

Bezier curve

I’ve never been particularly fond of the elliptical curves used for the non-circular 90° turns. What are others’ opinions of this alternative design that uses Bezier curves and a “straighter” connection to adjacent icons? Useddenim (talk) 01:11, 6 December 2013 (UTC)

uexSTRl-   uexSTRl-!
uexSTR BSicon .svg uexSTR BSicon .svg
uexSTRl- uexSTRq- uexSTRl-! uexSTRq-
uexSTR BSicon .svg uexSTR BSicon .svg
uexSTRl- + uexSTRq-
BSicon uexSTRl-.svg
uexSTRl-! + uexSTRq-
BSicon uexSTRl-!.svg
Yup, I also found them ugly. For simple small curves, your design looks better, IMHO. However, for junctions with a straight track, especially if there are curves from both sides, not very much of a curve can be seen. Maybe we should use different designs? Also, what about   (uex-STRl)? YLSS (talk) 08:00, 6 December 2013 (UTC)
  (uex-STRl!) (Bezier curve) or   (uex-STRl!!) (circular curve). Useddenim (talk) 04:55, 7 December 2013 (UTC)
I've got no problem with elliptical curves. After all, a circle is a special case of an ellipse, and we've been quite happy for several years using circles in   (STRlf) etc. --Redrose64 (talk; at English Wikipedia) 17:02, 6 December 2013 (UTC)
Of course, circles are ideal! They have a constant radius of curvature, namely 250px. For "small" ellipses like   (uexSTRl-), the radius of curvature at the top is 75px – too steep! For   (uex-STRl), it is 166.7px at the right edge – tolerable, but the gentle 250px would be better still. YLSS (talk) 19:03, 6 December 2013 (UTC)
I wish to add my own humble opinion: The previous version of the now changed curves, drawn using elipse arcs, was right. These new curves, drawn with bezier vectors (any curve could be done with beziers, that’s not the issue) are wrong — both esthetically and semantically. I regret that this change was even considered (its shortcomings being obvious), let alone implemented. -- Tuválkin 19:06, 27 December 2013 (UTC)
Please elaborate! What are the shortcomings? They are not as evident as you think ). I can only think about the branch protruding less distinctly when there is a straight track; but for that we can have a separate icon. On the other hand, diagrams such as this now look better than before. YLSS (talk) 20:49, 27 December 2013 (UTC)