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

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 () instead. Axpde (talk) 22:33, 11 December 2008 (UTC)

I changed

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

to

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

 <g 
   style="
   fill:#d77f7e;
   stroke:none" >
 <circle cx="250" cy="250" r="100" />
 </g>

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)

File:BSicon TEST.svg

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

vSTRelr vSTRelr BS2lr

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 ;-) axp_de^Hello! 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)

STR3+4

STR3+4

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. axp_de^Hello! 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 ... axp_de^Hello! 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, 2^nd 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)

File:BSicon uexGRENZEa.png (uexGRENZEa)

Already marked for replacement with svg:  (uexGRENZEa) -- Tuválkin ✉ 16:56, 28 December 2011 (UTC)

File:BSicon STRs.png (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)

File:BSicon AKRZuq.png (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)

File:BSicon MWABZlgu.PNG (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)

File:BSicon xvINTe-KBFe.png (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

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)

uvBS2-r 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 "File:BSicon BUE legende.svg" is an icon as much as "" or "File:BSicon ACC legende.svg" 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,   would be it (as well as  ), while   (and  ) 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

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)

LÜWc4 ÜWc4

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)

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

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)

Windroses

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

Overlay on (one of) parallel tracks Looks like small and big houses at the same scale Looks like the same house at different scales 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

Also,  (hSTRl+4) has the gap filled with mask color while  (hSTR2) has true empty gaps — compare  (hSTRl+4※ uSTR3+1)  and  (hSTR2※ uSTR3+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

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

Legend All good if the background is white anyway Overlaid on other icons, white shows. 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×p_de^Hello! 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×p_de^Hello! 22:11, 3 September 2011 (UTC)

Reverted?!

“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:

• Шаблон:Кубинка I — Михнево
• Шаблон:Икша — Кубинка I

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)

Drawbridges

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

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)