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

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
Archive 1 Archive 2 Archive 3 Archive 4 Archive 5

any

moved from User talk:Useddenim

Before you go too far down that road, could you please explain your idea? IMHO it's totally OK to use   (eHST3) etc. (or "x" versions) in such an unofficial kinda thing like our guideline, rather than creating some new colour pattern (?) like "any"... YLSS (talk) 00:36, 28 December 2014 (UTC)

I created them specifically to match the adjacent text: i.e. greyed out except for the relevant characteristic. I could live with a revert; what do others think? Useddenim (talk) 02:52, 28 December 2014 (UTC)

Elevated wyes

(Pinging: Useddenim, Tuvalkin, YLSS, Newfraferz87, Sameboat) Was wondering: why   (ABZgl+l),   (uABZl+l),   (uABZgl+l) and   (uABZl+l) (all regular 100px stroke) but   (uhABZgl+l) (60px stroke for curves)? Jc86035 (talkcontributionsuploads) 13:37, 2 June 2016 (UTC)

There was concern that 100px width is too thick for 90 degree turn by 250px radius. At one point new icons of similar gl+l or gr+r composition cease this practice. -- Sameboat - 同舟 (talk · contri.) 13:59, 2 June 2016 (UTC)
Yes, and in my opinion things like   (uhABZgl+l) should be standartized to use 100px thick lines. -- Tuválkin 22:36, 2 June 2016 (UTC)
I wasn't too sure how much visual problems would changing icons such as   (uhABZgl+l) bring about, so I didn't touch them. Unless more objections are raised, it seems that's not much of a problem now, so I'm fine with them being standardized. However, I did note the differences between   (uKRZlr+lr) and   (uABZlr+lr) and how it's absolutely necessary for the former to have narrow turning curves (otherwise it will end up as   (uJUNC) ).   ~ Newfitz Yo! 09:46, 5 June 2016 (UTC)
  (ABZgr+r green) is an example of an icon with narrow (75px) stokes for both the curves and the through line. IMHO it shows the triangle more clearly without excessively thinning the strokes. Useddenim (talk) 03:38, 6 June 2016 (UTC)
@Useddenim: 75px (all tracks), imho, seems to look a bit nicer than 100px (all tracks). Not sure if it's better than 100px–60px though. Jc86035 (talkcontributionsuploads) 05:48, 7 June 2016 (UTC)
And   (uhKRZl+lr) is an example with 70px lines. My point is that there are configurations where narrower lines are needed, and using all narrowed lines looks much better than a combination of thick and thin. Useddenim (talk) 10:26, 7 June 2016 (UTC)
@Useddenim: That particular one does look a little wonky though (the straight lines are a bit off), maybe you could fix that for a better demonstration? Jc86035 (talkcontributionsuploads) 11:09, 7 June 2016 (UTC)
That's because the icon itself is asymmetrical (unless you consider the top left–bottom right axis...) Useddenim (talk) 15:11, 7 June 2016 (UTC)
  (uhKRZl+lr) is more visible given the space between the lines/curves, but I would still argue that it is not symmetric and less aesthetically pleasing than   (uKRZl+lr). Would it be possible to reach a happy medium?   ~ Newfitz Yo! 15:43, 14 June 2016 (UTC)
Yes, if you don't mind a slight kink in the straight-through lines. Useddenim (talk) 16:58, 14 June 2016 (UTC)

Number size

num1m num1r num2r num3l num5m num7r num0m num11m
20px
num1m num1r num2r num3l num5m num7r num0m num11m
30px
num2a sameboat002
20px
num2a sameboat002
40px
20px, platforms
40px platforms

What's the standard code of a number icon? Several of them seem to be differently sized (or squashed), but only at 20px. Jc86035 (talkcontributionsuploads) 14:08, 15 June 2016 (UTC)

or is it just librsvg being weird? Jc86035 (talkcontributionsuploads) 14:11, 15 June 2016 (UTC)

It's something to do with the way fonts are rendered by the svg engine. Tuvalkin might know more about it. Useddenim (talk) 03:27, 16 June 2016 (UTC)
I started this series (and am responsible for the bad root letter case). Now I think we better use <path> to outline the numeric glyphs instead of using <text> and existent font for best result. I opt for the pixel by pixel style for simple and neat edge and the icon should be done in 20x20px natively to ensure that they look crisp in the RDT. -- Sameboat - 同舟 (talk · contri.) 07:00, 16 June 2016 (UTC)
@Sameboat: Would making the edges slightly curved work? It's clear to read but it's also not particularly aesthetically pleasing. Jc86035 (talkcontributionsuploads) 09:16, 16 June 2016 (UTC)
I think you want curved corners? Anything not horizontal or vertical will cause blurred edge after scaling due to interpolation which is something I want to avoid in small size rasterized icon. -- Sameboat - 同舟 (talk · contri.) 09:34, 16 June 2016 (UTC)
Revised my temp BSicon for numeric 0~9 (0 is hidden). All path are originally centered at (0,0) and moved to position via transform-translate for easier derivation. -- Sameboat - 同舟 (talk · contri.) 11:08, 16 June 2016 (UTC)
Should the numbers be aligned closer to the icon edge, similarly to the currently-used icons? Jc86035 (talkcontributionsuploads) 11:52, 16 June 2016 (UTC)
They are 1 to 2 px away from the 20x20px canvas edge. I don't think it's a good idea to align the object on the edge if it isn't meant to connect to the adjacent icon like STR/BHF icons do. Arguably you can move 1,4,7 leftward (x: 4->3), 3,6,9 rightward (x: 16->17), 7,8,9 downward (y: 16->17) all by 1px. -- Sameboat - 同舟 (talk · contri.) 12:04, 16 June 2016 (UTC)
One problem is that the current icons are thin enough to fit on the 125px-wide platforms (see w:en:Template:Mile End–Bow Road tube station). With a margin on both sides the numbers would have to be 3px (or, normally, 75px) wide…? Jc86035 (talkcontributionsuploads) 12:34, 16 June 2016 (UTC)
Moved the numeric closer to edges and thinner glyph width, but I can see another issue when overlapping on platform icons is the terrible low contrast, even though this can be fixed by using white numeric. -- Sameboat - 同舟 (talk · contri.) 12:50, 16 June 2016 (UTC)

Continuation icons

CONTge uvCONTge-
uvCONTfge uvCONTge-

Which one of the three lengths for opposite-direction CONT arrows – 275px (  (uCONT+fq), +gq and the elevated ones), 325px (  (CONTfa), ge, most others) or 350px (  (uvCONTge-) and all other parallel icons except these two) – is correct? Jc86035 (talkcontributionsuploads) 12:10, 21 August 2016 (UTC)

I'm probably guilty of drawing my icons inconsistently, but I would say that   (uvCONTge-) is too long whereas the other two are correct. However, I just realized where the extra length came from: Note the second line of the example: the tail was extended to match the head of the opposite direction. The stand-alone tail should be shortened to the standard length. Useddenim (talk) 14:23, 28 January 2017 (UTC)
@Useddenim: so 325px would be best for all of them? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
14:35, 28 January 2017 (UTC)
No. As stated above, they are all correct except for the single parallel line tail (which should be shortened to 325px). The line on elevated CONTinuation starts (  (hCONT+f), for example) was shortened to compensate for the extra length of the formation, resulting in an overall-balanced icon. Note the positions of the line ends relative to the centre of the icon. Useddenim (talk) 16:16, 28 January 2017 (UTC)
@Useddenim: The issue I was originally concerned with, I think, was that the formations could look inconsistent when they were overlaid differently to form parallel tracks. There isn't a need for this anymore, since Epicgenius's track diagram style mostly uses fades instead of continuation arrows, but it might still help to standardize them (especially in the case of parallel elevated continuation icons, which could be created but don't exist yet). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
04:28, 29 January 2017 (UTC)

Parallel curves

v-STRlf uvSTR+rf- uv-STR+lf vSTRrf-

@Useddenim and Sameboat: Some of these and these (many of the icons without elliptical curves) seem to have lines which are 5px off from 125/375, but I'm not sure if this is a problem in the subcategories as well. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
08:37, 20 December 2016 (UTC)

Fixed earlier this week. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
09:49, 28 January 2017 (UTC)

Tunnels under water

@Useddenim and Sameboat: Should tunnels be drawn above water   (WTUNNEL1) or below water   (tWSTR)? I'm inclined to put them above water, because we already have   (WTUNNEL) and it wouldn't make any sense for tunnels crossing   (WDOCKSm). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
09:58, 28 January 2017 (UTC)

  • I normally put tunnels under water because that's where they are IRL; but, I have no objection to the reverse if it's needed for clarity. Useddenim (talk) 14:15, 28 January 2017 (UTC)
  • I think the dashed design of tunnel lines is meant to enable their placement on top of (=over) other elements in order to keep them visible — and the “solid” water is a good example —, regardless of the “background” (which is actaually a foreground). This was probably not thought originally so for earlier tunnel BSicons, but merely lifted from existing mapping conventions elsewhere, but originally done thusly for that reason, I believe. -- Tuválkin 02:19, 29 January 2017 (UTC)

INTACCs

@Useddenim, Tuvalkin, and Lost on Belmont: I reuploaded several vINTACC icons assuming that they would use the same station circles as vINT icons, but for some reason they don't (50px black line instead of 60px). Is this deliberate, and should   (INTACC-M) use 50px as well (since it has to match with 60px INT icons)? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
11:02, 19 February 2017 (UTC)

There was a lengthy debate about this a few years ago. (Line thickness, circle radius.) Unfortunately, I don’t remember what the consensus was. Try digging through the archives… Useddenim (talk) 13:36, 19 February 2017 (UTC)
@Useddenim: According to archive 2, YLSS simply went with 50px rings (maybe he didn't anticipate that the interchange icons were expected to line up perfectly). I haven't found anything else yet. A few icons still have 53px rings. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
13:53, 19 February 2017 (UTC)

Shifts in tunnel

@Useddenim and Tuvalkin: Should three-quarter and four-quarter tunnel shifts have separate corner icons? Looking at en:Template:BMT Fourth Avenue Line, they don't match up perfectly. (In addition, Useddenim's   (tSHI4c1) is different to YLSS's   (utSHI4c1).) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
09:14, 26 February 2017 (UTC)

Parallel stations

@Useddenim and Tuvalkin: Is the slight difference in geometry between (e.g.)   (v-BHF-L) and   (lv-BHF-L) intentional? (The legende icon's station is slightly smaller, with the circle's centre being 25px to the right so that the left edge is exactly in the middle.) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
11:32, 1 March 2017 (UTC)

@Tuvalkin: I suppose it might be to do with having parallel passing tracks, but the difference (while noticeable) is probably negligible. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
14:57, 1 March 2017 (UTC)

I think I put the edge at 250px to allow it to be used with d icons and to reduce the chance of overlapping other features. Useddenim (talk) 02:40, 2 March 2017 (UTC)
@Useddenim: Should we keep them as they are? The slightly wider gap could be marginally better (see also w:en:Template:Metra Electric Line, which uses the 300px station circles instead of the 250px ones). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
07:06, 2 March 2017 (UTC)
The Metra diagram was a bit of a kludge because there is no elevated version of   (vBHF-STR). I don't think it looks bad, but it may look better with 250px∅ stations. Useddenim (talk) 11:22, 2 March 2017 (UTC)
@Useddenim: Updated the diagram with   (hvBHF-STR) and its ACC version (used with   (hdBHF+R)). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
13:17, 2 March 2017 (UTC)
Awww, you took away all the bumps. (Actually, the diagram now looks much neater.) Useddenim (talk) 00:58, 3 March 2017 (UTC)

Crossovers

@Useddenim, Tuvalkin, and Axpde: Is   (FOWl) semantically the same as   (FOWl+BRÜCKE)? Why does the former not need a bridge? (Also, why does   (ÜWBl) also exist, and should the mask be removed?) Should two of them (plus -r, ex- variants) be deleted/redirected? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
13:28, 11 March 2017 (UTC)

I created to versions of "FOW" (Fahrordnungswechsel = change of side of travel), one with bridges and one without, because some users demanded different versions. The "ÜWBL" has a grey masking, don't know whether there is a need for it ... a×pdeHello! 14:59, 11 March 2017 (UTC)
@Axpde: I don't think it's really necessary to have two/three different versions, since FOWl is almost never used and there's obviously a bridge in real life. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
02:02, 13 March 2017 (UTC)
It wash the wish of a user on dewiki to have a version without the bridges.
And as I said before there's a problem with "ÜWBL" because it has a grey masking! a×pdeHello! 06:57, 13 March 2017 (UTC)
@Axpde: I've trialled a version of   (ÜWBl)/r without the mask, using a more exact rotation for the bridge. Should   (FOWl+BRÜCKE)/r be deleted/redirected as duplicates? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
11:38, 13 March 2017 (UTC)
"FOW" is the correct root for this icon, furthermore the bridge icons in my version are correct, in your version it seems as if the tracks don't hit each other ... a×pdeHello! 17:09, 13 March 2017 (UTC)
@Axpde: Do you mean the line crossing under doesn't seem to align with itself? Is there that much difference with a 3.2° rotation of the formations? I think having +BRÜCKE in an icon name is a lot more cumbersome than just using a different root; furthermore using ÜWB matches with the parallel icons of the same root such as   (vÜWBl). @Useddenim and Tuvalkin: any second opinions? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
00:28, 14 March 2017 (UTC)
  1. The option without bridges may be used for level crossings or perhaps if it's not sure whether it's bridged or not. Regardless, it was the explicit wish of another user.
  2. It's nowhere written that bridges have always to be right-angled crossing other tracks.
  3. FOW is for a two track railroad changing the side of travel direction, ÜWB is for two parallel railroads crossing each other.
Greets a×pdeHello! 02:29, 14 March 2017 (UTC)
@Axpde: What do you mean by "it seems as if the tracks don't hit each other"?
  1. Okay. No objection to keeping them.
  2. Waiting for a second opinion; if you're referring to my modification of the bridge shape I just thought it was more aesthetically pleasing.
  3.   (vÜWBl) is basically the track diagram version of   (ÜWBl). I don't think there's anything wrong with those icons' naming.
Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
04:38, 14 March 2017 (UTC)
I was pinged in this discussion, but what I have to say about this icon is not constructive to the details of the discussion. But here it goes (and it was expressed before): Kill it with fire! The only way to properly depict this kind of arrangement is with something like   (vÜWBl). A diagram using   (STR) instead of   (vSTR) to show a double track has no business illustrating the swapping of their expected directions: Just add a "🔀" or a "⤨" in the text if really needed. -- Tuválkin 12:36, 15 March 2017 (UTC)
@Tuvalkin: I don't think there's a problem with splitting the line, as we could treat it as a   (nSTR) crossover which happens to merge at both ends. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
15:51, 15 March 2017 (UTC)
Well, in my opinion   (nSTR) is the root of all (that) evil… -- Tuválkin 17:32, 16 March 2017 (UTC)

Quarter-width icons

@Useddenim, Tuvalkin, Axpde, and Lost on Belmont: There are several quarter-width icons where the feature doesn't quite fit in the image (e.g.   (ckSTRc1),   (cCONTfq)). Should we do away with them, considering they can usually be replaced by half-width icons? The difference in rendering is somewhat noticeable (especially for the CONT icons), even at 20px. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
11:27, 4 April 2017 (UTC)

500x

I've tried adjusting the curve for   (5001) to M -166.7,333.3 35.4,131.2 A 106.52,106.52 0 0 1 110.7,100 c 64.3,0 64.3,25 139.3,25 l 250,0, but it doesn't really work that well. Is there a better way? (Just a single arc with the current parallel lines geometry reduces the inside of the curve to an angle, since the radius is only 21.17.) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
05:51, 11 April 2017 (UTC)

More things

@Useddenim, Tuvalkin, and Lost on Belmont: Pings here so I don't do them twice on this page. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
18:10, 12 April 2017 (UTC)

LLSTR icons for compound junctions

Should there be separate LSTR and LLSTR icons for KRWs (and other shifts, if necessary), 3-column curves and k curves? Many of the lücke icons in those groups (especially the 3-column curves) currently have somewhat-awkward positioning so that they can kinda-sorta connect with both the next interrupted line and a normal track. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
18:10, 12 April 2017 (UTC)

Deliberately drawn that way. They may look a little awkward at full size, but are fine at 20px. Useddenim (talk) 00:50, 20 April 2017 (UTC)
@Useddenim: The LLSTR distinction might still be better, especially for elevated lines (e.g. at w:en:Template:Seremban Line). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
16:23, 24 May 2017 (UTC)

Platforms

Should platforms be moved slightly closer to their adjacent tracks so that they're perfectly in line with elevated formations? (This isn't really a major thing, but it seems odd to have the platforms further away than the viaduct edges.) This could also require renaming, to differentiate between a platform with an edge adjacent to a track and a legende platform with 125/250px width (e.g.   (STR+BSlr)PSTR-LR;   (vSTR-BS)vPSTR-L or vPSTR-L-PLT;   (BSlr) (no geometry change)PLT-LR).

In addition, should elevated platforms have formations (e.g.   (6001),   (hKRZ+BSel)), or do we just ignore that? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
18:10, 12 April 2017 (UTC)

Parallel curves

Should   (hSTR+r-) and   (uh-STRr) be reuploaded with the usual parallel curves geometry, or should they just be renamed to hSTR+rg and uhSTRrf once the latter filename is eventually freed up? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
18:27, 12 April 2017 (UTC)

Only renamed. Circular curves look better than elliptical ones. Useddenim (talk) 10:26, 19 April 2017 (UTC)
@Useddenim: hSTR+rg or hSTR+r-STR, or something else? (The latter could have some problems with which-part-does-the-prefix-apply-to but it should be fine I guess.) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
12:12, 19 April 2017 (UTC)

kLSTR

moved from en:Template talk:Pink Line (CTA)

@Useddenim: The kLSTR icons don't line up properly. Did you use the right geometry? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
12:39, 10 July 2017 (UTC)

@Jc86035: They look correct on my computer. Rendering error? Useddenim (talk) 16:10, 10 July 2017 (UTC)
@Useddenim: It's hard to see on a display with regular pixel density, but   (kLSTR3) and   (kLSTRr+1) (and blue versions) have different geometry. The latter uses a geometry which has a dot exactly in the middle of the icon border, whereas the former matches the corner icon in its stroke-dasharray and thus aligns with the corner icon correctly. I didn't update the LSTRs when reuploading most of the k curves, although it might make sense to first rename the originals to use the LLSTR root since in order for them to match all three pieces of the curve have to be LUECKEn. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
16:16, 10 July 2017 (UTC)
@Jc86035: I created the ukLSTR (and uhkLSTR) icons from the figure above, and then just moved the viewBox in 500px steps, so I don’t know how the geometry would have changed. Useddenim (talk) 21:32, 10 July 2017 (UTC)
@Useddenim: I don't really know either, since you uploaded all of them in one batch but still used a different stroke-dasharray for the r+1 and l+4 icons. I'll reupload them. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
03:53, 11 July 2017 (UTC)

evACC

@Useddenim: What would elvACC look like? Would there be one wheelchair or two? (This might need to be used for Church Avenue in the F and G NYCS diagrams.) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
09:18, 3 August 2017 (UTC)

It wouldn't look like anything. Because l (legend) icons only have single features, they can have either have no prefix (in use) or the ex prefix (completely out-of-use). Being partially out-of-use (e secondary feature, or x main feature) doesn't make sense. Useddenim (talk) 13:16, 3 August 2017 (UTC)
@Useddenim: Like   (uxmlvBHF), I meant. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
13:39, 3 August 2017 (UTC)
I sill don't get it, unless you mean station open, no longer any wheelchair access? That scenario has been discussed at en:WT:London Transport (I think), and the consensus was, IIRC, use the regular station symbol and leave the specifics to the actual station page. Useddenim (talk) 17:11, 3 August 2017 (UTC)
@Useddenim: No, as in, part of the station open but all of it has or would have wheelchair access. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
14:44, 4 August 2017 (UTC)
This would probably occur so infrequently (and even then, only be a temporary situation) that it would be best handled as a text note (or with overlays if you absolutely insist on illustrating it). Useddenim (talk) 17:04, 4 August 2017 (UTC)

Black INTs and DSTs

@Useddenim and Tuvalkin: I accidentally uploaded about 20 INT/DST duplicates in set black, not realizing that they have exactly the same geometry. Would it be better to do something to separate them (add masking/white outline like   (ZOLL), change the set black colour to something less saturated, decrease the INT circle stroke width…) or just leave them as they are? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
05:07, 19 April 2017 (UTC)

  • I vote for changing the color of all icons of set black to  RGB:333333  or some such. Back then I suggested this very change for this exact reason:  Black  is one of the special colors of BSicons, along with platform grey, light grey (“ex-black”), formations’ greyish green, white (inside DSTs etc.), and (sorta) water blue. Using it as the line color not only makes INTs and DSTs look identical but also clashes with things like   (TRAJEKT),   (GIP), and, of course,   (ENDEa). I can take care of the recolorings and their uploads: would have it done in 2 weeks, tops. -- Tuválkin 09:59, 19 April 2017 (UTC)
    • @Tuvalkin: Is there enough contrast?     #333333        #000000     Maybe 383838 or 404040 might be better, but not sure. I could probably reupload everything in the category automatically with pywikibot (I don't think it contravenes the bot policy since it's uploads and it's actually quite slow at 4/minute), although it might be a while since I probably won't be editing for some time. Jc86035 (talk) Use {{re|Jc86035}}
      to reply to me
      10:13, 19 April 2017 (UTC)
  • The idea behind changing line black to  RGB:404040  is exactly to enrure that there’s enough contrast with feature black, so no white lining is necessary. -- Tuválkin 08:33, 5 August 2017 (UTC)
  • Ah yes, that issue. (It would be good to move here from that discussion about set olive the part that is about set black…) Well, here’s the thing: The problem ehere is not the shapes and sized of DSTs and INTs, the problem here is that line black is (even when recolored) nominally and visually the same color as feature black, and we’re facing a basic design issue: If we chose to include in our diagrams special colors for fixed features to be used along with varying line colors, then we CANNOT have lines that use those colors. That’s a problem quite simple to avoid when creating iconography for a given system, but while trying to document and stylize the graphical options chose by the creators of thousands of such diagrams worldwide, we were bound to bump into this problem. I’m not sure what to do now, but to me the idea of creating a special set of INTs or DSTs for one line color is inherently abhorrent, as it goes against the very basic philosophy of BSicons: Line colors change, the rest does not.
Maybe what we should do is simply go ahead and allow that INTs or DSTs of black lines are almost indistinguishable, which is expactable when one accepts that black is also used for some features, and let the BSicon users (which we are, too) come to the conclusion that detailed diagrams, which make use of (black) line side features, are not compatible with multi colored line diagrams, more suitable for simpler uses.
-- Tuválkin 09:55, 5 August 2017 (UTC)
@Tuvalkin: An existing issue with the INTs and INTACCs, in any case, is that non-circular INTACCs are sometimes 50px, but sometimes 60px to match   (lvINT-L) and others (I think at least one of these was chosen arbitrarily after lack of participation in discussion). Regardless of the line colour, changing the INT stroke width to 50px would (technically) solve both problems. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
10:00, 5 August 2017 (UTC)
  • I’m not against that, at all. (Provided the change is done across all sets, not only for set black, yes?) -- Tuválkin 10:18, 5 August 2017 (UTC)
    • @Tuvalkin: Of course; only changing set black would be counterintuitive. Is a stroke width of 50px enough to distinguish DST and INT, or do you think a narrower stroke would be needed (i.e.   (PETERWHY-INT))? Using something different would necessitate reuploading all of the INTACCs as well, but there are only 156 of them, which is not that many in comparison to the 4,750 INTs. Jc86035 (talk) Use {{re|Jc86035}}
      to reply to me
      11:47, 5 August 2017 (UTC)
    • pinging Useddenim Jc86035 (talk) Use {{re|Jc86035}}
      to reply to me
      12:23, 5 August 2017 (UTC)

Three-quarter shifts

@Tuvalkin, Useddenim, and Lost on Belmont: Is there any advantage to having the odd shape of the SHI3 curves, just to match corner icons? Neither tunnel nor elevated corners match the SHI4 corners (the current at-grade corners don't match perfectly either), and I'm reuploading most of them for some reason, so the shape could be switched from M 250,0 C 250,198 625,302 625,500 to M 250,0 C 250,250 625,500 625,500. On the other hand, this would make it slightly harder to draw junctions between a SHI3 and a KRW, although those are probably quite rare. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
16:19, 4 August 2017 (UTC)

@Jc86035: IIRC, the SHI3 icons were drawn precisely that way in order to use the SHI4 corners and to align correctly with KRWs; but as you noted, that is a rare construct. So go ahead and make the needed changes. Useddenim (talk) 17:16, 4 August 2017 (UTC)
✓ Done; categories are yet to be sorted correctly. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
08:26, 8 August 2017 (UTC)

18

@Useddenim and Tuvalkin: Should a prefix be reserved for 18-width icons? These can't currently be rendered properly due to their width of 2.5px (which would be rounded up to 3 by MediaWiki), but they could be handled in Routemap since the module generates table cells for c, d and so on, instead of loading the images. This would be useful for w:en:Template:5 (New York City Subway service), since due to the use of quarter-width icons the maximum width is 65px and the collapsible sections currently need to be either 60px or 70px wide to be aligned correctly. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
08:25, 8 August 2017 (UTC)

  • I think so. Although too close for parallel stretches, it can be useful for tight spots, and this disrance can be obtained with the old templates (see f.i. what I did at depósito Ribeira in pt:Template:Elétricos de Sintra (diagrama)). Also, remember those old bub icons? They had 3 parallel lines on a single icon.
The matter of half pixels is separate from the nomenclature of BSicons: After all, if we redrew all BSicons at 400px instead of 500px, that matter would not arise.
Are we running out of letters, though? Maybe o, following Latin "octavus" and its derivatives?
-- Tuválkin 09:37, 8 August 2017 (UTC)
✓ Agree. Useddenim (talk) 12:24, 8 August 2017 (UTC)
@Useddenim and Tuvalkin: ✓ Done in Module:Routemap on English Wikipedia. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
14:38, 8 August 2017 (UTC)

Parallel 3/4 shifts

vSHI3
equal
space between
UNequal
space between

@Jc86035: Please compare the original icons with your new uploads. Useddenim (talk) 18:29, 13 August 2017 (UTC)

@Useddenim: This is deliberate. The double tracks I uploaded and re-uploaded are different to the single tracks like the   (vKRW) icons and use M 125,0 C 125,250 500,350 500,500 M 375,0 C 375,150 750,250 750,500. If necessary,   (utvSHI3+lr-SHI3+l) can be renamed to utvSHI3+l-Rr-SHI3+l-L to distinguish it from the icons with regular geometry (and the vKRWs can be renamed to vSHI4l, vSHI4l-L etc.). Jc86035 (talk) 03:27, 14 August 2017 (UTC)
I have modified the diagram to show a 12 gap instead of a 34 gap in the second row. Jc86035 (talk) 03:31, 14 August 2017 (UTC)
If we follow the pattern for the 4/4 shifts, then we need a different root (KR3?) to differentiate between 3/4 shifts with two lines vs a single-line SHI3. Useddenim (talk) 03:48, 14 August 2017 (UTC)
@Useddenim: I don't think so – it should be possible to distinguish double   (vSTR2-L) and single   (v-STR2) geometries without changing the root. There aren't even any   (vSHI4l) icons at the moment; it's impractical to make another root for this. Jc86035 (talk) 03:50, 14 August 2017 (UTC)
OK Useddenim (talk) 03:55, 14 August 2017 (UTC)

exdSHI1+r

exdSHI1+r

Should   (exdSHI1+r) be 250×500 size. Rowan03 (talk) 17:15, 15 August 2017 (UTC)

Yes. Useddenim (talk) 23:45, 15 August 2017 (UTC)

Diagonal roads

Diagonal roads

Should   (RP43+1) and   (RP42+4) to match corners. Rowan03 (talk) 00:29, 21 August 2017 (UTC)

@Rowan03: Yes. I can't fix it right now since I'm already working on some other things, so you could try aligning the dashes to the corner icons in Inkscape (requires XQuartz on Macs), opening the Inspector (Shift+Ctrl+X) and manually changing the stroke-dasharray if necessary, and then copying the code back from the Inspector into a text editor (e.g. Notepad++, BBEdit, TextEdit). (Don't drag objects with the cursor, change values manually. Lengths of 45° diagonals are height (y-axis) × √2 rounded to 2 decimal places. Import the corner icons using the Import button in the top left and then move them 500px.) Jc86035 (talk) 05:24, 21 August 2017 (UTC)

Diagonal bridge over river

Diagonal bridge over river

Should be   (WBRÜCKE2+4) and   (WBRÜCKE3+1)'s its river to match standard WASSER corner icons. Rowan03 (talk) 13:12, 25 August 2017 (UTC)

@Rowan03: Of course, but we don't have unlimited time to fix these things, and there are only so many people who can edit SVGs and are interested in doing this stuff. If you can read/write XML you might be able to fix it by copying code from   (WASSER2+4) to   (WBRÜCKE3+1) (and maybe additionally make the file use stroke-dasharray="..." instead of the mask). Jc86035 (talk) 16:27, 25 August 2017 (UTC)

BHFCC

BHFCC sky tBHFea tBHFa@f tBHFe@g
80px
BHFCC sky tBHFea tBHFa@f tBHFe@g
20px

@Useddenim and Tuvalkin: I've tried adjusting the tunnel portals very slightly for   (BHFCC sky) so the BHF circle doesn't overlap with the portals as much, matching the   (hBHFCCe) portals. (Currently the portals are a bit inconsistent.) Is it working? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
10:00, 17 February 2017 (UTC)

OK Looks good. Useddenim (talk) 11:14, 17 February 2017 (UTC)

✓ Done for the non-terminal stations in the two basic sets. Jc86035 (talk) 12:18, 5 October 2017 (UTC)

k curves

@Useddenim and Tuvalkin: Are k curves better as quadratics or arcs? I might reupload a bunch of them as arcs at some point (modifying the current code definition slightly to d="M 982.84,-250 A 732.84 732.84 0 0 0 250,482.84 V 500" to prevent the curves touching the corners), but the quadratic curve could end up being better if slightly adjusted. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
07:04, 12 March 2017 (UTC)

@Useddenim and Tuvalkin: Incidentally, what was the difficulty with creating the elevated icons? The only problem with the originals with quadratic curves (aside from the 60px formations) seems to have been that the formation coordinates were approximated to the nearest 10px instead of being to two decimal places, and so they were off by about 4px (no masking was actually needed). Jc86035 (talk) 12:14, 5 October 2017 (UTC)
  • It was probably that — and thanks for fixing this. I confess most my BSicon drawing is done byt cobbling together from previous originals, sometimes with some number jiggering, but rarely based on proper trigonometry groundwork. -- Tuválkin 12:20, 5 October 2017 (UTC)

Tunnel portals

@Useddenim: Which small tunnel portal shape should be used (or should both be used)? Yours   (dPORTALg) uses r=150, ∆x=190; mine   (tSTR2af) uses r=170, ∆x=190.21. I picked r=170 probably out of   (tdSTR3a) (I don't remember, really), which I had modified to move the tunnel portal slightly, although yours is closer to YLSS's   (tv-STRa). Jc86035 (talk) 06:40, 6 November 2017 (UTC)

I got my numbers through trial and error from the previous version of the icon, which used the SVG Bezier Curve rather than circular Arc function. Useddenim (talk) 11:16, 6 November 2017 (UTC)

ENDE width

@Useddenim, Tuvalkin, Lost on Belmont, and Newfraferz87: Is the ENDE width 200px or 220px? I had thought the 200px width was a mistake, but it turns out a lot of parallel and half-width icons, e.g.   (vENDEe) and   (utdENDEe), use it instead of the original 220px used in   (ENDEe). 200px may or may not be better for icons like   (hENDEe) where it actually matters slightly; currently the 220px formations cover part of the viaduct railings (I don't know if it serves a purpose). Right now it's extremely difficult for me to notice the overlap at 20px anyway, even on a screen with high pixel density, so it might be better to just use 200px for rendering reasons. Jc86035 (talk) 14:51, 5 October 2017 (UTC)

 nENDE Examples 
220 × 50
200 × 50
c nENDE Example
141.42 × 50
141.42 × 70.71

@Useddenim and Tuvalkin: Furthermore, should   (nENDEa) and similar have 100px × 50px bumper blocks (current 220px × 50px), or could the area be halved from that of the dENDE series (i.e. 141.42px × 70.71px)? Jc86035 (talk) 09:22, 3 December 2017 (UTC)

@Useddenim: As for the examples, note that even though you didn't include 100px × 50px,   (PSLa) already uses that size. I don't know if that should be changed as well but it'd be best to be consistent with it, I think. Jc86035 (talk) 13:31, 3 December 2017 (UTC)

HUB curves

@Useddenim and Tuvalkin: Should HUBs use circular arcs or quadratic curves? Currently most of them use quadratics, although that might be a relic of the unusually compressed formatting which avoids using anything verbose (including XML headers, the lack of which broke the files earlier this week when I purged all the BSicons). Jc86035 (talk) 13:46, 3 December 2017 (UTC)

Duplicates?

vÜWBol+l
vÜWBg+r

@Useddenim, Tuvalkin, Epicgenius, and Vunz: Should the geometry of   (vÜWBol+l) or   (vÜWBg+r) be used? (Both were uploaded by Useddenim, four years apart. There are a few other duplicates.) I'm not sure which track shape or formations (or file name) should be used. The icon should be consistent with both   (evÜWBl) and   (vÜWBol+lr), which is to say at least one of those two should be renamed (probably vÜWBl+lr, since the "o" seems to be implied; or evÜWBol). Jc86035 (talk) 03:48, 19 May 2018 (UTC)

In retrospect, I like the curved version better. I think I drew the tangent in an attempt to make more space for the formation. Useddenim (talk) 13:04, 21 May 2018 (UTC)



Shifts

@Useddenim: I don't think it's a good idea to suddenly start having perfectly parallel ¼ shifts like   (vSHI1r~l), because it doesn't really make sense given that there are a non-negligible number of diagrams with several parallel ½ shifts and given that it's basically impossible to make more than about three of them parallel at the same time. Isn't there a discussion from about five years ago which resulted in   (uvSHI2l) being changed to use the standard geometry? Jc86035 (talk) 03:57, 29 June 2018 (UTC)

I just realized that   (uvSHI2l) does have a non-standard curve, so the above is probably moot. However, there should probably be some matching corners first so that you don't end up permanently breaking lots of diagrams, or the geometry should be changed (with the logic that the connection should match a standard single line). Jc86035 (talk) 04:05, 29 June 2018 (UTC)

@Jc86035: I created   (vSHI1r~l) to try and fix a problem I was having with a diagram, but it turns out that the difference for a 1/4 shift is negligible. (However, as the displacement increases the difference becomes more and more noticeable; note that the 4/4 shifts are parallel:  .) But for now it's just a one-off. Useddenim (talk) 11:55, 29 June 2018 (UTC)

ZOLL

Separated from Talk:BSicon/Renaming#GRENZE vs ZOLL

To be honest, I wanted to raise this issue for quite a long time, but always postponed it. So,
My impression – don't know where I got that from, correct me if I'm wrong – was that the present design of   (ZOLL) was intended to make it different from   (GRENZE) and thus prevent it from being deleted as a duplicate. With that threat gone (hopefully), I think we might reconsider the geometry and the colours. I understand that Tuválkin as the author of that change might think different, but... To my eyes, the older one looks better. There are two issues:

  1. The ring in   (ZOLL) is both thicker and smaller in outer radius, so the inner space is much smaller and the icon looks really blurred and cluttered. Similarly, the distance between the ring and the black bar is reduced, so there is no space visible between them at 20px as in   (GRENZE), which was better – again, IMHO.
  2. The colour of the ring is too bright. Not as much as some were originally, but still. I does stand out in an RDT.   (GRENZE) uses #CC0000, which doesn't differ much from #BE2D2C, but... is that bad?

A minor issue is that the white outer ring, if kept at all, should be confined to the area where there's a track (like here). All in all, I could live with the older design... But I would really like you all to tell me that I'm a fool and that the newer design is much much better!! YLSS (talk) 22:22, 13 January 2015 (UTC)

Take a look at en:Comparison of European road signs#Checkpoints. (I'm sorry I did.) Useddenim (talk) 01:49, 14 January 2015 (UTC)
GRENZE GRZq+ZOLL ZOLL
GRENZE GRZq+ZOLL ZOLL


Tested a new design at   (GRZq+ZOLL). Can be seen at the bottom of fr:Schéma de la ligne de Creil à Jeumont. Opinions? YLSS (talk) 16:18, 14 March 2015 (UTC)

I like that new design, and it seems to work well at 20px — which was my concern when I created the alternative design for the ZOLL family. -- Tuválkin 22:36, 2 June 2016 (UTC)
@Tuvalkin: Maybe it might be better with a mask instead of the grey separator? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
07:32, 4 April 2017 (UTC)
I agree that the separation element should be all around, as a disc, to enable clean overlaying. (I’m not calling it a mask, but yeah.) -- Tuválkin 10:53, 4 April 2017 (UTC)
@Tuvalkin: I meant using an SVG <mask>…</mask> for the non-overlay icons; sorry for the ambiguity. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
10:55, 4 April 2017 (UTC)

@Newfraferz87: I think YLSS's design should be used, and four people is probably a pretty good consensus around here, although now I think the grey separator is probably fine. Jc86035 (talk) 08:05, 16 July 2018 (UTC)

@Jc86035: Haha you found me out while I was testing around with the icon.
By grey separator I guess you mean the off-white boundary around? One issue I had with it was that the coordinates have to be continuously changed based on lines' orientation, not sure if it would be better to integrate it into the circular disc? (Also @YLSS: @Tuvalkin: )   ~ Newfitz Yo! 08:47, 16 July 2018 (UTC)
Btw I compiled some numerical stats for the icons, just for reference (please ignore the last one):
@Newfraferz87: JJMC89 bot now makes daily logs of uploads, moves and deletions, and I've been checking them regularly for a while as a sort of quality control.
I think if the icon is going to use the BHF elevated formations then it should retain the black line, although right now neither the black nor white lines are noticeable at 20px–25px in the "random test". I think YLSS's proposal looks better than the original and should be used as the base if all of the ZOLL/GRENZE icons are to be replaced. Jc86035 (talk) 07:45, 17 July 2018 (UTC)


@Jc86035: I uploaded     (hZOLL) with the black border, what do you think of it?   ~ Newfitz Yo! 12:50, 17 July 2018 (UTC)
@Newfraferz87: I've uploaded one with the standard formations style over it (I didn't realize the circle was slightly smaller). I don't think it's actually visually distinguishable from YLSS' design at 20px, but it makes more sense with the formations when it's at 500px. I'm not sure what else to do with it, though. Is it good enough as it is? Jc86035 (talk) 13:19, 17 July 2018 (UTC)

lvBHF2+4, uhSHI4+lq and RBoWq+ZOLL

I see 2 geomtric errors with 2 BSicons:   (lvBHF2+4) and   (uhSHI4+lq). First, lvBHF2+4 has a mask overlay behind it(which is slightly higher brightness than   (MASK), making it useless as a station on a diagonal paralell line, and secondly, uhSHI4+lq has the elevated formation touch the entire track. 86.22.8.235 19:07, 14 September 2018 (UTC)

I forgot something,   (RBoWq+ZOLL) should be light blue instead of dark blue — Preceding unsigned comment was added by 86.22.8.235 (talk) 19:34, 14 September 2018 (UTC)

✓ Done all. Jc86035 (talk) 11:13, 27 December 2018 (UTC)

3 stations

3HSTq
text
text
text
text
text
text
text
text
text
text
text
text

@Useddenim:   (ue3HSTq-) just seems a bit... wrong to me. I would have made a ue3HSTq- with the line in the usual place and then a uex[l]3HSTq-~FF with the rest of the station at the bottom of that icon's frame. Jc86035 (talk) 14:35, 26 December 2018 (UTC)

You mean something like this? I could see uses for both versions. Useddenim (talk) 15:09, 26 December 2018 (UTC)
@Useddenim: Yes, like that. I think if there's to be something like the current   (ue3HSTq-) it would be better to make it go into the normal top parallel line, but then that would just be   (uvSTR+lg-) +   (udHSTq-) +   (uv-STR+rg). Jc86035 (talk) 17:57, 26 December 2018 (UTC)
@Useddenim: I've uploaded udHSTq-. There doesn't seem to be that much difference, and I think keeping the smooth curve would be better than forcing the station circle to be as close to the edge as possible. Jc86035 (talk) 11:16, 27 December 2018 (UTC)
@Useddenim: This was fairly unnecessary, but I've also uploaded   (vvSTRl~r),   (vvSTRl~r~r~L), and other assorted connecting pieces, which would allow a station to use the normal ~F/~G icons (e.g. at w:en:Template:RER C). Jc86035 (talk) 18:42, 6 January 2019 (UTC)

Expansion (i.e. making the page more useful)

@Useddenim, Tuvalkin, and Epicgenius: I've expanded the "deriving new icons" section so that new people (if any) don't have to spend hours figuring out how some of this stuff works. I made   (hkBHF+4 geometry) and the other two a year ago, but didn't put them anywhere because I wasn't sure what to do with them. Would more icons like them be useful? Jc86035 (talk) 17:33, 22 January 2019 (UTC)

A very good start. I will have to examine it in more detail, though, when I have some time. And yes, It's always nice to find that someone else has already done the complicated math when one of those esoteric icons is needed. Useddenim (talk) 17:55, 22 January 2019 (UTC)
I agree. It would be good to make more icons like these, because it would probably help more users - both new and experienced. epicgenius (talk) 18:50, 22 January 2019 (UTC)

Tunnel tracks across

@Useddenim, Tuvalkin, and Epicgenius: Is there an agreed geometry for tunnel tracks across in narrow icons? I was planning to mass-reupload these icons (along with a batch upload of similar icons with larger widths), and I realized that the existing icons were both internally inconsistent and inconsistent with other tunnel BSicons.

Icon Date Uploader Dashes
  (utcd-STRq) 13 June 2014 Useddenim 48.4375,48.4375,48.4375,(...),48.4375
  (tdSTRq) 18 January 2009 Axpde 50,62.5,62.5,62.5,50
  (utd-STRq) 5 June 2012 Useddenim 75,50,50,50,75
  (utcSTRq) 17 February 2013 Useddenim 66.66,41.66,66.66
  (utcSTRq-) 13 June 2014 Useddenim 56.25,62.5,56.25

Italics indicate dashes that aren't 50px long, assuming that the dashes always start 25px before the left and right icon borders. I would have thought that most of the geometries would follow the usual convention of having all the dashes be 50px long – 50,75,50 for tcSTRq and 50,43.75,50,(...),50 for tcdSTRq. For tdSTRq, most of the existing icons have a 62.5px middle dash, and it might be preferable to keep that (although if the middle dash should be wider then 60,60,60,60,60 might be better). Jc86035 (talk) 15:02, 2 February 2019 (UTC)

pKBHFs

Ehh...

Maybe things like (basically KBHFs with p's and optionally u's, h's, and t's) could be uploaded? They could very well be used in some railways that don't stop at a huge station. These include:

  • tpKBHFa and tpKBHFe (whose bound to come up somewhere in a metro)
  • their u versions,
  • and their h and their at-level versions.

Any thoughts?

Ben79487 (talk) 23:25, 3 April 2019 (UTC)

Au contraire, pKBHF is very unlikely to be needed, as it's a major problem if a train attempts to bypass a terminal station. Useddenim (talk) 16:35, 4 April 2019 (UTC)
Meant that the train doesn't stop there (for example, if the route usually starts at station A but some Ltd. Express services stop at station B further down and don't come up to the section with station A. Hehehe. :) – Ben79487 (talk) 01:48, 9 April 2019 (UTC)
It sound as if you're asking for something to be used in a schedule chart as opposed to a route diagram (en:Template:Tel Aviv suburban railway map vs. en:Template:Israel Railways routemap). Useddenim (talk) 17:56, 10 April 2019 (UTC)

Should these be redrawn (and renamed) to be compatible with standard generic road icons overlaid with   (unSTR) etc.? E.g.   (RP4+T) unSTR+RP4/RP4+unSTR. Useddenim (talk) 17:07, 3 April 2019 (UTC)

Looks better to me at least.Deonyi 03:36, 6 April 2019 (UTC)
@Deonyi: Which one looks better? Useddenim (talk) 18:11, 10 April 2019 (UTC)
The thicker one, using   (unSTR) looks better to me. Although, evidence of use would be good and I would hesitate before creating routemaps for tram routes in such detail, though I suppose the Russian wikipedia can do as it pleases. Deonyi 12:35, 11 April 2019 (UTC)
  • Let me say this again: Detail is okay, but if one wants detail, then lets use regular icons instead of replicating everything at a smaller scale (that’s why I abhorr the whole n subset). Does it look too big on the page? — well, use PX=10 instead. -- Tuválkin 17:00, 11 April 2019 (UTC)

TBHF

α
β
γ
δ

@Useddenim and Tuvalkin: I've done some testing with potential redesigns for the   (TBHFo) series, since there isn't really an obvious way to do it. Does any one of these seem better than the others? Jc86035 (talk) 16:48, 1 August 2019 (UTC)

Either β (Straight crossing formations) or δ (Rounded viaduct formations) but not γ (Straight viaduct formations). Useddenim (talk) 19:22, 1 August 2019 (UTC)
  • I like them all, visually — the difference is negligible at 20px, and at a larger size I would approve either “message”, either straight or bent. Alas, not both, though, as different realizations of this detail in simultaneous use could be misconstrued as significant and contrasting.
That said, I would like to support the notion that the smaller bridges are the real TBHFos/TBHFos and that the larger bridges are hBHFaes, regardless of the presence of a second line, crossing below.
-- Tuválkin 15:24, 2 August 2019 (UTC)
Good point. So, does that mean we've settled on β for the tBHF/tINT icons? Useddenim (talk) 20:47, 4 August 2019 (UTC)
@Useddenim: I think so, yes. My main concern was that it leaves a narrower gap than the   (THSTo) formations, but I guess it doesn't really matter since there are only two station sizes in the first place (and both would have to be different for the 45°-angle formations anyway). Jc86035 (talk) 15:11, 7 August 2019 (UTC)

Shift crossings

α
β
γ
δ
ε
ζ

@Useddenim and Tuvalkin: To my knowledge, there isn't a convention for drawing crossings like tSHI2l+xl and tSHI3l+xl. (I omitted icons like the latter in the mass upload of SHI3 icons, because I couldn't find a satisfactory way to draw them.) Both icon groups have an even number of dashes for each track, so the overlap at the crossing is difficult to draw, especially if the angle isn't close to 90°.

Do any of the proposed designs work well? I'd be somewhat reluctant to change the dash spacing, but it's possible that it would still be the best option. Jc86035 (talk) 16:36, 4 August 2019 (UTC)

I think ζ (dash spacing decreased) looks best at 20px. Useddenim (talk) 20:47, 4 August 2019 (UTC)

Width of ENDE

At Category:BSicon/railway/half-width/line_endings (and probably elsewhere in cats about endings) we can see varying widths for the black/grey orthogonal block that constitutes the line ending icon. This should be homogenized across all icons. -- Tuválkin 12:27, 12 August 2019 (UTC)

@Tuvalkin: A while ago the width was changed to 200px for all of the normal-width icons. I've uploaded a bunch of half-width icons (and duplicated them into all of the other sets, because why not), though there are probably a few left over. Jc86035 (talk) 14:14, 12 August 2019 (UTC)
@Tuvalkin: Sorry, what I meant to say was that the width was changed (across all icons) but I originally only uploaded the normal-width icons and left the others for later. I've reuploaded most of the half-width icons as well as some of the parallel lines icons. Jc86035 (talk) 14:41, 13 August 2019 (UTC)

BHFSPL

BHFSPLe over uvBHF-KBHFe
Old
(BHFSPLe's blob is smaller)
New
(BHFSPLe's blob is the same)

¿Wouldn't it be better if   (BHFSPLe) and the alike had straight lines coming to and from the station blob, like this:   (BHFSPLe)? This would be consistent with other icons whose single line is a parallel line, like   (vBHF-KBHFe) --Snooze123 (talk) 17:28, 28 March 2020 (UTC)

@Snooze123: That is in fact how they used to be, as you can see in the file history of   (BHFSPLe), but it was changed in 2011 to make it clearer that the lines are supposed to be continuous. You can still get the same shape by using   (vKBHFe) over   (KSTRa), but it would represent the terminus of three lines, not a station where two lines meet at a junction. Jc86035 (talk) 17:37, 28 March 2020 (UTC)
Furthermore,   (BHFSPLe) =   (BHFSHI1+l) +   (BHFSHI1+r). Jc86035 (talk) 17:39, 28 March 2020 (UTC)

Shady arrows

At pt:Template:CPLisboa, drawn at 16px high,   (vCONTg@G ochre) looks a bit hazy and doesn’t match exactly the   (vSTR ochre) that follows. Any ideas? -- Tuválkin 18:44, 1 July 2020 (UTC)

Mismatched red-yellow roads

moved from Talk:BSicon/New icons and icon requests

Also   (RAoW) rotated 90 degrees --Trainsofvictoria (talk) 08:23, 16 August 2020 (UTC)

@AlgaeGraphix: It doesn't work next to   (RAq)
eg.
--Trainsofvictoria (talk) 03:13, 19 August 2020 (UTC)
@Trainsofvictoria: I should be working properly now KokoiMatsuchi (talk) 09:09, 23 August 2020 (UTC)

Naming conundrum

Moved to Talk:BSicon/Renaming#Naming conundrum
AlgaeGraphix (talk) 02:27, 25 August 2020 (UTC)

Too big

@Dimlys1994: Compare   (PSLe denim)’s 12 kb with   (PSLe)’s 821 bytes. This and other similar icons at Category:BSicon/railway/set denim need to be tagged with {{TracedSVG}} or corrected. -- Tuválkin 17:33, 30 September 2020 (UTC)

• Files tagged, can't correct myself. Thanks for noticing Dimlys1994 (talk) 18:40, 30 September 2020 (UTC)

Bridge icons

I think there is an issue with some of the bridge icons for minor roads. If you have to place   (uSKRZ-Yu) or   (uexSKRZ-Yu) and   (gSKRZ-Yu) side by side as on Wikipedia:Buckingham Arm, the borders of the yellow road in the unwatered green icon are not the same as in the watered blue icon.   (RYq) is the same as the watered bridge. I would normally download the icon, fix it, and upload it again, but the option to download icons seems to have disappeared. You always end up with a png rather than the svg. I prefer the blue icon road style, but I note that the yellow road over red railway   (SKRZ-Yu) seems to use the same style as the green icon, rather than the blue. Can anyone suggest a solution? Bob1960evens (talk) 17:51, 12 December 2020 (UTC)

To download the svg-file you need to click on "Original file". --PhiH (talk) 18:38, 12 December 2020 (UTC)
Thanks for the tip. I downloaded   (gSKRZ-Yu) and   (uSKRZ-Yu), copied the source for uSKRZ-Yu to gSKRZ-Yu, changed the colour, and uploaded it. It doesn't look any different on the icon page, but I am hopeful it will match on WP when the icon finally arrives. Bob1960evens (talk) 19:16, 12 December 2020 (UTC)
It now looks the same on WP. Bob1960evens (talk) 23:15, 12 December 2020 (UTC)

TINT interchange stations

INT
TINT

I've noticed that some TINT icons (interchange station where 2 lines cross) look a little strange. The black outline of the white station is a little too thick. Compare Pape station to Osgoode in en:Template:Ontario Line, Osgoode uses 2 overlayed icons and looks better in my opinion. Blaixx (talk) 12:42, 6 June 2019 (UTC)

They should be all identical, yes, as discussed long ago. I‘m surprised there is still some variation. -- Tuválkin 10:25, 7 June 2019 (UTC)
@Blaixx: Unfortunately I never got around to them; I'd held off on these mainly because I'd have to redraw the formations of icons like   (TINTo) properly before re-uploading them, since they use viaduct formations instead of crossing formations. Maybe in a little while. Jc86035 (talk) 12:17, 30 July 2019 (UTC)
@Jc86035: I may give this a try myself now that I have a better understanding of SVGs and BSicon conventions. It should be as simple as changing the circle radius to 125 and the stroke-width to 50. Blaixx (talk) 15:41, 2 January 2021 (UTC)

uw crossing + junction

Some new icons have been uploaded that neither match the existing ones nor conform to the naming conventions. Specifically:

Cmuelle8's
creation
Proper
icon
Orthogonal
equivalent
  (exKRZ2+4g)   (exKRZ2+4l)   (exKRZl)
  (exKRZ2f+4g)   (exKRZ2+4l+r)   (exKRZl+r)

If no-one objects I will nominate them for deletion shortly. AlgaeGraphix (talk) 12:30, 17 July 2021 (UTC)

Parallel Tracks to 3 Single Tracks Transition

Parallel Tracks to 3 Single Tracks Transition
uvSTR
uvÜST
uSTR+1~F\uSPLe!~uvSTR3-~G!~uv-STR2~G\uSTR+4~F
uSTR+1~G\uSTR\uSTR+4~G
uvSTR
uvÜST
uSTRc2\uSPLe!~uvSTR3-!~uv-STR2\uSTRc3
uSTR+1\uSTR!~uSTRc14\uSTR+4
uvSTR
uvÜST
udSHI3c2\uv-SHI3r!~uv-SHI1l\uvSHI1r-!~uvSHI3l-\udSHI3c3
uSTR\uSTR\uSTR

Are these the only ways to transition a parallel tracks into 3 single tracks? Is there a way to do similar to the first one but with a 45° diagonal and smooth down to a single track? Thanks! Xeror (talk) 02:16, 15 January 2022 (UTC)

(I don’t have a proper answer right now, but I had to add two   (uvÜST)s at the stem of the forkings, it was making me twitchy! -- Tuválkin 06:37, 16 January 2022 (UTC))
@Tuvalkin: The crossover would only be necessary if the lines carry bidirectional traffic. Useddenim (talk) 15:51, 1 March 2022 (UTC)
@Xeror: I added a third version that's *close* to 45°. Is that what you want? Useddenim (talk) 13:21, 22 January 2022 (UTC)
@Useddenim: : Yes! It is. Thanks! Xeror (talk) 23:04, 22 January 2022 (UTC)

Thickness of Elevated Structure of Road Icons

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