Talk:BSicon/Renaming/Archive 12

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
Archive 5 ← Archive 10 Archive 11 Archive 12 Archive 13

45° junctions

@Useddenim, Tuvalkin, Epicgenius, and Axpde:

Current Proposed
  (ABZq+1) etc. ABZq1
  (ABZq3) etc. ABZq+3

Can we do this? This is primarily because

  • +1 currently doesn't indicate which side of the icon the line from the corner goes to, but +1 in   (ABZg+1) does;
  • ABZg1 is currently a valid name and would be   (STR1) +   (STR), whereas ABZq1 is currently undefined, and if it were made to be   (STRl+1) +   (STRq) the logic wouldn't make much sense (since it would still be coming from the back of the icon).

It's also fairly clear now that

  • the naming rules for 90° ABZs are separate (i.e. g+4/q+4 curves are different; g+r/q+r curves are the same, so logic would be inconsistent anyway) and can be ignored for this;
  • "q" specifically means "rotated 90° anticlockwise" per   (STRfq), so it would be fairly logical to allow +3 to be used here to mean "[down the line, which is now towards the left] from 3".

Jc86035 (talk) 10:50, 29 April 2018 (UTC)

  •  Disagree The icons are perpectly named!   (ABZq+1) means track running across (q) and from corner 1 (+1). Your silly "rule" to rotate BSicons in a certain direction makes them uncomprehensible! Please stop your trials to fix things which aren't broken! a×pdeHello! 15:35, 30 April 2018 (UTC)
    @Axpde: How can you say they're already perfectly named? In the context I agree they're not problematic right now (if that's what you mean), but there's no harm in making the names better. There's obviously work to be done even on the ABZ root, given that there are still zigzag and wye icons which are named idiosyncratically.   (ABZ3+1lr) is fairly obviously wrong, since that name for an icon created now would be  . Changing the way that the "q" suffix is defined here is something that would help us in renaming those icons and creating new ones which aren't limited by the current system (for example, that zigzag icon might be called ABZ(3+1)l+r or ABZl3+1r or ABXql+r, and this would build upon the redefinition of "q"). Jc86035's alternate account (talk) 11:30, 2 May 2018 (UTC)
    Didn't claim all BSicons are perfektly named,   (ABZ3+1lr) shoulde be   (ABZr3+1l)! a×pdeHello! 14:30, 2 May 2018 (UTC)

✓ Done Jc86035 (talk) 11:35, 20 May 2018 (UTC)

WSTR

@Useddenim and Tuvalkin: Should   (hWSTR) etc. be renamed to treat W as "this track is water" rather than "this track crosses water" (i.e. to KRZW;   (WBRÜCKE2) would probably become KRZWo2 or 2KRZWo or something similar)? This would reconcile the railway icons' naming with that of the water junctions like   (WABZgl). This was originally advocated by YLSS in 2014, though I didn't think it made sense until renaming   (kWKRZq+4u) in October. Jc86035 (talk) 14:02, 24 December 2017 (UTC)

Axpde, I have not reverted you, but I would like you to move   (hWSTR) to   (hKRZW) again and keep it there until you have managed to overturn the consensus above that the W prefix should be used consistently. The file move was discussed here (with that exact file as an example). Don't revert a single file move just to make a point; I moved every file whose name contained "WSTR", and if you want to disagree you are very much welcome to ask about it here instead of clicking revert and not bothering to deal with any of the other similar files that I moved. I am currently aware that I made some errors in this process, like moving   (hWSTRq) to   (hKRZWq) instead of the shorter   (WKRZh), but my main account is "on a wikibreak" (i.e. I locked myself out of it) so I am technically unable to move any files right now.

KRZ means "crossing of to TRACKS", it has every been so and there is no need to overturn a consensus!
It wasn't YOU who invented this system so please don't change things which are contrary to the inventors system! a×pdeHello! 12:56, 2 June 2018 (UTC)
@Axpde: The BSicons cannot be owned by anyone (since they are, after all, hosted on a publicly editable wiki), so gatekeeping the system to those who were around in the mid-2000s would be pointless. As far as I am aware the "system" was created after consensus on 30 September 2006 by Bernina (please correct me if I'm wrong); even icons uploaded on that day have been renamed. In any case, I am the uploader of three-quarters of the BSicons that currently exist and uploaded my first in 2013, and have made more than ten thousand file moves, so you cannot say I did not have a part in it. It's true that many of them are differently coloured copies of icons that previously existed, but even then I have uploaded and redesigned thousands of others.
„Kreuzung“ bedeutet "crossing", richtig?
KRZ has been repurposed for roads (as SKRZ) and for paths (as fKRZ), so it clearly isn't limited to tracks.   (SKRZ-Bu) existed in 2007 as AKRZ-UKu. Jc86035's alternate account (talk) 13:46, 2 June 2018 (UTC)

@Tuvalkin and Useddenim: The errors mentioned are in the titles of these 19 files. I would prefer not to move them to titles which use "l" and "r" somewhat ambiguously, but the current convention, per   (KRZhl), seems to be to ignore that. Jc86035's alternate account (talk) 09:12, 2 June 2018 (UTC)

The files
Current Should be
  (exhKRZWaq) exWKRZhl
  (exhKRZWeq) exWKRZhr
  (exhKRZWq) exWKRZh
  (extKRZWq) exWKRZt
  (hKRZWaq) WKRZhl
  (hKRZWeq) WKRZhr
  (hKRZWq) WKRZh
  (hdKRZWq) hdKRZWq
  (tKRZWq) WKRZt
  (tKRZWq red) WKRZt red
  (uexhKRZWaq) uexWKRZhl
  (uexhKRZWeq) uexWKRZhr
  (uexhKRZWq) uexWKRZh
  (uextKRZWq) uexWKRZt
  (uhKRZWaq) uWKRZhl
  (uhKRZWeq) uWKRZhr
  (uhKRZWq) uWKRZh
  (uhdKRZWq) uhdKRZWq
  (utKRZWq) uWKRZt

Fill icons

So I just uploaded   (FILL2),   (FILL3), and   (FILL4) (complementing   (FILL)) so that there will be more fill icons. They are based off Wikipedia templates en:w:Template:Maybe, en:w:Template:Yes, and en:w:Template:Operational respectively. Is there a particular naming convention I should have followed? epicgenius (talk) 20:03, 26 May 2018 (UTC)

Ideas

@Useddenim and Tuvalkin:

  1. Since we now have an established model for referring to secondary and auxiliary objects, I thought it might be useful to expand it. Apostrophes (and maybe quote marks) could be used as "prime" marks for icons with more than one auxiliary object, to indicate that a prefix or suffix referring to an auxiliary object refers to the second or third auxiliary object.
    • For example, to fix the suffix ambiguity of using l and r to indicate bridge start/end as well as curves in crossings, treating the two formations as separate objects,   (hSKRZ-G2hlu) could be renamed hSKRZ-G2hua' (not sure about the suffix order right now; I changed it to this ordering from an incorrect ordering because it would alleviate the aforementioned issue). This is not particularly intuitive, but   (KRZhl) would then be just   (KRZha) since there is only one bridge to which a can be applied (it can't be used for the tracks since the K suffix would be needed for it to indicate the start of a track).
    • This could also be used in other icons where there are multiple formations or structures.
    •   (hdKRZ) and   (dKRZmu) should be consistently named. Perhaps a suffix could be applied to indicate that the bridge formation is narrow. n' is a possibility (n on its own would refer to the line across – it's the secondary object, but I don't know if that matters).
  2.   (ABZ3+1lr) and similar icons have a nonstandard naming structure right now. Maybe the grave accent ` (or some other character like the comma) could be used as a separator between regular positional suffixes (e.g. 3+1 in   (STR3+1)) and specific positional suffixes (e.g. +l in   (WSL+l)).
    • ABZ3+1`r+l (or ABZ3+1,r+l), for the aforementioned ABZ3+1lr, would indicate 3+1 to be the "main track", and r and +l to be "curve from back [1] to r" and "curve to front [3] from l".
    • vÜWB2+r`l+r (or vÜWB2+r,l+r), obviously a hypothetical example, would indicate 2 and r to be the tracks' end and start points, with l+r being similar to the curves in   (vÜWBl+r). The real icon would pose some very odd geometry issues, but SHI and ÜST icons could definitely benefit from this.
  3. Currently exSTRq-BHFq is ambiguous. Using the grave accent (or some other character like the comma) in front of prefixes which are used before d's position, to separate the prefixes where d would be, could be a solution to the ambiguity.
    • extBHFq-BHFq indicates that both stations are out of use.
    • t`exBHFq-BHFq (or t,exBHFq-BHFq) would indicate only the upper station to be out of use. (This doesn't necessarily have to be done, but the suffixes being out of order might not be a very clear signifier.)
    • ex`tBHFq-BHFq (or ex,tBHFq-BHFq) would indicate the upper line to be in tunnel.
    • tBHFq-exBHFq indicates that the lower station is out of use, and that both lines are in tunnel.
    • `tBHFq-exBHFq (or ,tBHFq-exBHFq) would indicate the lower line to be out of use, and the upper line to be in tunnel.
  4. Things that have nothing to do with renaming:
    • How are tunnels affected by the ~L/~R/~F/~G suffixes? Are the dashes transformed, or do they line up correctly? A set of misaligned dashes (with connecting icons) would actually be somewhat useful, because then we would be able to have a   (tdSTRq) that doesn't make diagrams look weird.
    • There should be a standardized way to draw unpaired tunnel dashes, like those in   (utPSLa). It would be much easier to keep tSTR~ undefined, really, because having it opens the door to icons like tSHI.01l~ (or something like that) where the line moves from 220px to 225px, and would probably lead to a very unnecessary rabbit hole. However, it would be useful for the "track change" icons, so I would keep the connecting parts at 220px/280px but have the rest of the points at their positions in the at-grade icons.

(Please reply using the indents :#, ::#, …, if using lists within the reply.) Jc86035's alternate account (talk) 11:12, 2 June 2018 (UTC)

Flyovers

@Useddenim, Tuvalkin, Vunz, and Epicgenius: Since the duplicates in this category have two different and currently valid naming schemas:

Current Proposed
  (vÜWBl) ✓[OK]
  (vÜWBr) ✓[OK]
  (exvÜWBg+l) exvÜWBr+r
  (exvÜWBg+r) exvÜWBl+l
  (exvÜWBgl) exvÜWBl+r
  (exvÜWBgr) exvÜWBr+l
  (vÜWBg+l)
  (vÜWBor+r)		 vÜWBr+r
  (vÜWBg+r)
  (vÜWBol+l)		 vÜWBl+l
  (vÜWBgl)
  (vÜWBol+r)		 vÜWBl+r
  (vÜWBgr)
  (vÜWBor+l)		 vÜWBr+l
  (vÜWBol+lr) vÜWBl+lr
  (vÜWBor+lr) vÜWBr+lr
  (uvÜWBol+lr) uvÜWBl+lr
  (uvÜWBor+lr) uvÜWBr+lr
Crosses over to left
vÜWBl		 Crosses over to right
vÜWBr
No lines through   (vÜWBl)   (vÜWBr)
Left line through +l   (vÜWBl+l)   (vÜWBr+l)
Right line through +r   (vÜWBl+r)   (vÜWBr+r)
Both lines through +lr   (vÜWBl+lr)   (vÜWBr+lr)

The icons are still restricted by the naming pattern to down the page/across the page orientations, although I don't think this is too much of an issue right now. Jc86035 (talk) 12:53, 19 May 2018 (UTC)

  • What’s the problem with across-oriented versions of these?
e.g.:   (vÜWBol+r)  q̿    (vÜWBol+rq)
No problem! -- Tuválkin ✉ ✇ 00:44, 21 May 2018 (UTC)
@Tuvalkin: I was referring to using 45° and other curves. Jc86035 (talk) 04:54, 21 May 2018 (UTC)

✓ Done Jc86035 (talk) 12:11, 17 June 2018 (UTC)

Double-stripe tracks

@Useddenim: Why rename   (mtSTR+1 red+blue)? Using + instead of ~ causes naming conflicts for stations;   (uemBHF). (A character other than ~ should probably be used due to the {{Routemap}} character restrictions, although I don't know what to replace it with.) Jc86035 (talk) 14:26, 29 June 2018 (UTC)

That was a mistake. I stopped renaming the color~colour icons before I got to   (mtBHF red~blue) &   (mtBHF+1 red~blue), but I couldn't undo the change to   (mtSTR+1 red~blue),   (mtSTR3+1 red~blue) &   (mINT-L green~yellow). On the other hand, using ~ as the connector dovetails perfectly with its use for lower-case suffixes: “half of primary object”. Useddenim (talk) 22:11, 29 June 2018 (UTC)
@Useddenim: I've renamed them all back. Jc86035 (talk) 22:17, 29 June 2018 (UTC)

Parallel lines across

@Useddenim, Tuvalkin, and Epicgenius: Following on from the block of text I posted a while ago, do you have a preference for any of these? It should probably be resolved at some point.

  1. Grave accent; ` (or some other character) goes where v would be in cases where the icon name is ambiguous
    •   (`exSTR+ro-STRr)
    •  (`exDSTq-BHFq) 
  2. Creation of ~q suffix; same as q but it can only apply to all of a parallel lines block and not its components, similarly to the other new tilde suffixes
    •   (vSTRl-exSTRro~q)
    •  (vBHF-exDST~q) 
  3. Status quo; standard-width icons cannot contain transverse parallel lines with two roots without naming restrictions
    •   (STR+xro-STRr)
    •  (exDSTq-+-BHFq) 

I think I prefer the first option, since it doesn't necessitate the rotation of curves. —Jc86035 (talk) 16:11, 7 July 2018 (UTC)

I would suggest Option 1, but use ^ (the caret symbol, ⇧ Shift+6 on US keyboards) as the inverse of v. Useddenim (talk) 00:15, 8 July 2018 (UTC)
@Useddenim: I think using the caret sounds better (I haven't updated my comment to reflect this). Should the caret always be used, or only be used for ambiguous cases, or somewhere in between? I would probably only choose "always" (i.e. ^-STRq) or "as little as possible". Jc86035 (talk) 03:30, 8 July 2018 (UTC)
Apply the KISS principle: therefore, as little as possible/only as necessary. Useddenim (talk) 12:23, 8 July 2018 (UTC)
I suppose Option 1 works as well since it's concise. epicgenius (talk) 12:26, 8 July 2018 (UTC)
[e] [x] ex
vSTRq        
DSTq-BHFq  
DSTq-BHFq		  
DSTq-exBHFq		  
^exDSTq-BHFq		  
exDSTq-BHFq
t [et] [xt] ext
tvSTRq        
tDSTq-BHFq  
tDSTq-BHFq		  
tDSTq-exBHFq		  
t^exDSTq-BHFq		  
extDSTq-BHFq

@Useddenim and Epicgenius: t^exDSTq-BHFq or texDSTq-BHFq? The suffix order makes the latter distinguishable, although it's still somewhat ambiguous. (Obviously this layout would be incorrect in a real table because of e in e.g. evBHF modifying the station rather than one of the tracks, but you get the idea.) Jc86035 (talk) 13:47, 8 July 2018 (UTC)

Wouldn't the prefix be ext, rather than tex? In any case, I'd rather go with t^ex to avoid confusion. epicgenius (talk) 13:50, 8 July 2018 (UTC)
@Epicgenius: No, the ex only modifies the DST. Compare   (vexBHF-DST) and   (exvBHF-DST). Jc86035 (talk) 13:53, 8 July 2018 (UTC)
OK, I get it now. In your example, it's v (entire icon) plus exBHF (left) plus DST (right) for the first icon; as opposed to exv (entire icon) plus BHF (left) plus DST (right) on the second icon. epicgenius (talk) 13:56, 8 July 2018 (UTC)
Now that I've added visual examples to the table, I endorse this proposal wholeheartedly. In fact, using the ^ now reads (to me) as "up, then down"… Useddenim (talk) 16:12, 8 July 2018 (UTC)
  • (Edit conflict) I must be incredibly stupid but I still cannot understand what the problem is. What’s the in the way of naming vFOOq the 90° anticlockwise rotation of vFOO, for any imaginable (square*) FOO? *(I can see the fundamental difference between these two types of icons in that diagrams are contructed with rows, not columns, but that dosn’t invalidate the overall approach.) -- Tuválkin ✉ ✇ 14:00, 8 July 2018 (UTC)
    @Tuvalkin: This is actually quite a good point, because now we have @f and @g and we can use those instead of abusing the horizontal parallel lines syntax. However, eliminating the horizontal "shorthand" style would still be more confusing and I would probably not like it, because   (-STRl+4) would become vSTR+1-q. As far as I can tell (correct me if I'm wrong) there was some sort of consensus for doing this, according to Talk:BSicon/Renaming/Archive 5#Parallel lines across, and because we don't have any rotated curves (excluding shifts and the 3-curves which are named as though they are straight tracks) it's probably better to keep the horizontal parallel lines syntax. Jc86035 (talk) 14:29, 8 July 2018 (UTC)

Roads

Moved to Talk:BSicon/Renaming/Roads#Roads
23:41, 31 July 2022 (UTC)

ZOLLs and water crossings

@Newfraferz87: Welcome back. A lot has happened; for example, we now have about ten new suffixes, and the W affix is now supposed to always work like L; i.e.   (WABZgl) and   (hKRZW). This probably makes things more difficult but is more logical. I've renamed e.g.   (hKWZOLLaxe) to TKZOLLWxeo (no conflict with formations a/e because of K prefix).

Thanks :) So the position of the W now follows the orientation of the waterway. However, this implies a conflict with   (hWHSTae),   (hWDSTae) etc., which I named hWZOLLae after (it is now   (TZOLLWo)). Would there be a standardization for the stations as well?   ~ Newfitz Yo! 08:18, 16 July 2018 (UTC)
@Newfraferz87: Yes, but no one's gotten to them (incidentally, I also wrote BSicon/Guide for doing things to a lot of icons). I believe   (hWHSTae) should be hTHSTWae, but as for the others it's not clear to me whether they're actually elevated. There is also a conflict with   (hKRZWaq), which I accidentally batch-renamed without having removed the q. I'm not sure if that icon should be WKRZhr, but I don't want to use that name because the l and r suffixes themselves cause naming conflicts. Jc86035 (talk) 08:27, 16 July 2018 (UTC)

@Useddenim and Tuvalkin: Is it correct to omit the h prefix in   (TZOLLWo), like it is for   (mTBHFo)? Should the formations go around the ZOLL? Jc86035 (talk) 07:53, 16 July 2018 (UTC)

The   (TBHF) prefix+ROOT combination should imply the existence of the elevated structure (but this example doesn't; perhaps it should be renamed to BHFKRZ, similar to   (BHFABZgl+l) etc.). Useddenim (talk) 11:32, 16 July 2018 (UTC)
@Useddenim: (Sorry, I meant to ask if it was correct to replace the h prefix with the o suffix. Which example are you referring to?) Is BHFKRZ necessary? BHFABZ (station around the junction) exists mainly because ABHF means something else (station at or inside the junction), so if T means the same thing for   (TWZOLLu) as it does for   (mTBHFu), then it shouldn't need to be replaced. Jc86035 (talk) 11:39, 16 July 2018 (UTC)

@Useddenim, Tuvalkin, and Newfraferz87: Is it possible to reconcile the suffix naming of   (hKZOLLaxe)? It's not really valid right now because of the limitations of the a/e suffixes so I'd probably rename it to something like KSTRxe+lhZOLLae or KZOLLxeo (like   (RBo)). Do you think there's something better? Jc86035 (talk) 13:16, 17 July 2018 (UTC)

Didn't you already find a scheme as in   (TKZOLLWxeo)? ;)
Though honestly I didn't find a good alternative when renaming the first icon from xdnGRENZE+BRÜCKE, but KZOLLxeo seems fine (can't think of any potential conflicts at the moment, though there might well be). The trouble comes if it gets combined with complex bridges like   then that would probably really require a combination separating line/bridge & feature.   ~ Newfitz Yo! 13:45, 17 July 2018 (UTC)
@Newfraferz87: If the conflict is resolved, it probably means renaming a few thousand icons, either by replacing the K prefix with some suffix combination, or by replacing a and e with some suffix combinations (probably something like &f/&g/&l/&r). It's doable, and I've renamed a few thousand icons to date, but it would be a bit disruptive and a lot of work just to fix naming conflicts with some icons that don't exist and   (KRZhl). Jc86035 (talk) 16:47, 17 July 2018 (UTC)

Quarter transform

@Useddenim: I have no idea what to do with   (uSTR+r@g), since the icon doesn't have an auxiliary object (unless the curve is now the auxiliary object?), but I suppose it would be appropriate to just let it be, although technically   (uSTR+r~G) implies that the line should be straight after the 90° turn. "uSTR+r~~G" would be forbidden by the Routemap syntax. "u-vvWSLeq" (from   (uvvWSLeq)) is a bit of a stretch, and it's not clear to me if [rotated 90° clockwise] "uvvv-WSLe" or "uv-(vvWSLe)" would make sense. Jc86035 (talk) 08:12, 12 November 2018 (UTC)

@Jc86035: If 3STR is a 3-column turn, then this icon could be 2STR, eliminating any conflicts with existing icons. As you noted,   (WSL) wouldn't be an appropriate root. Useddenim (talk) 12:58, 12 November 2018 (UTC)
@Useddenim: Maybe it might be better to define a new suffix type for quarter transforms (e.g. "~'[L/R/F/G/M]"), or to redefine one of the existing ones to allow for it? Jc86035 (talk) 11:57, 13 November 2018 (UTC)
What about something simple, like . as a separator? Useddenim (talk) 12:30, 13 November 2018 (UTC)
Sure. Jc86035 (talk) 13:09, 13 November 2018 (UTC)
✓ Done a few days ago. Jc86035 (talk) 16:52, 5 December 2018 (UTC)

Inconsistent naming

@Useddenim: There are only 14 icons using the . suffixes. I think it would be appropriate to better define them.

  • Group 1:   (uSTR+r.G) and the arrows – quarter icon transform, reflection assumed (as opposed to ~[L/R], which extends undefined geometry with straight lines)
  • Group 2 – (...?)
  • The SPL icons –   (SPLa.F) – could use horizontal parallel lines syntax instead, and calling it a quarter icon transform would be incorrect since the geometry changes. We don't have a suffix that's explicitly "squeeze icon contents into one half of the icon"; this suffix would ameliorate the issues we currently have with the horizontal parallel lines syntax. On the other hand, the quarter transform would also do the same thing, so this would be redundant.
  • A 1/3 icon transform could be useful for diagrams with diagonal lines. I'm not sure if reflection would be useful here.

Jc86035 (talk) 16:52, 3 January 2019 (UTC)

I don't have strong feelings either way. I had originally drawn the shifted SPL with regular geometry, but things didn't quite fit. Useddenim (talk) 17:11, 3 January 2019 (UTC)

NUL and lNUL

Now that there is an expanded set of suffixes to thoroughly describe icon geometry, I think it is finally time to rename the DiagoNULs:

f
  (NULfg)
→NULf@g		   (dNULfg)
→dNULf@g
  (NULf-)
→NULf.g
  (NULf)   (dNULf)   (vNULf)   (vNULf-)   (v-NULf)
  (-NULf)
→NULf.f		   (dNULf.f)   (vNULf.f)
  (NULff)
→NULf@f
  (NULga)		   (dNULff)
→dNULf@f		   (lvNULfa)
→lvNULf@f
g
  (NULge)
→NULg@g		   (dNULge)
→dNULg@g
  (NULg-)
→NULg.g		   (dNULg-)
→  (dNULg.g)		   (vNULg.g)
  (NULg)   (dNULg)   (vNULg)   (vNULg-)   (v-NULg)
  (-NULg)
→NULg.f		   (d-NULg)
→dNULg.f
  (NULgf)
→NULg@f
  (NULfa)		   (dNULgf)
→dNULg@f
fg / gf
  (vNULfg)
  (vNULgf)
fq
  (NULfq)   (dNULfq)   (vNULfq)   (NULfq-)   (-NULfq)
  (dvNULfq)   (dNULfq-)   (d-NULfq)
  (NULfgq)
→NULf@gq
  (NULfaq)
→NULf@fq		   (lvNULfaq)
→lvNULf@fq
gq
  (NULgq)   (dNULgq)   (vNULgq)   (NULgq-)   (-NULgq)
  (dvNULgq)   (dNULgq-)   (d-NULgq)
  (NULgeq)
→NULg@gq
  (NULgaq)
→NULg@fq
fgq / gfq
  (vNULfgq)   (vNULfgaq)
→vNULfg@fq
  (vNULgfq)
1
  (DNULfq)
→NUL1		   (vDNULfq)
→vNUL1		   (lvDNULf-q)
→lvNUL1~r
  (NULc1)
→NUL1@g		   (vNULc1)
→vNUL1@g
  (NUL+c3)
→NUL1@f		   (vNUL+c3)
→vNUL1@f
  (vDNULfgq)
→vNUL1fg		   (vNUL+c1-c1)
→vNUL1fg@g
  (vDNULgfq)
→vNUL1gf		   (vNULc1-+c1)
→vNUL1gf@g
2
  (DNULf)
→NUL2		   (vDNULf)
→vNUL2		   (lvDNULf-)
→lvNUL2~l
  (NULc2)
→NUL2@f		   (vNULc2)
→vNUL2@f
  (NUL+c4)
→NUL2@g		   (vNUL+c4)
→vNUL2@g
  (vDNULfg)
→vNUL2fg		   (vNUL+c2-c2)
→vNUL2fg@f
  (vDNULgf)
→vNUL2gf		   (vNULc2-+c2)
→vNUL2gf@f
3
  (DNULgq)
→NUL3		   (vDNULgq)
→vNUL3		   (lvDNULg-q)
→lvNUL3~r
  (NULc3)
→NUL3@f		   (vNULc3)
→vNUL3@f
  (NUL+c1)
→NUL3@g		   (vNUL+c1)
→vNUL3@g
vNUL3fg
→vNUL1fg		   (vNUL+c3-c3)
→vNUL3fg@f
vNUL3gf
→vNUL1gf		   (vNULc3-+c3)
→vNUL3gf@f
4
  (DNULg)
→NUL4		   (vDNULg)
→vNUL4
  (NULc4)
→NUL4@g		   (vNULc4)
→vNUL4@g
  (NUL+c2)
→NUL4@f		   (vNUL+c2)
→vNUL4@f
vNUL4fg
→vNUL2fg		   (vNUL+c4-c4)
→vNUL4fg@g
vNUL4gf
→vNUL2gf		   (vNULc4-+c4)
→vNUL4gf@g

I think this table shows all of the existing ones. Italicized names would be redirects. The good news is that only about half of the icons would have to be renamed. Useddenim (talk) 17:46, 13 December 2018 (UTC)

@Useddenim: Most of this sounds good, although
  • the table is missing some icons, like   (dNULg@F) (and some of them are duplicates) – petscan:6800874 should be comprehensive;
  • "@4" should be "@G" for consistency with e.g.   (tSTR2+4a@g) (I haven't used numbers for any of those suffixes, and using numbers removes the case distinction);
  • lvNUL1(L) should probably be lvNUL1~r (r and not l per   (evCONT1+3)/  (evCONT3+1));
  • ".f" should be ".F" since that's what the renamed files use (unless this one means something different); and
  • it might be preferable to use "ARR" (or "PFL") instead of "NUL".
Jc86035 (talk) 17:59, 14 December 2018 (UTC)
It's not clear if the arrows are secondary or auxiliary but dNULg@F implies I thought they would be secondary (as with CONT). On the other hand @f might be more appropriate since they can be used on stations. Jc86035 (talk) 18:01, 14 December 2018 (UTC)
I think @f/@g is the appropriate suffix, as the directional is always an adjunct to the primary feature. @Tuvalkin: Do you have any thoughts on this? Useddenim (talk) 17:11, 3 January 2019 (UTC)
@Useddenim: I've changed the @F/@G to @f/@g, as well as the @4s and the (L)s. I still think "NUL" isn't the best root to use. I've also re-ordered the suffixes of some of the proposed names. Jc86035 (talk) 17:59, 3 January 2019 (UTC)

Other icons (assuming .f and .g suffixes):

  •   (dNULg@F) – dNULg.f
  •   (dNULg@G) – duplicate of   (dNULg.g)
  •   (lNUL+c1) – lNUL3@g
  •   (lNUL+c2) – lNUL4@f
  •   (lNUL+c3) – lNUL1@f
  •   (lNUL+c4) – lNUL2@g
  •   (lNULc1) – lNUL1@g
  •   (lNULc2) – lNUL2@f
  •   (lNULc3) – lNUL3@f
  •   (lNULc4) – lNUL4@g
  •   (lNULfaq) – lNULf@fq
  •   (lNULff) – lNULf@f
  •   (lNULfg) – lNULf@g
  •   (lNULfgq) – lNULf@gq
  •   (lNULgaq) – lNULg@fq
  •   (lNULge) – lNULg@g
  •   (lNULgeq) – lNULg@gq
  •   (lNULgf) – lNULg@f
  •   (ldNULff) – ldNULf@f
  •   (ldNULfg) – ldNULf@g
  •   (ldNULge) – ldNULg@g
  •   (ldNULgf) – ldNULg@f
  •   (lv-DNULf) – lvNUL2~r
  •   (lv-DNULfq) – lvNUL1~l
  •   (lv-DNULgq) – lvNUL3~l
  •   (lvDNULf) – lvNUL2
  •   (lvDNULfg) – lvNUL2fg
  •   (lvDNULfgq) – lvNUL3fg
  •   (lvDNULfq) – lvNUL1
  •   (lvDNULg) – lvNUL4
  •   (lvDNULgf) – lvNUL2gf
  •   (lvDNULgfq) – lvNUL3gf
  •   (lvDNULgq) – lvNUL3
  •   (lvNUL+c1-c1) – lvNUL1fg@g
  •   (lvNUL+c1) – lvNUL3@g
  •   (lvNUL+c2-c2) – lvNUL2fg@f
  •   (lvNUL+c2) – lvNUL4@f
  •   (lvNUL+c3-c3) – lvNUL3fg@f
  •   (lvNUL+c3) – lvNUL1@f
  •   (lvNUL+c4-c4) – lvNUL4fg@g
  •   (lvNUL+c4) – lvNUL2@g
  •   (lvNULc1-+c1) – lvNUL1gf@g
  •   (lvNULc1) – lvNUL1@g
  •   (lvNULc2-+c2) – lvNUL2gf@f
  •   (lvNULc2) – lvNUL2@f
  •   (lvNULc3-+c3) – lvNUL3gf@f
  •   (lvNULc3) – lvNUL3@f
  •   (lvNULc4-+c4) – lvNUL4gf@g
  •   (lvNULc4) – lvNUL4@g
  •   (utlv-DNULf) – utlvNUL2~r
  •   (utlv-DNULg) – utlvNUL4~r
  •   (utlvDNULg) – utlvNUL4
  •   (utlvDNULgq-) – utlvNUL3~r
  •   (vNULfgeq) – vNULfg@gq
  •   (vNULg@G) – duplicate of   (vNULg.g)

Also, are you sure that it's best to use 1 and 2 rather than 2 and 3 for the duplicated diagonal names? Using 2 and 3 would make the naming less ambiguous due to the convention of indicating the arrow directions the "wrong" (onscreen from left to right) way; if 2 and 3 are used the track direction isn't going up the page. Also, a combination of   (STR+1~G) and   (STR2~F) would presumably be named STR2.ff due to it being shorter than STR+1.gg. Jc86035 (talk) 18:35, 3 January 2019 (UTC)

  • Nothing to say about the renaming, affix-wise, but I’d prefer a specific iconID, such as ARR or PFL. After all NUL means nothing, nil, null, as these at first were thought to be special line-less version of the old   (STRf), trivially named (just replace STR with NUL). Of course, as it does, this grew bigger than intended (which is very good), and now we can call arrows arrows, not just some ghost from another icon. (The use of the preffix l to tag black v.s white arrows is probably still a good idea, quirky as it is.) -- Tuválkin ✉ ✇ 21:49, 6 January 2019 (UTC)

GRZ

@Useddenim and Tuvalkin: The GRZ icon names still don't really make much sense. Proposal:

  • All icons with a white background behind the dashed line are renamed to use MGRZ from either GRZ or lGRZ.
  • All icons without such a white background are renamed to use GRZ from lGRZ (if necessary).
  • No other changes.

Jc86035 (talk) 17:13, 8 January 2019 (UTC)

  • I agree that the two sets need to be clearly separated — the M preffix seems to be a good way to do it. This renaming should affect also the ex versions of each icon, in which white, when present, changes to a light gray: A former border is therefore dimmer, not just lighter (as it could not be lighter than RGB:FFF, nor darker than RGB:000). As for the sense these make, well, when we think that at first these were thought to form a pair in which the regular version was a red-edged white disc bearing a black bar and the former version was a black and white dashed line, and that this state of affairs was fought for when challenged with much wrath and menace — we see we come a long, long way. (Funny enough, I got Jc86035’s ping exactly when I was going to pick some exGRZ icons needed for pt:Linha de Sintra…) -- Tuválkin ✉ ✇ 17:32, 8 January 2019 (UTC)

Parallel curves, again

@Useddenim and Tuvalkin: Would it be appropriate to rename   (vSTRrg-) and similar to vSTRr~r, based on   (vSTR3~r)? The g/f suffixes would have to stay because of   (vSTR+rg-) and similar (though those could be renamed to vSTR+r~r~G), as well as assorted junction icons like   (vABZgnrg+xnrf-STR) and   (vABZg+lgo-ABZg+lf). Jc86035 (talk) 13:32, 6 January 2019 (UTC)

  • Sorry, I need to learn what the tilde ~ means, first. I kinda lost the train of some of the new naming conventions. (I was going to say that «the logic of   (vSTRrg-), of course, as it is the right side of   (vSTRrg), with   (v-STRrg) being its matching leftside pair» but then edit preview showed that neither of these two look as I thought they do.) -- Tuválkin ✉ ✇ 21:20, 6 January 2019 (UTC)
@Tuvalkin: The suffix modifiers are summarized (to the best of my understanding) at BSicon/Catalogue#Suffix modifiers. But trying to keep up with Jc86035's suffix-compounding is like trynig to catch a moving target! Useddenim (talk) 22:03, 6 January 2019 (UTC)
This came about because I was uploading   (vvSTRr~l),   (vvSTR+l~r~r~LG), and other assorted 500px-radius-curve icons. As far as I'm aware ~L/~R is defined as "half" of the icon, so here it would mean all of the lines to the right of the middle, plus the middle line (if any). Jc86035 (talk) 08:49, 7 January 2019 (UTC)

@Useddenim and Tuvalkin: Similarly,   (utvABZ+lg-) and   (utvABZlf-) are each missing one letter. Should they be renamed like utvABZg+lg- or utvABZg+l~r? Jc86035 (talk) 15:54, 15 January 2019 (UTC)

utvABZg+lg- seems more intuitive to me. Useddenim (talk) 16:55, 15 January 2019 (UTC)

Disconnected parallel stations

@Useddenim and Tuvalkin:   (evDST-BHF) and   (veDST-eBHF) are duplicates; there are probably a few more in the category. Would the latter icon's title be more appropriate (I think it would be)? Jc86035 (talk) 03:31, 16 January 2019 (UTC)

Yes. When there are different features on parallel lines icons they should be parsed individually to avoid any amibguity. Useddenim (talk) 04:46, 16 January 2019 (UTC)
I think I've fixed all of them (only one duplicate, though). Jc86035 (talk) 09:50, 28 January 2019 (UTC)

uexhSKRZ-GDoa & uexhSKRZ-GDoe

¿Why do   (uexhSKRZ-GDoa) and   (uexhSKRZ-GDoe) have the -o suffix if neither   (uexhSKRZ-GD),   (uhSKRZ-GDa) or   (uhSKRZ-GDe) have it? ¿Shouldn't they be renamed to   (uexhSKRZ-GDa) and   (uexhSKRZ-GDe)? --Snooze123 (talk) 21:37, 27 January 2019 (UTC)

@Snooze123: It looks like I missed them when renaming the road icons in 2017. Fixed. Jc86035 (talk) 09:41, 28 January 2019 (UTC)

File:BSicon_gKRZ+4ov-STR3.svg

Although semantically correct, it's not the greatest name for this:   (gKRZ+4ov-STR3). Any suggestions Jc86035, Tuvalkin? Useddenim (talk) 01:18, 28 January 2019 (UTC)

@Useddenim: I think   (gSTR+4o+gv-STR3) or   (gv-STR3+gSTR+4o) (like   (vSHI1lo-uexSTRr)) would be clearer. I don't know how the order should be determined. Jc86035 (talk) 09:45, 28 January 2019 (UTC)
  (gSTR+4o+gv-STR3), so that it's clear that only one line is on the parallel alignment. Useddenim (talk) 12:53, 28 January 2019 (UTC)

SHI2

@Useddenim, Tuvalkin, and Epicgenius: I've renamed all of the BS2 icons outside the two standard sets to SHI2. I previously renamed the elevated icons to SHI2 in August 2017. The last discussion on the topic was in December 2017.

  • Is it time to rename the remaining 204 BS2 icons?
  • Should the 862 KRW icons be renamed to SHI4 as well?

Jc86035 (talk) 10:31, 28 January 2019 (UTC)

@Jc86035: I think the BS2 and KRW icons should be renamed as well for consistency. In both cases, there is a mix of both prefixes. epicgenius (talk) 16:03, 28 January 2019 (UTC)
Agree. Useddenim (talk) 03:28, 11 April 2019 (UTC)

What's up with the tildes?

I came across some inconsistencies in YLSS's list; for example,   (uexlBHF~F) but the side says "lBHFf". So can someone please explain to me why this is the case for the moved icons? -- Ben79487 00:25, 10 April 2019 (UTC)

@Ben79487: It's likely because of a left-over redirect from a previous move. Useddenim (talk) 17:39, 10 April 2019 (UTC)
@Ben79487 and Useddenim: As noted on Tuvalkin's talk page, this was part of the 2018 suffix standardization changes. YLSS stopped editing about four years ago, so some of his catalogues are now out of date because he hasn't been around to update them. Jc86035 (talk) 14:39, 14 April 2019 (UTC)
@Jc86035: Thanks for the info! – Ben79487 22:35, 14 April 2019 (UTC)

Naming guidelines

I’m totally lost, it seems: Not only I cannot be sure how to name a very simple icon I need to create ( ) but I can’t even find the page with filenaming guidelines. :-\ -- Tuválkin ✉ ✇ 15:16, 23 April 2019 (UTC)

@Tuvalkin: I'm not totally sure about that one either. I think uhvKRZW~L could be correct (per Talk:BSicon/Renaming/Archive 12#WSTR); the water would probably be expected to line up normally, per   (uhvKRZt~L) (the dashes aren't transformed along with the viaduct), although I thought that could be an issue. Jc86035 (talk) 15:22, 23 April 2019 (UTC)
  • I thought of uhvKRZW~L, too, or maybe uhvWKRZ~L — but when I tried to check it with the main page with all the naming guidelines, I searched everywhere I couldn’t find it. Where is it? -- Tuválkin ✉ ✇ 16:55, 23 April 2019 (UTC)
@Tuvalkin: I think the only thing that isn't mentioned is that W can now be used as a suffix. The other parts could largely be constructed from the available information. Jc86035 (talk) 04:56, 24 April 2019 (UTC)
Legend
 vSTR
c\hcdvSTR~L
hcdvSTR~R\c
uhvKRZt~L
There should be a v- (not a plain v) in the name because there is only a single line. Useddenim (talk) 15:47, 24 April 2019 (UTC)
@Useddenim: I don't think that would be necessary. Because of the transform the track centre is at x=500, and implying that there are two tracks (at x=375 and x=625) obviates the need to explicitly remove a formation at x=500; the two formations are supposed to be at x=250 and x=750. The name with the transform is also shorter than uhv-KRZW(Rr).
See also   (hcdvSTR~L) /   (hcdvSTR~R); I uploaded these last June and I don't think they would have been possible without the ~L/~R suffixes. Jc86035 (talk) 15:57, 24 April 2019 (UTC)
Hmmm, the cdvs don't line up with anything, and uhvKRZt~L is definitely a single parallel line. Useddenim (talk) 20:35, 24 April 2019 (UTC)
@Useddenim: They do actually line up; the lines are at x=125 and x=250. (The transformation is for half the width or height of the icon, and this sort of situation is why I chose to propose it this way instead of using a fixed one.) Jc86035 (talk) 03:38, 25 April 2019 (UTC)
  • Ah, yes, that’s what I was looking for! Thanks so much, @Jc86035: Indeed not the place we’d think about, and I browsed links to the catalog mentally going «Not here, not here, … — where the hell is it?» -- Tuválkin ✉ ✇ 13:26, 27 April 2019 (UTC)

Parallel, across, mixed

Is   (vSTRq saffron+teal) supposed to be named mvSTRq teal+saffron or mvSTRq saffron+teal? If we were to take mvSTR teal+saffron and rotate it 90° anticlockwise we would get this icon, so we would be using the former name. However, if we were to follow the top-to-bottom naming logic of the horizontal parallel lines syntax, we would use the latter name.

I don't remember if there are any correctly-named icons which are like this, but I don't think there are any. Per Talk:BSicon/Renaming/Archive 9#Parallel lines, the consensus is to ignore that the parallel mixed icons don't use the same naming logic as other icons (e.g.   (emvSTR) vs.   (emKRZ)), so it's not clear to me which one it should be. Jc86035 (talk) 04:00, 25 April 2019 (UTC)

Choose one and create a redirect from the other. It won't matter unless someone needs the inverse. Useddenim (talk) 20:44, 27 April 2019 (UTC)
There is actually   (fmvKSTRaq +yellow), which I renamed last July based on the first approach. I guess that settles it. Jc86035 (talk) 10:48, 2 May 2019 (UTC)

A better name for this

I needed this one and searched a long time for it, and then a long time for its name:   (SHI1r+SHI1c4). Any better ideas? -- Tuválkin ✉ ✇ 20:25, 3 May 2019 (UTC)

@Tuvalkin: I think SHI1r+c4 would be better (other options include vvSHI1r-SHI1r- and vSHI1+l~R). However, this search indicates that there's only one icon named this way,   (SHI2gl+c4) (uploaded by Vunz), and it uses a regular corner instead of a two-quarter shift corner. In Talk:BSicon/Renaming/Archive 11#BS2 there was rough consensus to e.g. use SHI2rxl+c2 for   (BS2rxl), so I think it would also be appropriate to rename   (SHI2gl+c4) to SHI2gl+STRc4. Jc86035 (talk) 12:16, 4 May 2019 (UTC)
✓ Done. Jc86035 (talk) 11:02, 15 May 2019 (UTC)

Parallel crossover junctions

@Useddenim and Tuvalkin: I'm not sure what   (vÜWBl+rxl) should be named (I've already tried to rename it). There are four tracks, but only three l/r suffixes, so it's not possible to just use the x suffix for the 16 possible combinations. Using the e/x suffixes (like   (evÜWBl) or   (evÜWBr)) would necessitate the renaming of the eight or so exvÜWB...+... icons to exvÜWB...+x... (like   (exvÜSTx), so e.g.   (exvÜWBl+r) would become exvÜWBl+xr). Is there another option that I'm missing? Jc86035 (talk) 14:52, 29 July 2019 (UTC)

e
x
vSTR+
e
x
ÜWB…. Problem solved. Useddenim (talk) 15:04, 29 July 2019 (UTC)
@Useddenim: I think I would prefer adding the x suffix to that, given that it wouldn't literally be correct (  ≠  ) and would unnecessarily lengthen the icon names. Jc86035 (talk) 15:08, 29 July 2019 (UTC)
vPSL+ÜWB? Useddenim (talk) 15:14, 29 July 2019 (UTC)
@Useddenim: I don't think PSL would work either, since the secondary track is supposed to be thinner.
Would you mind the +xlr option? I think it could be better to just do that. Jc86035 (talk) 15:19, 29 July 2019 (UTC)
I guess that would work. Maybe you should create an old name/new name table to be clear? Useddenim (talk) 15:47, 29 July 2019 (UTC)
@Useddenim: It's just these five. I didn't realize that there were only two of these in set u. Jc86035 (talk) 15:58, 29 July 2019 (UTC)
Current Proposed
  (exvÜWBl+l) exvÜWBl+xl
  (exvÜWBl+r) exvÜWBl+xr
  (exvÜWBr+l) exvÜWBr+xl
  (exvÜWBr+r) exvÜWBr+xr
  (vÜWBxl+lr) evÜWBl+lr

✓ Done Jc86035 (talk) 12:08, 30 July 2019 (UTC)

Parallel lines (legacy naming syntax)

@Useddenim and Tuvalkin: Should the   (vSTRegl) and   (vSTRgl) groups of icons be renamed? The latter would be trivial to rename, but the former would either necessitate a (trivial) extension to the SPL syntax (essentially, replacing "vSTR" with "SPL" and not doing anything else) or necessitate an extension to the SHI1 syntax to allow for combining 90° junctions. Jc86035 (talk) 16:58, 8 August 2019 (UTC)

Yes (to SPL) and yes (to STR-STR). Useddenim (talk) 20:08, 8 August 2019 (UTC)

Prefix order

Which is correct: BSicon_dlICON.svg or BSicon_ldICON.svg? AlgaeGraphix (talk) 00:20, 9 January 2020 (UTC)

@AlgaeGraphix: ld is correct. I think the prefixes (aside from the "root modifiers") should all be listed in order at BSicon/Catalogue, but it's possible that there are some issues left to be resolved. (SW and S are probably the biggest remaining issues, the former because it's unnecessarily two characters long and the latter because it has two conflicting uses.) Jc86035 (talk) 12:32, 26 January 2020 (UTC)

Recent page moves

@Jc86035: You just moved   (lvINT2+4-L) and   (lvINT2+4-R) (which I had named based on   (lvINT-L) and   (lvINT-R). However, you changed them to   (lvINT2+4-1) and   (lvINT2+4-3), but following that logic, shouldn't they simply be   (lvINT-1) and   (lvINT-3) similar to   (lINT-1) and   (lINT-3)? (The shorter versions at the near corner would then logically be named   (lv-INT-1) and   (lv-INT-3).) AlgaeGraphix (talk) 12:59, 26 January 2020 (UTC)

@AlgaeGraphix: lvINT-1 would be   (lvINT) which happens to connect to that corner, so it would either be a straight line from (150,250) to (0,500) or another shape with those end points. We don't actually have any station icons with curves in the station shape, but it's possible that we might need them eventually. Jc86035 (talk) 13:05, 26 January 2020 (UTC)
That being said, I don't think this is actually defined, but regardless, I would probably avoid having the station shape be transformed without consideration of the lines, since for non-legende icons it would become possible for the station to not intersect the lines. Hypothetically, BHFr-13 (or even BHFr-LF) would be extreme examples of this issue. Jc86035 (talk) 13:13, 26 January 2020 (UTC)
I think anything as convoluted as those examples would be better illustrated with a HUB. AlgaeGraphix (talk) 16:45, 26 January 2020 (UTC)

Suffix modifiers

@Tuvalkin and AlgaeGraphix: The . suffix was introduced about a year ago; see Talk:BSicon/Renaming/Archive 12#Quarter transform and the next two sections. Reviewing its usage, it's still only used for two things.

  • As before,   (uSTR+r.G) uses it to indicate a quarter transform with the curve geometry preserved beyond the original icon edge.
  • As before,   (SPLa.F) uses it to indicate a squash.

I think it would make sense to change the suffix modifiers as follows:

  • Allow ~L etc. to include an integer, to indicate the degree to which the icon is transformed (e.g. ~3L would be a transform of one third of the icon width, ~4L one quarter, and so on).
  • Redefine .L etc. as the same as ~L etc. but with geometry preserved beyond the icon edge in all directions (i.e.   (dSTR2+1) instead of   (dSTR2)). ..L indicates that the geometry of the now-in-frame portion of the icon is reversed (specifically, reflected along the line between the centre of the new icon and the point on the new icon representing the direction of the transformation, i.e.   (dSTR2+4) instead of   (dSTR2)).
  • Define .l etc. as a squash of an icon to half of the icon width or height in the specified direction, or to a quarter of the dimension for .4l or to two-thirds of the dimension for .2/3l.

Does this seem like a good idea? If it doesn't work out it's always reversible. Jc86035 (talk) 15:36, 26 January 2020 (UTC)

As an example, see   (vSTR1~r) and   (vSTR1~r~6F). I don't think it would otherwise have been possible to name the latter icon with the currently available constructs. Jc86035 (talk) 12:28, 1 February 2020 (UTC)

Fractional shifts

Legend
 ½/4
18/4

Lantus moved the SHI½ icons with the rationale "unpractical name". Although fractional characters might not be directly typeable from the keyboard, neither are many of the diacritical marks, yet those are acceptable in file names. SHI18 is not the correct name for these icons, as the diagram shows the dramatic difference between a ½/4 and a 18/4 shift. I am open to renaming suggestions before proceeding with the reversion step of en:WP:BRD. (Pinging Jc86035, Tuvalkin.) AlgaeGraphix (talk) 21:12, 19 June 2020 (UTC)

  • I absolutely agree! Whoever has a problem with typing ½ or ¼ should come up with a suitable alternative and create a set of redirects using that replacement. Moving an existing icon to a new name without any discussion is unacceptable. -- Tuválkin ✉ ✇ 09:11, 20 June 2020 (UTC)

Junctions with two parallel lines

@AlgaeGraphix, Tuvalkin, and WT79 The Engineer:

  •   (uvABZql-) → uvABZqr~l~L?
  •   (uv-ABZqr) → uvABZqr~r?
  •   (uvABZqr-) → uvABZqr~l?

I'm not sure about these. If we were to take the example of   (kABZq1) then the ~l/~r would be correct since the line direction would be from r, but the icon names imply to a degree that the line direction is towards r. Jc86035 (talk) 06:37, 9 June 2020 (UTC)

I have no objection – I wasn't quite sure what to call them either, when I uploaded them, so sorry if I chose the wrong one. WT79 The Engineer (talk) 17:00, 9 June 2020 (UTC)
@WT79 The Engineer: I don't blame you; there isn't currently a defined way to name those three icons. Jc86035 (talk) 17:58, 9 June 2020 (UTC)
@Jc86035: so we're not using f/g to indicate that a single parallel line curve is being moved forward/back? AlgaeGraphix (talk) 17:08, 9 June 2020 (UTC)
@AlgaeGraphix: Currently we do use those suffixes for basically all double-parallel 90° curves. I did suggest changing this so that the icons would use ~l/~r suffixes instead last year and again last month, but nothing has come of it yet. I still think it should be done (and I explained my reasoning in both prior discussions), but it would be necessary to take a more comprehensive look at what this change would affect and outline what specifically would have to be done for all the relevant icons that currently exist.
Aside from the fact that that usage doesn't fit with the f/g suffixes' uses in other icon names (  (STRf) and so on), the other reason that I didn't suggest using them here is that those suffixes wouldn't be well-defined in this case because they've never been used in that way in conjunction with q, so the meaning and correct suffix order would have to be decided. Furthermore, using l and r instead would obviously cause naming conflicts.
For context: I think the first time that something like the ~l/~r suffixes was used was when YLSS renamed   (vSTR2~l) etc. to use the -L/-R suffixes in December 2014, and his renaming of the   (v-STRlg) group of icons in January 2014 actually predates that. The ~l/~r suffixes didn't exist until 2018, and until 2017   (STR+l) was still STRrg. Renaming icons that use the f/g suffixes to indicate parallel lines in this way would be one of the last steps in standardizing the basic suffixes. Jc86035 (talk) 17:58, 9 June 2020 (UTC)
  • @Jc86035: Since I was pinged, here’s my answer — a bit out-of-the box and not something I didn’t say many times before: When we have an icon such as   (uv-ABZglf) we should have no problem in deriving the name of  , which I defend should be always uv-ABZglfq. In general any yesyesyesyes (FOO)  when rotated a quarter turn anticlockwise becomes yesyesyesyes (FOOq) . That doesn’t solve the matter for the other two icons, but it simplifies the underlying issue in a much wider way. -- Tuválkin ✉ ✇ 00:10, 3 July 2020 (UTC)

Surely there’s a better name for this?

I recently created   (SHI1c3+SHI1+r ochre) because I needed it and could not find it, not even in standard colors. The topology is obvious and the geometry (I hope) is trivial. This is akin to other SHI1 parallel icons, and should have a simpler name, I think. -- Tuválkin ✉ ✇ 20:12, 2 July 2020 (UTC)

@Tuvalkin: This is a pretty interesting case; I think vSHI1l~R ochre would be the simplest possible name. I don't think you could get something shorter than that. Jc86035 (talk) 10:40, 3 July 2020 (UTC)
Since   (STR+c3) is a contraction of  (STR※ STRc3) , then why not   (SHI1c3+SHI1+r ochre) → SHI1+r+c3 ochre? AlgaeGraphix (talk) 13:59, 3 July 2020 (UTC)
@AlgaeGraphix: I think it sounds reasonable. I would probably still prefer vSHI1l~R ochre, but for 50% of the icons your proposed naming would have a shorter title. Jc86035 (talk) 14:32, 3 July 2020 (UTC)

A tale of three grey icons and their naming (and their categorization)

(@Jc86035, Useddenim, AlgaeGraphix, and YLSS: This affects also categorization, but I think the main issue is the name of these icons:) Yesterday I created these three, because I needed them:    . So far so good, but here’s the thing:

  • To create   (cBS2c3 grey), I trivially recolored   (uexdBS2c3), created by YLSS in 2014.
  • Then I needed its matching symmetrical pair and I sought for recoloring the trivially named cBS2c2 (just replace 3 with 2, right?), to find it had been created by me in 2013, based on Axpde’s   (BS2c2), and renamed (without redirect) in 2017 as   (cSHI2c2) — which I then used to create   (cSHI2c2 grey), thus named.

I’m not a zealot for redirects, but in this case, since we’re stuck with some BS2s thanks to the Bilderkatalog then lets’s keep redirects including them even for icons outside it — for the pairing I end up with is symmetrical in topology and geometry but not in name:   (cSHI2c2 grey)  (cBS2c3 grey).

Furthermore, this discrepancy between BS2 and SHI1 (already under discussion elsewhere) causes {{BSicon file description}} to categorize the icons in question very differently:

  •   (cSHI2c2 grey): BSicon/railway/set grey/quarter-width/shift/two quarters/corner
  •   (cBS2c3 grey):  BSicon/railway/set grey/quarter-width/uw/curve+corner
Redirect or no redirect, these namings are equivalent and the categorizations should be identical. Bug in the template, in the module, or is it just simpler to rename everything in a coherent fashion and keep the odball names as redirects?
  • Finally,   (STR2h3h grey), also a matter of {{BSicon file description}} misinterpreting the 3 and the h in the filename to categorize this under BSicon/railway/set grey/elevated/3/curve.

-- Tuválkin ✉ ✇ 14:58, 25 July 2020 (UTC)

I thought it had been decided the BS2 was only going to be kept for the full-width regular and u sets (and full- and half-width corners), with everything else renamed to SHI2. AlgaeGraphix (talk) 15:11, 25 July 2020 (UTC)
  • (@AlgaeGraphix: apologies for splitting your post to intersperse my reply.) I wasn’t aware (or I forgot). It doesn’t seem like a stable solution, though: I should know that, sure, but any newcomer would do the same as I did: See a red icon they need in gray, copy the SVG code, edit to recolor, upload with the apparently correct name. All these BS names (heh) need to become redirects to avoid this problem. -- Tuválkin ✉ ✇ 17:22, 25 July 2020 (UTC)
I don't think the naming is a particularly big issue; just use SHI2 instead of BS2 for any new icons. I've been putting off mass-renaming all of the BS2 icons for quite a while, but it will probably happen eventually. (The KRW situation is a bit more complicated since it's now being used for slanted diagonals, but I'll probably rename most of the SHI4-compatible ones at the same time as the BS2 icons.) Jc86035 (talk) 15:27, 25 July 2020 (UTC)
I have no idea how {{BSicon file description}} is supposed to work. AlgaeGraphix (talk) 15:11, 25 July 2020 (UTC)
@Tuvalkin and AlgaeGraphix: The categorization in Module:BSicon is not intended to be canonical; I just did it to make uploading a faster process. It's not actually coded particularly well and probably should be improved at some point. It does occasionally output obviously incorrect results, especially for suffixes which I didn't write any code to handle (such as the h suffix as used here). Jc86035 (talk) 15:27, 25 July 2020 (UTC)

Could not find a better name for this bay/gulf/dock icon

Moved to Talk:BSicon/Renaming/Roads#Could not find a better name for this bay/gulf/dock icon
00:15, 30 August 2020 (UTC)

Weir and lock

I was looking through the catalogue of watercourse BSicons, and noticed an anomaly in the naming of lock/weir combinations. I suggest File:BSicon uLockWeir.svg → File:BSicon uxLockWeir.svg. This would make it consistent with the naming for File:BSicon uWeirLock.svg, although there does look to be a need for design consistency in this small set as well. VanIsaac (en.wiki) 08:43, 19 August 2020 (UTC)

@Vanisaac: Most—if not all—of the canal features should be renamed consistently. See Talk:BSicon/Renaming/Canals#Locks. AlgaeGraphix (talk) 14:17, 21 August 2020 (UTC)

Naming conundrum

Moved from Talk:BSicon/Icon geometry and SVG code neatness
v-STR+l v-STR+r
  (v-STR+l)│  (v-STR+r)ヽ( `д´*)ノ
v-STR v-STR
  (v-STR)│  (v-STR)

Hi, recently I've been looking for transformed curve icons for connecting two parallel, shifted, straight lines. However, I didn't found any circular arches:

I was able to create the icons I need, but I'm not certain how to name them. Do you have any ideas? KokoiMatsuch (talk) 14:16, 22 August 2020‎ (UTC)

@KokoiMatsuch: I took a look at your uploads, and although there are many   (BST) and   (DST) icons, I don't see the parallel curve ones you refer to. AlgaeGraphix (talk) 23:11, 22 August 2020 (UTC)
STR+l.L STR+r.L
  (ARCH1)│  (ARCH1')(´ ∀ ` *)
v-STR v-STR
  (v-STR)│  (v-STR)
@AlgaeGraphix: I haven't uploaded them yet, but I'll do it in a minute KokoiMatsuchi (talk) 08:50, 23 August 2020 (UTC)
@AlgaeGraphix: There you go (I've just uploaded two, I'd prefer submitting the rest after having known the rule of naming them). Temporarily I named them ARCH1 and ARCH1'. 09:01, 23 August 2020 (UTC)
c STR+l
c│  (STR+l)│cd│O3=  (STR+r)
v-STR v-STR
  (v-STR)│  (v-STR)
1. The   (ARCH) icon already exists.
2. The same result can be achieved with spacers and overlays; see →
3. The . symbol transforms an icon 1/4 shift in a direction:   (uSTR+r) →   (uSTR+r.G), so your icons are actually   (STR+l.L) and   (STR+r.L). AlgaeGraphix (talk) 15:35, 23 August 2020 (UTC)
Thank you for resolving this problem. I'll use the "comma" then. (I'm still wondering, why nobody at Polish wikipedia haven't updated the template to use c, d icons) KokoiMatsuchi (talk) 16:02, 23 August 2020 (UTC)
KokoiMatsuchi Note: the symbol is a period (full-stop/decimal point), not a comma. AlgaeGraphix (talk) 17:11, 23 August 2020 (UTC)

Four curved road transitions should be renamed

Moved to Talk:BSicon/Renaming/Roads#Four curved road transitions should be renamed
23:41, 31 July 2022 (UTC)

striped fill rename

please rename File:BSicon FILL ddbbff*cccccc.svg to File:BSicon FILL ddbbff+cccccc.svg to conform with other striped fill tile naming conventions. -Mjdestroyerofworlds (talk) 05:53, 11 July 2021 (UTC)

✓ Done. AlgaeGraphix (talk) 13:18, 12 July 2021 (UTC)

Rename tkLLSTR2 to utkLLSTR2

Uploaded the file with the wrong name. Please help to rename   (tkLLSTR2) to   (utkLLSTR2)  - oahiyeel talk 13:23, 15 July 2021 (UTC)

@Oahiyeel: ✓ Done. AlgaeGraphix (talk) 21:45, 15 July 2021 (UTC)

de

@Cmuelle8: What does de mean in   (fmKRZ+BUE-de) (and possibly others)? -- Tuválkin ✉ ✇ 15:16, 24 June 2021 (UTC)

  • Not unrelated, everybody take heed: This user seems to really be doing a lot of changing and very luttle discussion to match.
The discussion is at Talk:BSicon/Renaming/BUE. --91.55.164.1 12:50, 16 July 2021 (UTC)
Also take heed for fully unchanged BSicon/Catalogue/straight 2 that still uses BRÜCKE root, without any transition from BSicon's beginning to BRUECKE or SKRZ / WKRZ forms. Note that a lot of other old names should not be used in new articles anymore and exist for compatibility reasons only. --91.55.164.1 12:50, 16 July 2021 (UTC)

File moves

Moved from User talk:Davey2010#BSicon file moves:

@AlgaeGraphix You're trying to simplify things by putting a discussion you have not joined into a bad light. Tuvalkin has lost interest on the discussion and his original proposal to discuss was not very well worded on his side either. That said, I'm not in conflict with him. For the most part work on BSicons can be done frictionless side-by-side, that's what the naming convention is for. People that want to be productive do not want to waste their time in lengthy discussion with zero return. Work on BSicons is not to be rejected or approved by nose but rather if the nomenclature and basic standards of the design that's documented are met.

Your request/instruction to Davey2010 to decline renaming requests based on the person or nose submitting the request hinders this productive work-flow and does not get the community around BSicons anywhere. Shared is a common rule set BSicon editors work with - this rule set isn't perfect. Those (overseeable) renaming requests exist, because from time to time synthesized names translate to more than one icon graphic resolving that synthesized name, or vice-versa.

Examples of this are easily found with root KRZ and the variations synthesizable with the q, o and u suffix modifiers. Other names far from perfect are exhibited in e. g. Category:BSicon/railway/water/set u/elevated/tunnel/portal/crossing - it would not be "my interpretation" if these names were used for icons with the tunnel-dashes reversed, but perfectly valid solutions to the synthesized names that have been title-mapped and posted to the category at will - cp.   (uthKRZW).

Since it's not always obvious which title mappings pose problems at the time an icon is uploaded, some house keeping has to be done from time to time to not get stuck. This is trailing work, i.e. look at accumulated data, identify conflicts, resolve conflicts to allow for further additions. This is work that has been done before, by others with other problems, maybe other discussions. And this is what you've been done e.g. with   (WTUNNEL) and   (KRZWu), among others.

It is plain to see that when the rule set or naming convention started out back before 2006 that there simply wasn't enough data to decide if it was designed well enough to accomodate for all the icons that live on commons now. There were numerous attempts to extend and patch shortcomings, some documented on the front page to this date, without diving into the version history - e. g. the early addition of +l mnemonic. How can you claim an expertise of ~260.000 icons named consistently, which is and has been a community effort and diminish the work of others as singular interpretation? Have you given any evidence as to why the renaming requests you disliked were malformed? All I've read here is denying problems people sooner or later will have on a larger scale and animating people to stay put. This has proven to be the wrong way, re-read Talk:BSicon(Where? Be specific. AlgaeGraphix (talk) 15:34, 16 July 2021 (UTC)) archives, pay emphasis in particular to phrases like

we've seen this nomenclature break in the past

By depending on reputation rather than reason this will simply repeat. --Cmuelle8 (talk) 22:02, 15 July 2021 (UTC)

You may have made a valid point somewhere in this discussion, but frankly I don't have the patience to read through your lengthy, pedantic and sophistic arguments. Maybe Germans are different, but most people don't want to deal with someone who keeps saying "You're wrong because…". I sincerely hope that your feet don't get sore from that pin you're dancing on. Also, what qualifies you as an instant expert on BSicons after just over a month of working with them on Commons?
Furthermore, please include edit summaries, as your lack of them is both confusing to others who are trying to figure out what you are doing, and also just plain rude. (See meta:Help:Edit summary for more information.)
Tuvalkin, anything to add? AlgaeGraphix (talk) 15:34, 16 July 2021 (UTC)
I've been working on BSicons for years. I never claimed to be an instant expert and at no point in any discussion I've told you you're wrong because. If you don't want to work through Talk:BSicon/Renaming/BUE thats fine, but then don't simply frame it irrelevant. It does not need your instant attention. In time people can reference and comment it, if they encounter it in their work.
I don't consider myself a German. Do you want to be reduced to your nationality? Impatience paired with insults is exactly the reason why I wasn't very eager to start all of this and not in that depth in the first place, although requested. Like anyone I'm not flawless and Mediawiki does not expect anyone to be. It is and has been a common space to collaborate, share ideas and projects and it has resisted bad vibes for quite some time now. We're working on and in the same boat here, but language often does not reflect that. Your last sentence is constructive, can you pinpoint me to the Edit summary you seek clarification to?
The main principle to keep BSicons open and extensible for others is subdivision of problem fields. Just because some potential problems have not surfaced yet, doesn't mean its stupendous to research and explore them, even if that doesn't draw major interest. A dead project where everyone involved fears the porcelain doesn't break when making a move has never been among operating goals of commons. We all have limited resources and the growing amount of uploaded icons has not resulted in a maturing documentation accompanying this circumstance. This is one source of conflict, imho. Vague documentation is inviting to start a project, but its a burden to maintain nowadays without sorcery and tons of experience in the heads of few.
There is BSicon/Icon geometry and SVG code neatness and style guide and BSicon/Guide, partly outdated it seems, on how to technically upload and edit the files. The guide claims Inkscape is tolerated, but in practice SVGs are hand-edited, which is often hard-wired if one is to stick to the legende prototypes or derive new icons from existing ones. BSicon/Catalogue front page is ok as a quick reference, but it doesn't dive into detail and examples are used sparingly.
I've read people stating that BSicons are so convoluted - presumably they're not simply referring to STR. A practical guide on title mapping does not exist, maybe because its too boring to write one.. It'd be extremly handy to have a page with 5 to 10 example icons from categories of the default set that describes in detail their specific title mapping. The style guide maps svg code to rendering - a similar thing for the title codes is missing afaict.
This discussion has drifted off easily and far from anything specific that this talk prefix is supposed to host. In particular the move from Davey2010 talk page to BUE was OT. --Cmuelle8 (talk) 22:37, 16 July 2021 (UTC)
The first instance I see of you working on BSicons is an upload at 22:51, 12 June 2021, not even five weeks ago.
As Tuvalkin pointed out, the appropriate place to discuss file (re)naming is here, on the main talk page; not wait for people to "encounter it in their work".
There's nothing on your user page that gives any sort of indication, the preponderance of your editing is on de:wp, and your edits on en:wp are on German topics, so that seemed to be a reasonable assumption.
My nationality is a significant part of my identity. I'm sorry if you don't have any national pride.
The majority of your contributions only have an auto-generated summary, if anything at all. Four of your last ten edits have no summary, the other six are system generated; only one of the last 25 has any input from you.
Taking a quick look at some of the icons that you have created almost makes me think that you are deliberately creating esoteric "edge case" icons that would in practice be used so infrequently that the project would be better off simply using overlays. (The fact that de:wp doesn't support layering is a different issue.)
I think I do my part in trying to keep documentation up to date.
Uploading files is a core part of Commons; it should not be necessary for the BSicon project to have to explain how that is done. Yes, you are correct in saying Inkscape is tolerated, mainly as an avenue to let neophyte editors to create icons. However, it creates bloated code, and SVG is not hard to learn. The BSicon/Catalogue was written using the KISS principle; what exactly do you think needs to be added?
I'm unclear as to what you mean by mapping—obviously a translation issue.
Davey2010 clearly did not want any further discussion on his talk page; this is the correct spot for it to receive maximum visibility.
AlgaeGraphix (talk) 00:28, 17 July 2021 (UTC)
Cumelle, Algae was very kind in moving your post because if it were me I would've simply deleted it. I don't quite understand what you felt you would achieve by starting an arguement with someone on my talkpage - I very clearly stated here I wasn't going to move these so Algae coming to my talkpage earlier in the day had not made any difference or "influenced me" so to speak. (Again as explained on my talkpage my laptop simply hates renaming these and ironically now I think of it so did my previous laptop)
Algae was correct in moving your post and as I said they were very kind to do so.
Maybe Cumelle instead of trying to pick a battle maybe it'd be a better to work with them and come to an amicable solution to whatever issue you have. –Davey2010Talk 01:39, 17 July 2021 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Talk:BSicon/Renaming/Archive_12&oldid=708093799"