Talk:BSicon/Icon geometry and SVG code neatness/Archive 1

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

Image:BSicon texHST.svg

moved from User talk:Maxima m#Image:BSicon texHST.svg

"Image:BSicon texHST.svg" is about to be deleted, use Image:BSicon extHST.svg (BSicon extHST.svg) instead. Axpde (talk) 22:33, 11 December 2008 (UTC)

I changed

style="fill:#d77f7e; stroke:none"


fill="rgb(215, 127, 126)" stroke="none"

, and it seems OK now. Don't know why, though... ;-) - Erik Baas (talk) 14:15, 19 September 2008 (UTC)

Thank you so much. Just now I was going to change to
   stroke:none" >
 <circle cx="250" cy="250" r="100" />

and I hoped it would be OK. SVG Viwer of Adobe shows all versions as I wanted, though, and sigh.--Maxima m (talk) 15:13, 19 September 2008 (UTC)

Yes, Firefox (2 and 3) also displayed the icon the right way. In the mean time I found out what the problem was: line breaks are not allowed in "style"... See Image:BSicon TEST.svg, it has 5 circles:
  • first circle is before the path
  • 2nd is the same as in the original file
  • 3rd has "style" on one line
  • 4th has a semicolon after "stroke:none"
  • 5th has "style" on one line and a semicolon after "stroke:none"
3 and 5 are handled okay, the others don't
- Erik Baas (talk) 16:09, 19 September 2008 (UTC)
Thanx a lot, you wizard. Though Mediaiki shows 3 black and 2 pink circles, IE + SVG Viewer, NN + SVG Viewer display the same 5 correct cooloured circles. I will code as you showed above next svg file. --Maxima m (talk) 13:46, 20 September 2008 (UTC)

Parallel-track column shifts

uBS2c2 vSTRelr uBS2c3
uBS2c2 BS2lr uBS2c3

I recently replaced a renamed icon and it now shows misaligned. I repeat the sequence here (→), with blue corners for contrast. This is bound to happend in many other cases, not only in this little one example I detected it at. As you can see, it is visibly crooked, even at 20px high and in the same color. Short of needing an endless new vBS2c_ icon family, surely   (vSTRelr) and   (vSTRalr) could be redrawn to match the existing corners?

(For what is worth, the diagram in question did use once   (vBS2lr) and that did match the corners smoothly. Maybe revert to its geometry, namings aside?)

-- Tuválkin 15:24, 20 November 2011 (UTC)

✓ Done. Useddenim (talk) 18:16, 20 November 2011 (UTC)
Yay! -- Tuválkin 22:02, 20 November 2011 (UTC)

{{PD-ineligible}} vs. {{PD-geometry}}

Hi Useddemin,

some time ago we came to the conclusion, that all BSicons should be labeled as {{PD-ineligible}}, but I have to admit, that {{PD-geometry}} fits even better, so no hard feelings ;-) axpdeHello! 07:22, 6 April 2011 (UTC)

FWIW, {{PD-geometry}} is an alias for {{PD-shape}}. -- Tuválkin 19:21, 9 November 2011 (UTC)
Yes, I had already noticed that, and have been using {{PD-shape}} ever since. Useddenim (talk) 05:20, 10 November 2011 (UTC)

which looks best?

Hi Useddenim, what do you think, which bow (suggested name "STR3+4") suits best? a×pdeHello! 14:03, 6 July 2011 (UTC)
STRc12 STR3+4
STR2+r STRc3
STRc12 STR3+4
STRr+1 STRc4
My version connects in the corner at exactly 45°, and goes to the 125/375 px line, for consistency with the ÜW and v icon sets. Useddenim (talk) 17:32, 6 July 2011 (UTC)

Light/heavy hierarchy

moved from User talk:Axpde/Archive 3#File:BSicon ~mKRZ.svg Reverts

  (mKRZ)   (umKRZ)   (exmKRZ)   (uexmKRZ)

Having one line interrupt the other implies superiority, which is not necessarily the case. My redrawn versions gave equal weight to both lines. (Note that in the case of in-service crossing out-of-service, the former does logically interrupt the latter. Useddenim (talk) 15:10, 6 March 2011 (UTC)

The design of the icons is 5 years old and globally used. It's not up to you, to determine what's "logical" or not. Heavy rail outranks light rail thus the red line superimposes the blue line. axpdeHello! 15:18, 6 March 2011 (UTC)
“Heavy rail outranks light”: not necessarily so. There are numerous instances where a light rail line with very short headways crosses a heavy rail line that sees only occasion use. Besides, on 2 April 2010 you arbitrarily decided that all the ~tKRZt~ icons are not logical “…and there are no bridges below surface!!”—despite since being proved wrong! (Or maybe I missed seeing the notice of your appointment as the sole arbiter of logic for Wikipedia.) Useddenim (talk) 17:31, 6 March 2011 (UTC)
Ok, there are very few examples of bridges below surface, but in most cases, those bridge icons are used to display crossing subsuface lines that are completely independent. Anyway, that a different story discussed elsewhere.
If you have a situation where the light rail track is more important than the heavy rail one, feel free to overlay uSTR or uSTRq ... axpdeHello! 14:07, 7 March 2011 (UTC)

Archive note: The "redrawn" version referred here are now known as   (mCRS) and   (umCRS). Circeus (talk) 02:55, 6 October 2011 (UTC)

Note 2: Three-level bridge structure within an underground tunnel, from p.22 of Brian Hardy's Paris Metro Handbook (Capital Transport, 2nd ed., 1993). The photo caption states, "At Opera, lines 3, 7 and 9 cross, all underground. This view shows line 9 (lower right), line 7 (left), above which can be seen the girder works for line 3." Useddenim (talk) 03:59, 6 October 2011 (UTC)

Another fine kettle of fish

moved to Talk:BSicon/Icon topology and semantics#Completely new BS icon set

PNGs to convert

Here’s what I found: -- Tuválkin 05:56, 28 December 2011 (UTC)

x60px (uexGRENZEa)
Already marked for replacement with svg:   (uexGRENZEa) -- Tuválkin 16:56, 28 December 2011 (UTC)
x60px (STRs)
Marked for replacement with svg as   (STRs), but this is a different design. Better discuss this icon semantics and geometry before making and filename/format changes though. I think, too, this one is to go straight to the dustbin. -- Tuválkin 20:03, 28 December 2011 (UTC)
60px (AKRZuq)
This is obviously akin to   (AKRZu), and its svg version is trivial. -- Tuválkin 16:56, 28 December 2011 (UTC)
And identical to   (AKRZuq), m.m.. I just marked it as repleaceable. -- Tuválkin 21:10, 28 December 2011 (UTC)
x60px (MWABZlgu)
Part of the   (MWABZlu) family; redrawable as svg, if usage begets it. -- Tuválkin 16:56, 28 December 2011 (UTC)
Redrawn:   (MWABZlgu) -- Tuválkin 21:10, 28 December 2011 (UTC)
x60px (xvINTe-KBFe)
I'm not sure of the logic of this one… Useddenim (talk) 13:48, 28 December 2011 (UTC)
It is a single-cell twinning of   (KINTxe)+  (KBHFe), which seems to suggest vKINTxe-KBFHe for its name, while   (vxINT-INT) hints at the desirable geometry for half a   (vINT).-- Tuválkin 16:56, 28 December 2011 (UTC)
But I can see what you mean. being half   (INT) half   (BHF) seems senseless, regardless of the “severed limb”. If it is two stations connected by passengerways, one of which is multi modal and the other is not (like this), then it should be iconized with CPICs, not as a single icon. -- Tuválkin 20:03, 28 December 2011 (UTC)
An svg version created   (vKINTxe-KBHFe), anyway. And with it we got (for the moment) rid of BS (pseudo)icons in png format lacking an svg equivalent. -- Tuválkin 21:49, 28 December 2011 (UTC)
Based on the above discussion, I've changed the configuration of the icon from ⊂⊃ to ◦◦ (since De COUVILLE, the original creator, hasn't given us any context for its proposed use). Useddenim (talk) 05:59, 29 December 2011 (UTC)
further discussion moved to #double_stations

double stations

Based on the above discussion, I've changed the configuration of the   (vKINTxe-KBHFe) from ⊂⊃ to ◦◦ (since De COUVILLE, the original creator, hasn't given us any context for its proposed use). Useddenim (talk) 05:59, 29 December 2011 (UTC)

I always assumed these icons were to be linked by default. How the crap are we supposed to tell apart icons that are joined and those that are not? Circeus (talk) 06:32, 29 December 2011 (UTC)
Should   (vBHF) look like   (BHF)+  (BHF) or like   (BHF-L)+  (BHF-R) (as it is now), that is the question. I can see advantages in either approach. -- Tuválkin 02:14, 30 December 2011 (UTC)
I'd say that it depends upon the particular situation. I would, however, suggest leaving   (vBHF) as it presently is, as   (dBHF)+  (dBHF) could always be used where warranted. Useddenim (talk) 02:59, 30 December 2011 (UTC)
Can most project that uses BSicon handle the d- ones seamlessly? If so I think it is a sound approach to have v- station of any kind joined only, and others created via d- icons. If we keep both icon sets, we will need to come up with separate conventions because otherwise sooner or later someone will try to upload a separated form of something we already have in joined, or need a joined form of something that's currently only in separate. Circeus (talk) 03:30, 30 December 2011 (UTC)
If one checks en:Wikipedia:Route diagram template/Catalog of pictograms/parallel stations#Combinations, you will note that — aside from mixed light/heavy rail — they are all of the double-circle format. If it turns out to be needed,   (vBHF-BHF) could be created (even though Axpde will probably detest the name). Useddenim (talk) 17:02, 30 December 2011 (UTC)

Lets move this discussion away from where it is expected to be about double stations icone shapes. -- Tuválkin 00:30, 18 February 2012 (UTC)

moved to Talk:BSicon/Templates#Synchronize!. -- Tuválkin 02:01, 31 March 2012 (UTC)

¾-shift curves

exvÜSTxr + vSHI3l-
BSicon exvÜSTxr.svg
uBS2c23 v-SHI3r
exvSTRe + BS2+l
BSicon exSPLe.svg
uBS2c14 v-SHI3+r

I created three of these and added them under en:Wikipedia:Route_diagram_template/Catalog_of_pictograms/parallel_straight_tracks#3.2F4_shift, named after their ½-shift (and ¼-shift) counterparts:

  •   (vBS2-r)    (BS2r)
  •   (vBS2l-)    (BS2l)
  •   (vBS2-+r)   (BS2+r) — and   (vBS2+r-)

I hope I got the names right (if not, lets discuss it in Talk:BSicon/Renaming). However the fitting with corner icons was unsure. Looks good enough in 20 px high, but I want to test it here in bigger size. ---- Tuválkin 23:51, 27 May 2012 (UTC)

Already discussed at Talk:BSicon/Renaming/SPL (with no consensus or conclusion).
Possible coherent naming scheme
¼  (BS4+r) ½   (BS2+r) ¾  (BS3+r)

Bummer. Need either tighter curves or a new set of corner icons. -- Tuválkin 00:41, 28 May 2012 (UTC)

BS2c2 uv-SHI3r
BS2c1 uBS2+r
How about this? Path is d="M 0,500 C 0,175 375,325 375,0". Useddenim (talk) 15:14, 28 May 2012 (UTC)
Neat-o! -- Tuválkin 19:04, 28 May 2012 (UTC)
✓ Done -- Tuválkin 07:42, 29 May 2012 (UTC)

Upd: I renamed them and re-uploaded with smoother curves to be used with new 4/4 shift corners. The older design looked closer to a curve + curve than to a shift. YLSS (talk) 17:32, 1 December 2013 (UTC)

Features to rotate along with the track?

We can say for sure that while some features are iconic and should always be pointing the same “up” direction (such as   (uxSTRbm) vs.   (uxHSTRbu), or   (ACC) vs.   (ACCq)), others are slaved to the orientation of the main line and rotate along with it (such as   (eABZrg) vs.   (eABZql), or   (ENDEa) vs.   (ENDEl)).

However, I’m not 100% sure about a few borderline cases, such as level crossing icons. Today I rotated   (BUEq) so that it shows the same design as a whole as   (BUE), but I guess it could be argued that the (upright) X-cross sign "20px" is an icon as much as "BSicon BUILDING.svg" or "20px" are, and as such it should not rotate along with the track/line. What do you think?

-- Tuválkin 19:35, 15 April 2012 (UTC)

I think we should adopt the (North) American icon   (BUE-us), which uses a shape that has 90° rotational symmetry. Useddenim (talk) 23:56, 15 April 2012 (UTC)
Heh heh!, — that’s dodging the question. -- Tuválkin 00:01, 16 April 2012 (UTC)
Okay, I think I have this one figured out: You see, the cross is two different parts (on symmetry axis) because gated level crossings have also two different ways to go — unlike, say,  , something like   shows one flow of traffic   that yields to the other  , as enforced by the thingy  . Sure this is a no brainer for road/rail, but a tram line crossing a heavy rail one, well, BSicon .svgBSicon uSTRq.svgBSicon BUE.svg  would be it (as well as BSicon .svgBSicon uSTR.svgBSicon BUEq.svg ), while BSicon .svgBSicon STRq.svgBSicon uBUE.svg  (and BSicon .svgBSicon STR.svgBSicon uBUEq.svg ) would mean the opposite (and unlikely) situation. The "X" rotates to show which flow yields to the other. -- Tuválkin 06:35, 27 June 2012 (UTC)

ÜW Lücken

exLSTR+1 LLSTRc4 exLSTR+1 exLSTR+4
uexLSTR+1 LLSTRc4 uexLSTR+1 uexLSTR+4

I modified   (LSTR+l1) to have a SW quarter disc at the corner, for easy match (and following the respective corner icons, too —   (LÜWc4), et c.). However all other such icons show unmatching corner ends; see examples. -- Tuválkin 18:17, 22 July 2012 (UTC)

(Also, the names: Shouldn’t   (LSTR+l1) be just   (LSTR+1)? And what’s with all the dupes? -- Tuválkin 18:17, 22 July 2012 (UTC)

My thoughts: notice the corner connection. (That's why I drew the ones I did the way I did.) Useddenim (talk) 21:36, 22 July 2012 (UTC)
Yes, while I was offline it struck me it should be it. My apologies for not having noticed it before!
That’s the reason for it, but both approaches have problems. While the way I did it we can have a continuous string of LUECKEs without any odd-shaped “discs” where icons meet, those same corners cannot be used for a seamless start or end of a dotte segment of the line. This calls for some thinking, and I think I have an idea. I’ll be back soon! :-) -- Tuválkin 23:01, 22 July 2012 (UTC)

STRc2 uSTR3+l LLSTRc2 STR3+l

fixed to LL -- Tuválkin 23:24, 29 July 2012 (UTC)

Okay, so this is the problem, as illustrated at the right: Some times we need the corner dots as exact quadrants (green icons), some times we want them to match regular line corner (blue icons). The right side diagrams look bad and the left side ones look good.

My suggested solution is this: Lets change all ÜW LÜCKE icons to have quarter discs at the corners and lets create a new set of icons whereon the dottedness starts, something like   (LSTR3a green).

-- Tuválkin 00:28, 23 July 2012 (UTC)

Oppose. Create new icons with 1/4 disks, and keep existing LÜCKE to avoid having to make hundreds of changes. Useddenim (talk) 10:27, 23 July 2012 (UTC)
New icons? Okay, why not? So, LUECKEs ending at icon sides orthogonally are always good, while for LUECKEs ending at icon corners we’ll have regular ones matching non-LUECKE icons and special ones matching each other. Suits me. Any ideas for the new names? LLSTR, maybe? -- Tuválkin 04:02, 25 July 2012 (UTC)

✓ Done -- Tuválkin 23:24, 29 July 2012 (UTC)

KRW width

exKRW+l exKRWr KRW+l KRWr uexKRW+l uexKRWr uKRW+l uKRWr
exKRWl exKRW+r KRWl KRW+r uexKRWl uexKRW+r uKRWl uKRW+r
exKRWg+l exKRWgr KRWg+l KRWgr uexKRWg+l uexKRWgr uKRWg+l uKRWgr
exKRWgl exKRWg+r KRWgl KRWg+r uexKRWgl uexKRWg+r uKRWgl uKRWg+r
exKRW+l exKRWgr KRW+l KRWgr uexKRW+l uexKRWgr uKRW+l uKRWgr
exKRWl exKRWg+r KRWl KRWg+r uexKRWl uexKRWg+r uKRWl uKRWg+r
exKRWg+l exKRWr KRWg+l KRWr uexKRWg+l uexKRWr uKRWg+l uKRWr
exKRWgl exKRW+r KRWgl KRW+r uexKRWgl uexKRW+r uKRWgl uKRW+r
xKRWg+l xKRWgr eKRWg+l eKRWgr uxKRWg+l uxKRWgr ueKRWg+l ueKRWgr
xKRWgl xKRWg+r eKRWgl eKRWg+r uxKRWgl uxKRWg+r ueKRWgl ueKRWg+r

Hi, there. Which shape is to be adopted? For the simplicity and consistency with tunnel (dashed) line, 20% width throughout would be better. --Maxima m (talk) 23:27, 28 June 2012 (UTC)

20% (stroke-width=100px) is correct. I'm fixing them as time permits. Useddenim (talk) 23:42, 28 June 2012 (UTC)
100px (so, 20% of 500px, okay) is not only okay, is the obvious way to go — identical to the width of, say,   (STR). I have no idea why would someone think it should be different. (Of course we are dealing here with width as measured orthogonally to the length of a line, really the line path itself.) -- Tuválkin 01:31, 29 June 2012 (UTC)
The blue set seems to be better drawn, evn though   (uexKRWg+l) and   (uexKRWg+l) are still missing. Maybe simpler is to recolor the blue set for the outdated red ones and upload it with no "u". -- Tuválkin 00:13, 30 June 2012 (UTC)

The hybrid set is very incomplete and includes a few with mistmatching withs and axes. (I just add to the table →.) Missing:

  •   (xmKRWr)
  •   (emKRWr)
  •   (uxmKRWg+l)
  •   (uxmKRWr)
  •   (uemKRWg+l)
  •   (uemKRWr)
  •   (xmKRWgl)
  •   (xmKRW+r)
  •   (emKRW+r)
  •   (uxmKRWgl)
  •   (uxmKRW+r)
  •   (uemKRW+r)
  •   (xmKRWg+l)
  •   (xmKRWgr)
  •   (emKRWg+l)
  •   (emKRWgr)
  •   (uxmKRWgr)
  •   (uemKRWgr)
  •   (xmKRWg+r)
  •   (emKRWgl)
  •   (emKRWg+r)
  •   (uxmKRWg+r)
  •   (uemKRWgl)
  •   (uemKRWg+r)
  •   (xKRW+r)
  •   (eKRW+r)
  •   (uxKRW+r)
  •   (ueKRW+r)
  •   (eKRWr)
  •   (uxKRWr)
  •   (ueKRWr)
  •   (xKRWr)

I.e., the whole "m" series (both colors), a few red "e/x" and a lots of blue "e/x" icons. -- Tuválkin 15:23, 30 June 2012 (UTC)

Now all completed and seem OK on the icons on the right, I hope. Sorry, I have forgot I uploaded narrow lined icons. --Maxima m (talk) 02:00, 2 July 2012 (UTC)


numN315 numN000 numN045
numN270 INCIDO numN090
numN225 numN180 numN135

So I didn’t like the name and the geometry of   (mapNORTH000deg), so I created and uploaded   (numN000) and its kin. I’m not 100% happy with these, but I think they're a step on the right direction. -- Tuválkin 05:02, 21 November 2012 (UTC)

If you want a different name, you should 'propose that. Now we have two icons for exactly the same.
If you want to improve or change the image, you can upload a new version. -DePiep (talk) 11:09, 25 December 2012 (UTC)
And, to be clear, the name and the inamge both are not an improvement to me. I'll be back on this. -DePiep (talk) 11:42, 25 December 2012 (UTC)
The names "  (numN315)", etc, were chosen to match already existing ones, unlike "  (mapNORTH000deg)", which is an oddball. As for the design, I'm not happy with it (too thick), either, and will work on it. Separate names allow for separate experimental work, to be standartized later. -- Tuválkin 20:40, 25 December 2012 (UTC)
What match already existing ones you mean? I could conflow. - if there was a flow to go with. -DePiep (talk) 03:18, 4 January 2013 (UTC)
These «already existing ones» I mean: With names consisting of
"num" + the text in question + additional position indications.
-- Tuválkin 17:09, 4 January 2013 (UTC)
New, more elegant shapes ✓ Done. -- Tuválkin 16:47, 17 February 2013 (UTC)

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

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

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)

Transparency/masking in elevated icons

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 .svgBSicon uSTR3+1.svgBSicon hSTRl+4.svg (hSTRl+4uSTR3+1)  and BSicon .svgBSicon 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

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

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

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

(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 .svgBSicon 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

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)