Talk:BSicon/Renaming/Archive 12

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

45° junctions

@Useddenim, Tuvalkin, Epicgenius, 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)

  • I fully Symbol keep vote.svg agree, both with the proposed renamings and with the underlying argument. -- Tuválkin 13:53, 29 April 2018 (UTC)
  • I also Symbol keep vote.svg agree. Are we changing the names for   (ABZq+4) and   (ABZq2)? I should think not - if the rotation is 90 degrees counterclockwise, then the "front" of the   (STRq) is on the left - but I want to know anyway. epicgenius (talk) 14:16, 29 April 2018 (UTC)
    @Epicgenius: No; those would be unchanged under the proposed logic. Jc86035 (talk) 14:20, 29 April 2018 (UTC)
    @Jc86035: Thanks. epicgenius (talk) 14:21, 29 April 2018 (UTC)
  • Symbol keep vote.svg agreed Vunz (talk) 13:20, 30 April 2018 (UTC)
  • Symbol keep vote.svg Mild agree. However, just make sure there isn't a repeat of the CONTl/CONTr debacle. Useddenim (talk) 23:33, 29 April 2018 (UTC)
  • Symbol delete vote.svg 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 BSicon .svgBSicon STR3+r.svgBSicon ABZ3+1l.svg . 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, 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)

  • Looks like a good idea. -- Tuválkin 16:00, 25 December 2017 (UTC)
  • Okay; but, we can't use 2 as a suffix because of the potential conflicts with   (STR2), etc. Useddenim (talk) 14:25, 26 December 2017 (UTC)
    @Useddenim: We could use it as a prefix (as with 1 for BRÜCKE1 etc.); incidentally I was thinking of making 4HUB (from 45°, 4 corners) icons for aligning HUBaq, HUB2 etc. with   (BHF2) etc.. Jc86035 (talk) 08:57, 27 December 2017 (UTC)
    @Jc86035: Wouldn't HUB2+g be a better name for the   (BHF2) overlay (similar to   (CONT2+g)? Useddenim (talk) 14:19, 27 December 2017 (UTC)
    @Useddenim: No, I meant like a   (HUB2) or   (HUBaq) where the HUB fits correctly with a   (BHF+1). I’ve seen some fudging of station positions in diagrams like w:en:Template:WMATA Blue Line where a 3HUB-G2 (or similar name) would be needed to fit 3ACCr+1 in the HUB properly. Jc86035 (talk) 15:21, 27 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, 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)

  • I would have gone with   (FILLy),   (FILLg),   (FILLb) and   (FILLr) (as with coloured roads). Useddenim (talk) 06:37, 27 May 2018 (UTC)
  • @Epicgenius: But why? -- Tuválkin 12:59, 2 June 2018 (UTC)
    • @Tuvalkin: I needed more than one fill icon for en:Template:NYP track map. However, the map no longer uses these icons. Jc86035 updated the local Routemap template so that individual cells may have background colors. epicgenius (talk) 14:45, 2 June 2018 (UTC)
      • (To clarify, I added this functionality about two years ago, although the documentation does not currently make it obvious that the functionality exists, as there is no example diagram which contains the cell formatting. Jc86035's alternate account (talk) 17:14, 2 June 2018 (UTC))

Ideas

@Useddenim, 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)

  • You’re supposed to be on a break, man!… Okay, I’m “processing” it in the back of my mind. Will comment later. Busy now. -- Tuválkin 13:15, 2 June 2018 (UTC)
    I'd written out most of the ideas beforehand, although it took me longer than I expected to formulate them into coherent and understandable English. Jc86035's alternate account (talk) 14:03, 2 June 2018 (UTC)

Flyovers

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

Current Proposed
  (vÜWBl) ✓
  (vÜWBr) ✓
  (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)
  • Aha, gotcha. We’re cool, then. -- Tuválkin 12:59, 2 June 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, 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)
    • BSicon .svgBSicon -BHFq.svgBSicon exDSTq-.svg (`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)
    • BSicon .svgBSicon -BHFq.svgBSicon exDSTq-.svg (vBHF-exDST~q) 
  3. Status quo; standard-width icons cannot contain transverse parallel lines with two roots without naming restrictions
    •   (STR+xro-STRr)
    • BSicon .svgBSicon -BHFq.svgBSicon exDSTq-.svg (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 BSicon .svgBSicon -BHFq.svgBSicon DSTq-.svg 
DSTq-BHFq
BSicon .svgBSicon ex-BHFq.svgBSicon DSTq-.svg 
DSTq-exBHFq
BSicon .svgBSicon -BHFq.svgBSicon exDSTq-.svg 
^exDSTq-BHFq
BSicon .svgBSicon -BHFq.svgBSicon exDSTq-.svg 
exDSTq-BHFq
t [et] [xt] ext
tvSTRq        
tDSTq-BHFq BSicon .svgBSicon t-BHFq.svgBSicon tDSTq-.svg 
tDSTq-BHFq
BSicon .svgBSicon ext-BHFq.svgBSicon tDSTq-.svg 
tDSTq-exBHFq
BSicon .svgBSicon t-BHFq.svgBSicon extDSTq-.svg 
t^exDSTq-BHFq
BSicon .svgBSicon ext-BHFq.svgBSicon extDSTq-.svg 
extDSTq-BHFq

@Useddenim, 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

@Useddenim, Tuvalkin, Epicgenius: Module:BSicon has informed me, by throwing an error on the 55 files I uploaded with a title containing RR, that I've accidentally created a naming conflict issue by allowing the modifier suffixes to be combined:   (RR) is a valid root, as are   (RG) and   (TRR). Should we do anything about this? There are only about 90 TRR, RG and RR icons combined, so one option would be to rename all of those icons. Jc86035 (talk) 18:54, 11 July 2018 (UTC)

  • The road icons are the ones that should be renamed, in my opinion. -- Tuválkin 21:19, 11 July 2018 (UTC)
@Jc86035: Aside from the fact that this is a case of “You broke it; you fix it”, I’m still trying to figure out what the -~LL and -~RR suffixes are supposed to mean. I think you need to expand the explanatory table to help us all with the compound suffixes that you’re now introducing. But I agree with Tuvalkin that the red and green roads can be renamed; but what would you propose for the Traverser/Transfer table icons? Useddenim (talk) 23:22, 11 July 2018 (UTC)
@Jc86035: Out of curiosity, what do these conflict with? epicgenius (talk) 00:47, 12 July 2018 (UTC)
@Epicgenius, Useddenim:   (hv-STR+1~RR), among others. I did this because the +L/+R suffixes were made redundant by extending the tilde suffixes to ~RR/~LL respectively (same for F/G), and it would be more confusing to have some of the transform suffixes go the wrong way.   (hdSTRr+1-)  (hdSTRr+1-~F)  (hdSTRr+1-~FF). It would already have happened earlier because I renamed the KBF icons to   (uBHF+r@GG) (metro big station on curve from right with station moved back twice) and so on. Jc86035 (talk) 04:55, 12 July 2018 (UTC)
I reused the + suffixes for the old-style formations that are perfectly against the icon edge (leer+hl  (lhSTR+L)). Jc86035 (talk) 05:14, 12 July 2018 (UTC)
TRR could become TRV. RG and RR could use some other arbitrary letter, although A, B, D, E, M, P and Y are taken, and we probably shouldn't use something which is already an affix (A, C, D, F, G, K, L, M, R, S, T, W, X). Alternately, we could change all the roads to use three-character roots to avoid syntactical problems which were bound to come up at some point. Jc86035 (talk) 05:27, 12 July 2018 (UTC)
Suggestion:
Existing   (RD1)   (RP1)   (RP2)   (RP4)
Proposed   (RPH)*
(RA)
  (exRPH)*
(RM)
  (RPB)
(RB)
  (RPR)
(RR)
  (RPG)
(RG)
  (RPWq)
(REq)
  (RPYq)
(RYq)
* H = Highway – Useddenim (talk) 12:20, 12 July 2018 (UTC)
  • I could go with Useddenim's suggestion, since it still uses the root "RP". epicgenius (talk) 12:31, 12 July 2018 (UTC)
@Useddenim: I was actually thinking about renaming RP[1-4] before this, since it's not a logical sequence (RP4 should logically have three dashed lines). [Like this:BSicon .svgBSicon RP4.svgBSicon RP2.svg (RP2RP4) ?Useddenim (talk) 16:52, 12 July 2018 (UTC)] Perhaps
  • RD → RPD
  • RP1 → RPS ("unclassified" / "single")
  • RP2 → RPP ("paved" / "painted")
  • RP4 → RPV ("divided")
and then (3), (3,2) could be optionally used for indicating lane numbers for P and V respectively, and (2,1-1,2) could be used to indicate transitions like   (RP2112). (There's a possibility that someone might want more than nine lanes, although if there's no road in the world which is that wide then I'd be fine with not having the punctuation. However, if we don't want to have some other sort of standard delimiter, the brackets might still be useful to avoid the usual naming conflicts.) Jc86035 (talk) 13:06, 12 July 2018 (UTC)
@Jc86035: I dislike the idea of using parentheses ( ) in icon names because it is two characters whereas all other delimiters are one and also that it’s easy to omit the closing ). Instead, I would suggest a semicolon ;– because we can’t use colons in file names – and commas to separate lane numbers. Then your examples above would become RPP;3, RPV;3,2, etc. Useddenim (talk) 16:52, 12 July 2018 (UTC)
@Useddenim: Another delimiter (` in sections above) would be needed to disambiguate all of the curves. Jc86035 (talk) 16:54, 12 July 2018 (UTC)
@Jc86035: Wouldn't ROOTgeometry;lanes be sufficient? Useddenim (talk) 23:17, 12 July 2018 (UTC)
@Useddenim: I think it would work, although I would want it to be consistent with naming for other icons like   (vÜSTr3+1) and the road crossings where the primary track geometry is indicated at the end of the name. Jc86035 (talk) 04:50, 13 July 2018 (UTC)
Worry about that when (if) it happens. Useddenim (talk) 11:36, 13 July 2018 (UTC)
@Useddenim: But it already exists, doesn't it? Just because   (hSKRZ-G13+1) and   (vÜSTr3+1) are conveniently named doesn't mean we shouldn't sort out the rest of it in a logical way. (It's also somewhat likely that if we figure it out and create a massive table full of nonexistent files that someone is eventually going to try and fill all the cells.) Jc86035 (talk) 04:07, 14 July 2018 (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, 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, 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 BSicon .svgBSicon hSTRa@g.svgBSicon exKSTRa.svgBSicon lGRENZE.svg  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, 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, 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)
  • Thanks, I will dwell on it. -- Tuválkin 22:59, 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, 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)