Talk:BSicon/Renaming/Archive 11

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

Parallel BHF legend

  (lBHF)   (lvBHF)
  (lBHF-)   (lvBHF-)
  (lvBHFf)
  (lBHFf)   (lvBHFff)

Any thoughts? Useddenim (talk) 11:33, 13 July 2017 (UTC)

As above, I would support usage of bracket notation (i.e.   (l-(vBHF)),   (lv-(ACC-))) as well as the creation of a new group of suffixes, probably -f/-g, to indicate that an object is moved forward (i.e.   (lvNULf-f),   (uABZg+1-g)), to separate those icons   (lHSTf) from the arrows   (HSTf) (and additionally -F/-G for elevated formations and the SKRZ icons, where -L/-R would not work). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:43, 13 July 2017 (UTC)

Road crossing with station

Moved to Talk:BSicon/Renaming/Roads#Road crossing with station
23:46, 31 July 2022 (UTC)

Curve crossings

@Useddenim and Tuvalkin: Should the icons in this category, e.g.   (KRZr-KRZ+ru), be renamed to e.g. STR+r-STRro? The current order of some of their names is incorrect, and the name suggests  . Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:41, 11 August 2017 (UTC)

Why not STR+ru-STRro? --C21H22N2O2 | talk | de.en 11:56, 11 August 2017 (UTC)
I wouldn't mind if that were done instead. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:59, 11 August 2017 (UTC)
What are you meaning with this? --C21H22N2O2 | talk | de.en 17:58, 11 August 2017 (UTC)
I would be fine with either STR+ru-STRro or STR+r-STRro.
If no one else comments, I guess they could be renamed anyway since most of them are already named incorrectly. Jc86035 (talk) 09:19, 13 August 2017 (UTC)

"+gr"

Useddenim, why   (SPLal+gr) and not vSPLal-? +gr suggests that the split is from both g and r, like   (ABZ2+gr) (and so the geometry would be something like  ). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:53, 2 August 2017 (UTC)

@Jc86035: I ran through several naming possibilities, and this seemed the best. I rejected your suggestion because of   (vSPLa):  (vSPLa-) / (v-SPLa) . I had also considered   (SPLal+g-)/  (SPLal+-g), but didn't like the +- combination (not to forget the -ROOT- convention used for single parallel lines across); however, if you think that it would be better, go ahead and move the four dozen files… Useddenim (talk) 12:42, 2 August 2017 (UTC)
@Useddenim:   (vSPLa-) doesn't look like that, so I don't think that's a problem. In any case the above icon would be better named vSPLa-SHI1r. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:12, 2 August 2017 (UTC)
Besides, your example ( ) is actually   (vÜSTl+gr). Useddenim (talk) 13:18, 2 August 2017 (UTC)
@Useddenim: Using that naming structure, would it then make sense to rename   (vÜSTelr) to vÜST2h3h (or a different suffix, if it's replaced with something else)? This might be somewhat problematic, though, since vÜSTr+1 could mean either a crossing from r to 1, or a crossing from f to 1 with only the right crossing track like   (vÜSTr3+1). Unless the meaning of l and r in this context is changed then there will be edge cases where the naming is ambiguous. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:35, 2 August 2017 (UTC)
I think you just made the case for different roots for a single crossover (  (vÜSTl)/  (vÜSTr) and a double crossover (  (vÜST). So which one keeps ÜST and which one changes? Useddenim (talk) 13:48, 2 August 2017 (UTC)
Upon further thought, I would suggest keeping   (vÜST) (T = two) and use   (vÜS1) for singles, eg   (vÜS1l)/  (vÜS1r), etc. Useddenim (talk) 13:56, 2 August 2017 (UTC)
@Useddenim: Perhaps a different three letters from "Überleitstelle"? Seems a bit arbitrary to use a number. Tuvalkin and Lost on Belmont, any thoughts? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:31, 2 August 2017 (UTC)
ÜLS (or is it ÜLT?) works for me. Useddenim (talk) 14:37, 2 August 2017 (UTC)
@Useddenim:   (vSTRegr) could be renamed under this rule as vÜSTlfr, but then this leaves   (vSTReglr) which couldn't be renamed to this root.
Possibly an apostrophe could be used to distinguish the icons with naming conflicts? Jc86035 (talk) 10:06, 14 August 2017 (UTC)
Um, didn’t think to check (the existing)   (vSPLa-)/  (v-SPLa); so yes, you’re right,   (SPLal+gr)⇒vSPLal- etc. Useddenim (talk) 13:26, 2 August 2017 (UTC)

Parallel stations

@Useddenim and Tuvalkin: How should   (vfHST-fexHST2) be distinguished from   (fvHST-exHST)? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:25, 3 May 2017 (UTC)

  • The first one could be fvHST-exHST and the second one fvHST-L-exHST-R. -- C21H22N2O2 (V • T • E) 12:19, 3 May 2017 (UTC)
@C21H22N2O2: Problem with that is there are a lot of other icons which would be affected by this. Syntactically it's more correct I suppose but it would be another several hundred (thousand?) renames. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:35, 3 May 2017 (UTC)
  • I suggest:
  •   (fvHST-exHST) (no change), based on f &   (vHST-exHST)
  •   (fvHST-+fexv-HST), using the generic + to overlay otherwise independent icons   (vHST-) and   (exv-HST)
-- Tuválkin ✉ ✇ 21:56, 3 May 2017 (UTC)
 Agree with Tuvalkin's proposal. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:55, 4 May 2017 (UTC)

✓ Done Jc86035 (talk) 09:58, 23 August 2017 (UTC)

Remaining GRENZE to be renamed ZOLL

Separated from Talk:BSicon/Icon geometry and SVG code neatness#ZOLL

Aside: should the icons   (HGRENZEr) and   (KGRENZEl) be merged into a single GRENZEaq, like   (ENDEaq)? Likewise for   (HGRENZEl) and   (KGRENZEr).   ~ Newfitz Yo! 14:05, 17 June 2017 (UTC)

  • @Newfraferz87: Probably better to just rename them to use ZOLL, as GRENZE was replaced by it and GRZ as far as I'm aware. I did this while clearing out the motorways and vBRÜCKEs; e.g.   (RBoWq+ZOLL) and   (vBRÜCKE1+ZOLL). Jc86035 (talk) Use {{re|Jc86035}}
    to reply to me     16:02, 17 June 2017 (UTC)
  • In my opinion, and to match what has been done (how did these four escape?), the renaming should be:
old name new name
(1st proposal)		 new name
(later suggestion)
  (HGRENZEr)   (ZOLLaq)   (KZOLLaq)
  (KGRENZEl)
  (HGRENZEl)   (ZOLLeq)   (KZOLLeq)
  (KGRENZEr)
-- Tuválkin ✉ ✇ 23:57, 17 June 2017 (UTC)
Agree.—or should they be KZOLL? BTW, the H (for Horizontal) prefix should have been eliminated long ago. Useddenim (talk) 03:51, 18 June 2017 (UTC)
  •  Support In this case ENDE should be KSTR, but I don't know if this is necessary. KZOLL is okay. -- C21H22N2O2 (V • T • E) 05:29, 19 June 2017 (UTC)
Support KZOLL. Lost on  Belmont 3200N1000W  (talk) 22:34, 19 June 2017 (UTC)

@Lost on Belmont, Useddenim, C21H22N2O2, Newfraferz87, and Tuvalkin: ✓ Done; deletion discussion for the two HGRENZE icons is here. Jc86035 (talk) 09:56, 23 August 2017 (UTC)

legende ACCs

@Useddenim, Tuvalkin, and Newfraferz87:   (llACC-R) or   (lACCx-R)? Jc86035 (talk) 12:44, 24 August 2017 (UTC)

I don't like the ll prefix (which has the possibility of confusion with the already-existing LL prefix for interrupted lines), which is why I chose the x suffix (for minor feature out of use). (Besides which, you never added it to the catalog, so how are we to know that   (llACC-R) even existed?) Useddenim (talk) 13:47, 24 August 2017 (UTC)
@Useddenim: Sorry for not adding them to the catalogue (I wasn't aware that every new icon was supposed to go in it). I don't think it would be confused with LL since one is for stations only and the other is for tracks only, although I think one of llACC/lACCx could be used for just the wheelchair and the other could be used for just the station circle. Jc86035 (talk) 15:32, 24 August 2017 (UTC)

llACC icons

moved from Talk:BSicon

I couldn't see any differences between   (llACC) and   (ulBHF) until I read the source. I don't think that a "normal" user can tell apart them. If we need an icon who shows a station who had disability access in past, it should show a crossed wheelchair, e. g.   (BHFxA) (should get renamed or replaced). I also uploaded a test icon   (llACC2), how is it? -- C21H22N2O2 /talk/lab/de/en 11:31, 25 August 2017 (UTC)

@C21H22N2O2: Without these it would be hard to make   (llACC-L) +   (lACC-M) +   (llACC-R), unlike with   (lINTACC-M), which can connect to   (lINT-L) and other regular INTs.   (llACC) is arguably not as useful though (unless it's being used to cover another wheelchair). Jc86035 (talk) 16:18, 25 August 2017 (UTC)
@Jc86035: But the   (llACC)/  (ulBHF)-problem isn't solved. They're too similar that a normal wikipedia reader can tell apart them. -- C21H22N2O2 /talk/lab/de/en 17:56, 25 August 2017 (UTC)
@C21H22N2O2: The llACC/lACCx icons aren't supposed to be used without a wheelchair somewhere in the icon, so I don't think this is an issue. Jc86035 (talk) 04:02, 26 August 2017 (UTC)
Ah, there are only used in overlays like   (lACC-L) +   (lACC-R)! But why not remove all icons like   (lACC) and replace them by overlaying a white wheelchair like   (lACC2)? -- C21H22N2O2 /talk/lab/de/en 09:19, 26 August 2017 (UTC)
@C21H22N2O2: This would be pointless since every wheelchair is supposed to be accompanied by that shade of blue. The wheelchair-only icon could be useful in some situations though (e.g. over   (llvACC-L) connected to a non-ACC station). Useddenim, do you think   (lACC2) could be renamed to   (llACC) or lACCx after all of the llACC/lACCx icons are renamed/redirected to the other group of icons? Jc86035 (talk) 12:27, 26 August 2017 (UTC)
Not a problem, as there are only 16 icons—including duplicate images— in the group. But we still need to settle on which root to use. Tuvalkin? Sameboat? Useddenim (talk) 13:20, 26 August 2017 (UTC)
Isn't ABHF for Azweigbahnhöfe like   (ABHFr+r)? -- C21H22N2O2 /talk/lab/de/en 19:13, 26 August 2017 (UTC)
I don't know one. The first icon only with a wheelchair on blank ground was uploaded by me yesterday and I used the ACC root to name it. Any ideas? -- C21H22N2O2 /talk/lab/de/en 21:26, 26 August 2017 (UTC)
@Tuvalkin and C21H22N2O2: The currently existing ones are   (llACC) and   (lACCx) (this is, to clarify, concerning prefix/suffix options). I would prefer using those two, or another suitable suffix combination, rather than creating a new root. Jc86035 (talk) 07:46, 27 August 2017 (UTC)

@Useddenim, Tuvalkin, C21H22N2O2, and Newfraferz87: If no one comments, I would personally prefer using lACCx for the icons without wheelchairs, similar to how   (INT-xR) has the INT stripped away with only a BHF.   (lACC2) could become llACC. Jc86035 (talk) 11:38, 28 August 2017 (UTC)

 Agree. Useddenim (talk) 14:48, 28 August 2017 (UTC)

More things

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

  • What followed was then split into four H3 sections, but this (needless) threading is preventing some to be archoved till the last one is closed. Changing those to H2 now. -- Tuválkin ✉ ✇ 18:17, 4 September 2017 (UTC)

The north arrows

Should the north arrows   (numN000) be renamed NORTH, NORTH045 etc.? They're not really numbers/letters, and it would help with reducing/deprecating the num prefix, due to the not-capital-letters thing (and also since all other nums are replaceable in {{Routemap}} with real text). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 18:22, 12 April 2017 (UTC)

HUBs

@Jc86035: How do you plan to resolve this conflict?

  (HUBl)   (HUBlf) → HUBl+g
  (HUB+l)   (HUBrg) → HUBf+l
  (HUBr)   (HUBrf) → HUBr+g
  (HUB+r)   (HUBlg) → HUBf+r

Useddenim (talk) 12:18, 9 September 2017 (UTC)

@Useddenim: You could do something like you did with   (lGRZ2m3) I think (HUBm+lf and not HUBlmf per above section?), or just not do anything and leave it to someone else down the line who wants to fix it. In any case the HUBs use all sorts of nonstandard naming like using the s, t and x suffixes in different ways. Jc86035 (talk) 12:32, 9 September 2017 (UTC)

TEEs and TBHFs

@Useddenim, Tuvalkin, and Newfraferz87: Should the e/x TEEs have their colours swapped? Compare   (xKRZ) and   (xTEEe). In addition, if the TEEs and TBHFs use the same naming structure as KRZs, would TBHFaq/…axq/e…aq/x…aq/ex…aq/ex…axq be             (based on rotating   (TBHFa) etc.)? Jc86035 (talk) 10:37, 8 September 2017 (UTC)

No. For   (xKRZ) the primary line is  , while for   (xTEEe) the primary line is  . Useddenim (talk) 00:42, 9 September 2017 (UTC)
@Useddenim: Shouldn't   (xTEEa) match   (xTBHFa) as well? Should the TEEs be the only icon group where the transverse line is by default primary? I think for consistency's sake it would be better to swap the colours. Jc86035 (talk) 04:07, 9 September 2017 (UTC)
I do everything I can to avoid using ⊤ TBHF icons. However, it's my understanding that a through (i.e. edge to opposite edge) line takes precedence. Useddenim (talk) 12:04, 9 September 2017 (UTC)
There was a discussion about   (eABZ2+4g) or something like that, so this could plausibly follow that consensus. Should   (xTBHFa) then be TBHFax (-xa is used by   (TBHFxaq))? Jc86035 (talk) 12:09, 9 September 2017 (UTC)
  (xTBHFaq) and   (TBHFxaq) looks like a bad naming conflict to me. I have half a mind to keep the TBHF root for only X-junctions and use TEE+BHF, but that would create a new level of trouble with existing icons.   ~ Newfitz Yo! 12:20, 9 September 2017 (UTC)
@Newfraferz87: I actually renamed the -xaq icon from   (BHF+TEEr+xl) per § KBHFs (the TEE part would now be TEExaq, I think), but there aren't any naming conflicts since x can be placed before and after a/e, per KRZ rule that crossing geometry-related suffixes precede others and per ENDExa. Jc86035 (talk) 12:30, 9 September 2017 (UTC)

@Useddenim: Note also   (uextTBHFte), uploaded last year by Tuvalkin. I'm still not sure if adding e should mean e and x are swapped. (This would probably be renamed to either uextTBHFet or uetTBHFext.) Jc86035 (talk) 11:58, 10 September 2017 (UTC)

Continuation curves

@Useddenim and Tuvalkin: Could this be done for consistency, seeing as most other icons use + for point-to-point lines (e.g.   (CONT3+g))?

Current Proposed
  (CONTlf) CONTf+l
  (CONTlg) CONTg+l
  (CONTrf) CONTf+r
  (CONTrg) CONTg+r
  (CONTfl) CONTl+f
  (CONTgl) CONTl+g
  (CONTfr) CONTr+f
  (CONTgr) CONTr+g

Jc86035 (talk) 11:52, 9 September 2017 (UTC)

✓ Done (and redone with second suffix of each icon swapped after I realized the original names had incorrect suffixes). Jc86035 (talk) 02:10, 11 September 2017 (UTC)

Duplicate move requests

These files were moved on 7 September by Jc86035 (talk · contribs) citing discussion here. Rowan03 (talk · contribs) is requesting they be moved again. I moved one of them and added "2" because his original request ended with an apostrophe, but I declined the other requests when I saw they had recently been moved following a discussion. He requested another move request, wanting to swap file names apparently. I don't know what any of the titles mean but please resolve this here and come to a consensus as to what they should be named before additional requests are made. Thank you. Wikimandia (talk) 01:17, 11 September 2017 (UTC)

@Wikimandia: Fixed. The original titles were incorrect (BSicons' left and right are relative to going down the page, not to the viewer) and I didn't catch this in moving the files. Fortunately they aren't actually used so I just swapped the contents of the files to avoid having to fix redirects and do a round-robin page move. Jc86035 (talk) 01:44, 11 September 2017 (UTC)
Awesome, thank you so much! Wikimandia (talk) 01:45, 11 September 2017 (UTC)

ABZ and STR icons

Could we rename   (ABZlf),   (ABZlg),   (ABZrf) and   (ABZrg) (plus all variants) to the expected ABZgl, ABZg+r, ABZgr and ABZg+l, since there aren't any conflicts preventing the moves? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 18:22, 12 April 2017 (UTC)

 Strong support ! If necessary we can use a bot so it goes faster. --C21H22N2O2lovesBSFor me!From me! 06:43, 13 April 2017 (UTC)
Plus the curves   (STRlf),   (STRlg),   (STRrf) and   (STRrg) to STRl, STR+r, STRr and STR+l. STRl and STRr are currently existing, but they're only redirects to   (STRfq) and   (STRgq). --C21H22N2O2lovesBSFor me!From me! 06:48, 13 April 2017 (UTC)
@C21H22N2O2: JJMC89 bot has replaced all the redirects on the English Wikipedia already, but it's only replacing BSicon names there so far so it might take a bit more time for the curves since the redirects are used a lot (1, 2, 3, 4, 5, 6, 7, 8). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:02, 13 April 2017 (UTC)
@Jc86035: I believe we have enough time, or is that not correct? --C21H22N2O2lovesBSFor me!From me! 10:12, 13 April 2017 (UTC)
@Jc86035: But we can rename the curves and junctions now and then the bot does his work, right? --C21H22N2O2lovesBSFor me!From me! 10:15, 13 April 2017 (UTC)
@C21H22N2O2: No, because the redirects are still in use and they aren't automatically changed by CommonsDelinker or anything (the bot only fixes templates on enwiki so far). If we were to delete the redirects and move the curves over without replacing usage first then a lot of pages would show the wrong images. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
@Jc86035: Ok, that means that we have to fix all usages of STRl and STRr before we rename them to the curves. But the six others we can rename now, because they aren't redirects to other icons. --C21H22N2O2lovesBSFor me!From me! 11:15, 13 April 2017 (UTC)
@C21H22N2O2: I think it's best not to rename half of the curves before the others… probably best to keep it consistent within each group. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:19, 13 April 2017 (UTC)
@Jc86035 and Axpde: Ok, so we need some bots to do the first part. I suggest that Axpde and I do the job at de:WP and the others ... don't know. We'll find a solution. --C21H22N2O2lovesBSFor me!From me! 11:24, 13 April 2017 (UTC)
Pinging JJMC89. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:25, 13 April 2017 (UTC)
 Strong support ... although it will confuse legions of users, but IMHO Bernina made just one mistake in his template: his Fahrtrichtung ("f") vs. Gegenrichtung ("g") concept :-( a×pdeHello! 09:38, 13 April 2017 (UTC)
The f/fq/g/gq prefixes are good, but they shouldn't be confounded with the a/l/e/r prefixes. IMHO we've to make a clear border between these both prefix groups. And for the confused users we can use a non-confused bot... --C21H22N2O2lovesBSFor me!From me! 09:58, 13 April 2017 (UTC)

@Jc86035: OK, I think at de:WP is all clear, only my bot request or the associated archive are using this icon. --C21H22N2O2lovesBSFor me!From me! 19:03, 14 April 2017 (UTC)

@C21H22N2O2: It's probably still better to get a bot running on dewiki, or we'll be stuck with the newly-created redirects forever, it'll be confusing for new editors to have to deal with multiple icon names for the same thing, and we won't be able to repurpose the redirects if we need to. I think JJMC89 is handling that though. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:41, 15 April 2017 (UTC)
@Jc86035: I don't think that all is clear, I know it. I've checked the WhatLinksHere (in German: Linkliste) and you can do that too: STRl, STRr, exSTRl, exSTRr, uSTRl, uSTRr, uexSTRl, uexSTRr. Ok? -- C21H22N2O2 (V • T • E) 10:17, 15 April 2017 (UTC)
I think it's fine? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:35, 15 April 2017 (UTC)
Yes, it's fine ;) OK, I've to admit that i've used these icons on one of my subpages on de:WP, but with them I want the new version. To sum up: Houston, all OK here in Germany, how is it with other countries? -- C21H22N2O2 (V • T • E) 05:53, 17 April 2017 (UTC)

@C21H22N2O2, Axpde, Useddenim, and Tuvalkin: JJMC89 has begun implementing the replacement script on several wikis, including the German, Chinese, Spanish and French Wikipedias. There are about 50 of them to do, but hopefully it'll be done soon so the above icons (and others) can be renamed. I am unable to vote on wikis (due to low edit count) where bots require consensus, but it may be possible for you to do so. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 16:57, 3 July 2017 (UTC)

@C21H22N2O2, Axpde, Useddenim, and Tuvalkin: I have nominated almost all of the problematic redirects for deletion here. The last eight (global usage linked above) are still used on some wikis and will have to wait a little bit longer. If pywikibot's throttle gets fixed (currently it keeps hitting the Commons limit of 8/minute) I will do all of the file moves semi-automatically. Jc86035 (talk) 11:52, 28 August 2017 (UTC)

@C21H22N2O2, Axpde, Useddenim, Tuvalkin, Newfraferz87, Lost on Belmont, and Sameboat: Last eight are now up for deletion, so if all goes well I will be doing a lot of page moves soon. Jc86035 (talk) 16:29, 4 September 2017 (UTC)

@C21H22N2O2, Axpde, Useddenim, Tuvalkin, and Newfraferz87: @Lost on Belmont and Sameboat: ✓ Done with almost all of them. Remaining: CPIC and GRZ icons (not touching them yet since they're a mess),   (BHFlf!) etc. (needs redirect deletion),   (RP4r) etc. (see this section),   (KBFrg) etc. (not sure how to rename them),   (WDOCKSlf) etc. (conflict with   (WDOCKSl)),   (dWDOCKSs+lf) etc. (not sure how to rename them),   (fWBANKllf) etc. (not sure how to rename them),   (uABZrff) etc. (might need redirect deletion),   (WWECHSELlf) etc. (not sure how to rename them),   (Tlf) etc. (nonstandard, some icons use Cyrillic Т), and a few others. Jc86035 (talk) 16:12, 12 September 2017 (UTC)

  • @Jc86035: All these special cases need a separate analysis, even when/if renaming them into a better, more homogenous way turn out to be swift and simple. Since the bulk renaming is done, this section should be close and allowed to be archived — also to enable stable reference of it in those and other discussions. -- Tuválkin ✉ ✇ 16:32, 12 September 2017 (UTC)
  • @Jc86035: thanks for you efforts but I'd say let those water "BS"icons untouched, it's not of our concern ;-) a×pdeHello! 17:07, 12 September 2017 (UTC)

Cutting to tunnel transitions

@Useddenim and Tuvalkin: I have renamed most of the *CC icons (the enwiki catalogue needs updating), but I didn't realize that the CBHFCC icons would be problematic since e.g.   (tCSTRa) shows the end of a tunnel, as opposed to   (htSTRa) showing the start of one.

  • Should   (tCSTRea)/  (tCSTRae) (plus variants) be renamed to teCSTRa/taCSTRe (or tCaSTRe/tCeSTRa)? The usage of ae and ea, of course, conflicts with   (tSTRea) and similar.
  • None of the CBHFCC icons are actually in use, having been created randomly by 京市. Should they be re-renamed from *eaq to *aeq, or should I just upload the correct shape (with the cutting on both sides) without renaming them?
  •   (uextCSTRea-Rq) and others uploaded by Xeror are out of sync with the other tunnel portals uploaded by Useddenim. Should they be re-renamed from *eaq to *aeq as well?

—Jc86035 (talk) 07:42, 1 October 2017 (UTC)

Suffix reuse

@Useddenim, Tuvalkin, C21H22N2O2, and Newfraferz87:   (RP4r),   (RP2r) and   (RP1r) (roundabouts) are currently blocking page moves for   (RP4rf),   (RP2rf) and   (RP1rf) (90° curves). I did not notice this so all of the others have been renamed (I used pywikibot so they were all done in one go). Should the roundabouts be renamed? Jc86035 (talk) 15:59, 12 September 2017 (UTC)

 Strong support Which suffix would be well for them? rb? -- C21H22N2O2 /talk/lab/de/en 16:23, 12 September 2017 (UTC)
  • Civilspanaren used r (from "roundabout"?) back when these road icons were meant to be something different than just a new “set light-grey-with-white-lane-lines”, but now it really needs to be changed. Too bad that o and x have already meanings, and b is not really free for use, although it is a prefix. Now, some ideas:
STR+r
STRr
d
  • Thinking in broader terms, though, what we have here is a kind of crossing/merging of genric “lines” not unlike what we name as, say,   (ABZ),   (WSL), or   (ÜST). This suggests that what we need here is not a new suffix, but a new root name!
  • (Of course that would clash with current naming of these road icons, where, according to the original naming idea, the root ID determines the type of road while prefixes and sufixes denote geometry and topology. So, either we keep these road icon names as a separate paradigm, or we homogenize them all. The series   (SKRZ-G) shows that a hybrid naming scheme, if properly implemented, can be successful, however.)
  • If we think that it would be useful to have this geometry/topology in a single icon for any regular line/track icon, not only for these road oddities, (see diagram) then we should find a new root ID for these icons.
-- Tuválkin ✉ ✇ 18:37, 12 September 2017 (UTC)
What about using D as a suffix (RP#D a/e/l/r), for the (visual) similarity to   (DST)? Useddenim (talk) 19:15, 12 September 2017 (UTC)
The root structure is fine, but why not RP#RB? -- C21H22N2O2 /talk/lab/de/en 19:47, 12 September 2017 (UTC)
@C21H22N2O2: I would avoid using both capital B and capital R due to   (RB) (as with RA, D, E, G, M, P, R and Y). One letter might be fine. Jc86035 (talk) 02:58, 13 September 2017 (UTC)
@Useddenim: I'd use d since it's unused and not a valid suffix without +. D is a suffix already   (DKRZD), so it should probably be avoided here. If there's no objection I'll rename them at some point. Jc86035 (talk) 08:07, 1 October 2017 (UTC)
@Jc86035: RP#d would be fine. Useddenim (talk) 11:28, 1 October 2017 (UTC)

Water

@Useddenim: Since there's no WDOCKS-L, shouldn't   (WDOCKS-Le) etc. be named based on   (WDOCKSe) and therefore be WDOCKSe-R [right side], like   (lhSTRe-R)? Jc86035 (talk) 11:22, 8 October 2017 (UTC)

Yes. Useddenim (talk) 10:05, 9 October 2017 (UTC)
✓ Done Jc86035 (talk) 12:38, 9 October 2017 (UTC)

Junction icons

@Axpde: 45° junctions follow the same conventions as those with the point of the junction at f or g, just not in the way that you think they do. Jc86035 (talk) 06:42, 25 November 2017 (UTC)

  (ABZr+12)   (ABZ23)   (ABZl+34)   (ABZ+14)
  (ABZr+1f)   (ABZr+2g)   (ABZ2r)   (ABZ3l)   (ABZl+3g)   (ABZl+4f)   (ABZ+4l)   (ABZ+1r)
  (ABZr+1g)   (ABZr+2f)   (ABZ2l)   (ABZ3r)   (ABZl+3f)   (ABZl+4g)   (ABZ+4r)   (ABZ+1l)
  (ABZ3+1g)   (ABZ4+2f)   (ABZ4+2l)   (ABZ1+3r)   (ABZ1+3f)   (ABZ2+4g)   (ABZ2+4r)   (ABZ3+1l)
  (ABZ4+fl)   (ABZ1+fr)   (ABZ2+gr)   (ABZ3+gl)

WSL

@Useddenim, Tuvalkin, Axpde, and Vunz: Since there are now a bunch of weirdly named WSLs uploaded by 蘭斯特 like   (WSLr+l+l), and since the existing system is also a bit inconsistent, should the WSL naming conventions be changed? Jc86035 (talk) 12:37, 9 November 2017 (UTC)

Current Proposed (Jc86035) Proposed (Axpde)
  (WSLg+l) etc. ✓[OK] Fine OK
  (WSLe) etc. ✓[OK] Fine OK
  (WSLr+r) etc.   (WSLeq) (based on   (vWSLeq)) OK
  (WSLqr) etc.   (WSLglq) OK
  (WSLq+r) etc.   (WSLgrq) OK
  (WSLql) etc.   (WSLg+lq) OK
  (WSLq+l) etc.   (WSLg+rq) OK
  (WSLr) etc.   (WSLlq) OK
  (WSLa+l) etc.
  (WSLel) etc.		   (WSL+l)
  (WSLl) (after targets are renamed and replaced)		 OK
  (WSLr+l+l) etc.   (WSLge) (based on   (vWSLge))   (WSLge)
  (eWSLgcc) etc.   (exWSLga)   (exWSLga)
  (uWSfd) etc.   (uWSLgaq)   (uWSLql+l)
@Axpde: We can't use …ql+l for   (uWSfd), because following   (uexWSLg+lr), either that would be one loop on each side, or it would be impossible to have an unfilled   (uexWWPr)canal icons are exempt from logic at this point in time because of the naming conflict. If we use q as a 90° anticlockwise rotation of the whole icon, then we may as well rename all the others to use q that way where logical and appropriate. Jc86035 (talk) 15:19, 9 November 2017 (UTC)

@Useddenim, Tuvalkin, Vunz, C21H22N2O2, and 蘭斯特: ✓ Done (renamed 81 files; others will follow after replacement). Further to the above, could we rename the double-width WSLs as well? (I'm not entirely sure that the existing vWSLg(+)?[lr] files are named correctly – I would have swapped l and r in the names – but they make sense. It's possible to round-robin-swap the file names and have them automatically replaced by JJMC89 bot now, though, so it's not an issue if they should be changed as well.) Jc86035 (talk) 12:02, 25 November 2017 (UTC)

Current Proposed Notes
  (bvWSL-BS2+r) etc. bvvWSLg+l (or bvvWSLg+r) like   (vWSLg+l)
  (uebSHI2+r+WSLe) uebvvWSLgr (or …gl) like   (evWSLgr)
  (bvWSL-BS2lxr) etc. bvvWSLgrxl (or …lxr) like   (vWSLgr) + (xvWSLgl)
@Jc86035: Wouldn't the bvvWSL icons look something like   (bvvWSLe), or does the bvv prefix signify something different than double-width; parallel line; parallel line? Useddenim (talk) 22:28, 25 November 2017 (UTC)
@Useddenim: I think that icon would have bvvv, per   (vSPLa) ≈ vvSTRa. I had thought bvvvWSLe would just be the outer loop, but adding inner loops where possible also makes sense. (Do you think the icons should have l/r swapped or are they fine?) Jc86035 (talk) 04:42, 26 November 2017 (UTC)

SKRZ

@Useddenim and Tuvalkin: There is still some inconsistency in how SKRZs are named; could we fix that? Jc86035 (talk) 03:26, 3 December 2017 (UTC)

Current Proposed Notes
  (SKRZ-Buq) etc. ✓[OK] Fine
  (SKRZ3+1-Bu) etc. ✓[OK] Fine
  (SKRZ-G4hq2+4) etc. ✓[OK] Fine (or SKRZq-G4h2+4)
  (SKRZ-G43+1o2+4) etc. SKRX-G4o If KRX is picked then a rotated version would probably be SKRX-G4oq
SKRX is much neater than SKRZ2+4…3+1, but otherwise seems like a good idea. Useddenim (talk) 12:18, 3 December 2017 (UTC)
@Useddenim: I've corrected the rest of the proposal because I mixed up the primary/secondary convention. I think the last icon is probably the only one that needs renaming at present. Jc86035 (talk) 13:31, 3 December 2017 (UTC)

✓ Done (renamed the latter icon). Jc86035 (talk) 14:02, 24 December 2017 (UTC)

Prefix order

@Useddenim and Tuvalkin: Does k go before [o/]c/d/b[/s/w]/v   (kvSTR+1) or after   (dkSTRc1)?

Furthermore, is it logically consistent for C, D and 3 to be "root modifiers" while other similar suffixes are placed before c, d and v (in particular 3, which isn't a capital letter)? Though vCSTR might look slightly better than CvSTR, and this doesn't really matter. Jc86035 (talk) 12:48, 27 December 2017 (UTC)

Using tildes

Useddenim, are we doing this now? It seems sensible, although edge cases could conflict with the !~ used in {{Routemap}}. Jc86035 (talk) 13:11, 31 December 2017 (UTC)

Not all icons affected listed in table
Current Proposed
  (dBHF~L fuchsia) dBHF~R fuchsia to synchronize with other icons, since this is the right half
  (STR-R) STR~R (or vv--STR)
  (dSTR-R) dSTR~R or dv-STR
  (lhSTR-R) ✓[OK] Okay
  (KRZo-R) ✓[OK] Okay
  (SEP-L) SEP~R
  (lBHFf) lBHF~F
  (lvBHFf) lvBHF~f small f meaning quarter of an icon, possibly combining?
  (lvBHFgg) lvBHF~G
  (lBHFgq) lBHF~R or lBHF~Gq both names would work but since there's no line I think we would choose the shorter one?
  (dKBHF~Leq lime) dBHF~Fq lime or dBHF~fq lime
  (exKBHF~F brown) exBHF~f- brown or exBHF~F- brown with parallel lines syntax? not sure
  (mKBHF2 u~steel) ✓[OK] Okay (or umKBHF2 ~steel)
  (mBSHI2l u~purple) umvBHFSHI2l- ~purple or mvBHFSHI2l- u~purple based on BHFABZ
  (SHI1+r+BHF) BHFSHI1+r to avoid ambiguous nesting of + combining two roots within parallel lines syntax
  (BHF yellow-blue) mBHF yellow~blue
  (BHF black-halforange) mBHFe black~orange+black
  (mbSHI4l exmaroon~ochre) embvvSHI4l-- maroon~ochre inconsistent with ex-primary object being xROOT, but per   (emvSTR), unless we want to change those as well
do we really want this? the colour contrast is extremely low and it's difficult to tell that the track has two colours
  (mBSHI2r fuchsia~exmaroon) mv-BHFSHI2r fuchsia~ex·maroon with interpunct/middot (alternately apostrophe?) or mv-BHFSHI2r fuchsia~exmaroon without interpunct
  (BHFlf) BHFf~l or BHFf-l or ~BHFf? we can't use ~L or -L
I'm fine with any renaming that synchronizes things. I just needed some titles that would fit within the existing naming and not cause conflicts or usurp a more conventional design. There shouldn't be a problem with the !~ overlay, as I can't think of any design that would begin with a ~. Move as you see fit. @Tuvalkin: ? Useddenim (talk) 14:41, 31 December 2017 (UTC)
@Useddenim: I've added some more entries to the table, since I wrote the above while you were uploading files. Are those fine as well?
  1. The issue with the double-width icon is the thing about the primary/secondary convention and the colours not matching:   (xmABZgl) vs   (xmvSTR). There aren't any practical issues with keeping it the way it is, especially since the set~set/set+set thing currently matches the left-to-right direction of the parallel lines and that would have to be changed as well if xmv were to be swapped with emv, but it's still keeping me up at night somewhat of an annoyance which could be fixed in a few hundred semi-automatic page moves and redirect deletions.
  2. How do we deal with, say, a BHF with ex·u~pink or ex·u~f? Do all parts always have to be put after the icon? Would we use uex~pink or exu~pink or ex·u~pink or umROOT ex~pink? Would we just have a tilde after a [bahn]~u icon since it could use the um prefix?
  3. Would you treat ~F as forward to the icon edge or forward half an icon? Would it be different for parallel lines, as f currently is? Would ~f be correct or would it be better to use some sort of combining parallel lines syntax?
  4. Couldn't we use dv-BHF instead of dBHF~R? I think it's somewhat unnecessary to use a new suffix for something that can be done just with parallel lines syntax and this batch of renaming would be a good time to switch icons over to use v and vv for that.   (exKBHF~F brown) could be renamed to be fm[K]BHFea ex·brown+ (like   (mKBHFea), which might not need the K) and the rest of the station added.
  5. Do we indicate triple colours with two tildes? Do we add a double m prefix? Should they exist (low colour contrast, etc.)?
Jc86035 (talk) 15:27, 31 December 2017 (UTC)

We could fix the (u)mv problem for once and for all by eliminating the m prefix:

  (mvSTR) →   (vSTR ~u)   (umvSTR) →   (vSTR u~)

and then have all colour combinations follow on from there. Useddenim (talk) 21:05, 31 December 2017 (UTC)


Something else to throw in to the mix:   (TBHF) →   (BKRZ), using B (and I for INT) as an icon modifier for ABZ/WYE, KRZ/KRX, SHI, etc. Useddenim (talk) 20:57, 31 December 2017 (UTC)

@Useddenim: I think if we were to remove m from parallel lines (which I think we shouldn't, since it's quite convenient, we'd still be using e and x anyway, and it would be inconsistent with using it for junctions) it would be better with dashes, since a tilde would imply that both lines were striped as in   (vxSTRe) (which would probably become vSHI1l ~ex-SHI1r ex~ or something like that; is m necessary?).
I am against using B as a prefix just because it's convenient, since B could mean BHF or BST, and A for ACC and D for DST would conflict with the existing A and D prefixes. We can afford to add two more letters to a few icon names. Jc86035 (talk) 05:21, 1 January 2018 (UTC)
Well, it was a thought… Useddenim (talk) 16:41, 1 January 2018 (UTC)

lINTs

Current Proposed
  (lINT1) etc.   (lINT-1)
  (lINT2+4) etc.   (lINT-24)
  (lINT-1) etc.   (lvINTf1) or   (lvINTc1)?
if lvINTc1
  (lINTc1) etc.   (lv-INTg) or   (lv-(INT-))?
  (lINTc3) etc.   (lvINTf-) or   (lv(-INT)-)?
  (lINTf1) etc.   (lINTc1)
corner 3 connection
from   (lINTf2)
to   (lINT2+4)		   (lINT-4+G)?
corner 1 connection
from   (lINTf2)
to   (lINT2+4)		   (lINT-4+R)?
  (lvINTlq)/rq   (lvINTffq)/ggq

@Useddenim and Tuvalkin: The dash in   (lINT-2) indicates that it should be an INT from middle to corner 2, but that icon is   (lINT2), which is probably incorrectly named since it should be something similar to   (lhBHF2) (with only the circle and not the formations).

  (lINT-1) connects to   (vSTRc1) and not   (STRc1), so I would probably rename it to lvINTf1 or lvINTc1 to indicate what it actually could be used for (the only use of the icons is here, which should actually use   (exlINTf2) and connecting icons). Using the latter name would make more sense but it would be inconsistent with   (lINTc1) and we would have to rename those to something else. I suppose using f and g makes sense per   (v-STRrf) and   (lvBHFf). Jc86035 (talk) 09:10, 14 January 2018 (UTC)

  • I agree with the renaming principle: Stations should not be named as if they were lines. Besides, INs should be named using the same principles as BHF, right? (As for the details, I don’t have any insights to share right now; will revisit later if necessary.) -- Tuválkin ✉ ✇ 23:31, 14 January 2018 (UTC)

Masking

  1. Should the M prefix be added to all existing icons like   (hSTRc1) (with mask), per   (hSTR+hc1) (no mask) and   (hkSTRc1) (no mask)? About 22 + 54 diagrams out of 139 (54.7%; including user pages) on enwiki might have uses that require masking.
  2. If those icons are renamed, should icons without masks be uploaded under their current titles?
  3. Should the l prefix be added to all icons like  (MSTR2) , per   (hMSTR) and   (lhMSTR)?

Jc86035 (talk) 10:13, 21 January 2018 (UTC)

Perhaps the solution would be to fix the icons that have embedded masking, and the create stand-alone mask icons (which would then no longer have a need for the l prefix). Useddenim (talk) 13:34, 21 January 2018 (UTC)
If you're referring to the elevated corner icons, I think it would be better to have JJMC89 bot manually replace all uses of the originals after uploading the new icons with masking, and only then re-upload the original icons without masking. What do you mean by "which would then no longer have a need for the l prefix"? (For what it's worth,   (lhSTRc1) doesn't have masking.) Jc86035 (talk) 13:42, 21 January 2018 (UTC)

Multi-part icon names

I just renamed   (mvÜST-ÜST yellow+sky) to   (vÜST yellow-ÜST sky) based on   (vSTR saffron-ENDEe azure) and   (vfmKRZu-umKRZu). Issues:

  1.   (vSTR+4-STR azure) causes a naming conflict, since this would also be a valid name for   (vSTR+4-) +   (v-STR azure). Solutions include naming that hypothetical icon vSTR+4 -STR azure (with a space to indicate the default set), naming the hypothetical icon vSTR+4-STR +azure (this would affect the other aforementioned icons), naming the existing icon vSTR+4 azure-STR azure (this would probably affect   (uvSTR+4-STR) as well), naming the hypothetical icon vSTR+4-(STR azure), or naming the existing icon (vSTR+4-STR) azure. I would prefer the first of those, especially as there would be many valid and equally arbitrary ways to place brackets.
  2. Does   (vSTR+GRZq azure) need to have azure before +GRZq (per the above, since it doesn't apply to the GRZ part), or should it stay as it is (per   (SKRZ-Ao denim))? I would prefer the former since it's syntactically different because of the +, although there's   (SPLa+vBHF) (which I think would be named BHFSPLa per § Using tildes).
  3.   (SPLe+vCPICl), if renamed to XBHF-LSPLe per § Using tildes and Another CPIC renaming scheme, could be interpreted as parallel lines syntax, and could be interpreted as being one side of SPLe if renamed to XBHFSPL-Le. Maybe XBHF-L'SPLe?

Jc86035 (talk) 07:20, 13 January 2018 (UTC)

  • Concerning issue 1, I think that   (vSTR+4-STR azure) does not cause a naming conflict: According to what we’ve been renaming multi-color multi-line icons, the compound   should be named mvSTR+4-STR +azure, while, say,   should be named mvSTR+4-STR azure+.
Concerning issue 2, no: GRZ’s color is inherent and azure does’t apply to it.
-- Tuválkin ✉ ✇ 23:43, 14 January 2018 (UTC)
  • @Tuvalkin: Concerning 1, this still crops up in cases where m isn't used like   (veBHF-uBHF) (and veBHF-BHF azure would result in a conflict). I'm not sure if   (vSTR saffron-ENDEe azure) is correct now but I think it probably is since I moved it back after moving it to   (mvSTR-ENDEe saffron+azure) last year (I don't remember why). Concerning 2, shouldn't the + indicate that all affixes need to be applied twice if applicable to both parts (e.g.   (fvHST-+fexv-HST), where f is applied twice)? Jc86035 (talk) 05:58, 15 January 2018 (UTC)
  • In cases such as   the m preffix always should be used, even in icons such as  , the latter with appended color names, separated by a space and connected by a +. Disjunct color names are only to be used when an icon name is made up of two fully independent names, separated by a +; this kind of names should be used only when there is no better alternative; for the cases above, we have:
iconperfectacceptablewrong
 not possiblemveBHF-L-BHF-R
veBHF-L-+u-BHF-R		veBHF-uBHF
 mvSTR-ENDEe saffron+azurevSTR- saffron+v-ENDEe azurevSTR saffron-ENDEe azure
 not possiblefvHST-+fexv-HST
 not possiblefvHST-L-+fexvHST-RfvHST-exHST
This (the part concerning colors, not the double station name issue) is not my own suggestion or opinion right now, it is what we decided upon back when the “other colors” mess was clared. (And, yes, all this would be much simpler if my suggestion of using brackets and not spaces for color names had been approved back then: I told you all so.) -- Tuválkin ✉ ✇ 05:26, 22 January 2018 (UTC)
@Tuvalkin: Would   (vumKRZu-fmKRZu) with red (driver's right), blue (driver's left) and green (across) be mvmKRZu-mKRZu red+green+blue+green? Does it need an m before the v? (I think the mv… a+b structure is good, though it seems a bit awkward to scale it to the various valid and possible edge cases like these hypothetical ones.) Jc86035 (talk) 09:53, 28 January 2018 (UTC)
I agree with both your name suggestion and with your assessment of it — but after all it’s expectable and even virtuous to have awkward names for awkward icons: Anything else would mean that the naming systemn doesn’t meet the needs. -- Tuválkin ✉ ✇ 13:30, 28 January 2018 (UTC)
@Tuvalkin: In the table, couldn't the last two be fvHST-exHST (after replacing current uses) and fvHST-L-exHST-R?
If the aforementioned four-colour name is correct, then   (vumKRZu-fmKRZu) would become ufvmKRZu-mKRZu (this would probably be correct per   (ugKRZo))? Or would it be mvmKRZu-mKRZu u++g+ (this would probably also be correct per   (ABZr+mr +f))?
Concerning (2),   (WGRZ) does sort of imply that we could change the GRZ colour, so it might be better to use + unambiguously, to replicate an overlay of the adjoining parts (STR azure!~GRZq = STR azure+GRZq). Jc86035 (talk) 15:00, 28 January 2018 (UTC)

Parallel lines – one side

Should icons like   (vSTR2-R) and   (vSPL1+r-L-L) also have their -L and -R suffixes changed, per STR-L →   (STR~L)? I think using -l and -r, :l and :r, or :L and :R would work. -f and -g, or ~f and ~g, could also be used for the current "move the primary object along the line" uses of f and g; e.g.   (tSTR2ef) → tSTR2e-f (and one of the unused pairs, or ~l and ~r, could also be used for icons like   (BHFlf)). We could also start using more Unicode characters, though this might not be desirable and would probably be unnecessary. Jc86035 (talk) 10:53, 28 January 2018 (UTC)

Tildes

What are the rules for using the tilde suffixes, anyway? I'm having trouble figuring out exactly how they're supposed to work. I've renamed most of the -L/-R transform icons to ~L and ~R, except for some of the half-width icons (to parallel lines) and the ones where -L or -R might be incorrect (like   (vSTR-L), which I moved to   (vvSTR-STR-) – would it be more correct to name it vvSTR~L or something like that?). Do the ~L/~R/~F/~G suffixes always move an object to the icon edge (or the edge of the parallel lines syntax border)? Would   (dBHF~R) be different to dv-BHF, the latter of which might presumably have the small station circle of   (dBHF)? Jc86035 (talk) 11:04, 28 January 2018 (UTC)

I've also just realized that ~L and ~R currently contradict the ~F uses (as well as the directions of the +L, +R, +F and +G transforms), and that it might be better to move all of them back and then swap them. I'm reverting the ~L and ~R moves for now. Should they be swapped (i.e.   (STR-L) would become STR~R)? Jc86035 (talk) 11:39, 28 January 2018 (UTC)
I don't know that we formulated any rules for the use of ~ in icon names. I just used it (in files like   (exdpBHF~R ruby) and   (mv-BHFSHI2r~exBHFSHI2r fuchsia~maroon)) because I needed a name that wouldn't conflict with anything else. However, I do like the idea of defining it as move an object to the edge, and restricting -L/-R/-M to connecting to left/right/middle. Useddenim (talk) 16:57, 28 January 2018 (UTC)
If ~ is defined as “against an edge”, then it does make sense to use it as the divider between that halves of bi-coloured icons. Useddenim (talk) 18:51, 28 January 2018 (UTC)
Whatever is decided, the icons in Category:Icons for railway descriptions/half width/parallel lines/stations and stops/BHF/halved should probably also be included. Useddenim (talk) 18:51, 28 January 2018 (UTC)

SKRZ

@Useddenim and Tuvalkin: Since this is more easily doable with pywikibot now, could SKRZ-G1/G2/G4/GD be renamed to SKRZ-P1/P2/P4/D for consistency with the original roots? This could avoid issues/confusion arising from somewhat ambiguous names like SKRZ-G2+4. Jc86035 (talk) 16:18, 9 February 2018 (UTC)

  • If «there are a few icons which need to be added to the catalogue pages», then the catalogue pages do not suffice. Besides, this catalog, “unofficial” as it is, is much more readable and compact. I’ll try to keep it current. -- Tuválkin ✉ ✇ 15:59, 12 February 2018 (UTC)

RP2 divided curves

Moved to Talk:BSicon/Renaming/Roads#RP2 divided curves
23:46, 31 July 2022 (UTC)

BS2

@Useddenim and Tuvalkin: Assuming that the BS2 shift icons will eventually be renamed, how should   (BS2rxl) and   (eBS2lxc) be renamed based on the existing SHI syntax? Would there have to be +c2 and +c3x2/+xc2, making them inconsistent with   (eBS2l) (which would be xSHI2l)? Would we replace the c suffix? Jc86035 (talk) 08:37, 29 November 2017 (UTC)

  •   (BS2rxl) → SHI2rxl+c2 and   (eBS2lxc) → xSHI2l+xc3. These icons have three features (the shift(s) + 2 corners), so of course they're not going to be consistent with the simpler icons. Useddenim (talk) 11:27, 29 November 2017 (UTC)

@Epicgenius: Other than this one, the most recent discussion is here. All the elevated icons have already been renamed (most recently by me). The only pertinent concern is the German Wikipedia's Bilderkatalog, which appears to be universally seen as a design guideline (i.e. avoid bells and whistles like CONTs, 3-curves and parallel lines) but is stated to be a list of the (only) BSicons allowed in dewiki diagrams. Since it doesn't include any shifts other than the BS2 icons, the SHI1–4 icons aren't seen as canonical, and no one has ever renamed any of the BS2 icons because SHI2 is an ugly English-based root with a false suffix or something like that (I don't really remember at this point). However, I don't know if this really matters any more, since there have been so many Bilderkatalog icons which have been renamed without asking dewiki users (e.g.   (ABZgl),   (KDSTeq)). I first asked about the BS2–SHI2 discrepancy in September 2015, and the renaming was first proposed at Talk:BSicon/Renaming/SPL a few years earlier. Jc86035 (talk) 10:01, 17 February 2018 (UTC)

@Jc86035: It's not “an ugly English-based root”, as German uses the same sound in „Verschiebung”. Useddenim (talk) 04:51, 20 February 2018 (UTC)
@Useddenim: Thanks; I didn't know that (or maybe I forgot about it). Jc86035 (talk) 05:00, 20 February 2018 (UTC)
@Jc86035: Thanks for the link. On a slightly unrelated note, you said the Bilderkatalog contains "a list of the (only) BSicons allowed in dewiki diagrams". Does that mean icons not on the Bilderkatalog can't get used at dewiki? Was there a discussion there? epicgenius (talk) 01:18, 18 February 2018 (UTC)
@Epicgenius: I suppose it's just the way it's always been (I haven't bothered reading their talk page archives to find out), and it was probably quite sensible in the old days when the naming rules were less internally consistent and icons were more often uploaded with wonky geometry (though I wasn't around then). The Bilderkatalog is often ignored, sometimes so that conveniences like   (dSTRl+4h) can be used (since there still isn't an overlay function, it's not possible to have something like c!~v-SHI2r\STRl); sometimes to use KRW and kSTR icons; sometimes because editors have copied diagrams from other Wikipedias. Apparently there have been a bunch of conservative users who have refused anything like the addition of overlay (and, of course, the abolition of the Bilderkatalog) for years. Most of the time diagrams do look consistent, though. Jc86035 (talk) 07:53, 18 February 2018 (UTC)

Another CPIC renaming scheme

Since the last one was more than a year ago, I'd like to propose that all CPICs become XBHF, all CPICAs become XACC, and so on. There are currently no BSicon roots (or BSicons) beginning with uppercase X. (Alternately uppercase I could be used.)

  •   (heCPICl) → hXBHF-Le
  •   (CPICAa) → XACC-Rq
  •   (CPICKl) → KXBHF-Feq
  •   (utCPICCCle) → utXBHF-Lef
  •   (xCPICma) → KXBHF-Mxa
  •   (CPICqq) → XPT*
  •   (CPIClg) → XPT+r*
  •   (CPICdd) → XPTe*
  •   (CPICpassu) → STR+XPTq*
  •   (uexCPICpasso) → XPTq+uexSTR*
  •   (CPTa) → TXPTa

XBHF etc. would use standard -L/-M/-R/q/xa/xe suffixes instead of the current l/m/r/(a and e)/(x prefix + a)/(x prefix + e).   (tCPICCCle) would probably become tXBHFCC-Le or something like that until we decide on how to rename the KBHFCC icons. Jc86035 (talk) 10:19, 9 January 2018 (UTC)

* It just so happens that   (CPICqq) is about the same width as   (BSm), so PT could be reused if we want to rename the platforms as well. Jc86035 (talk) 10:19, 9 January 2018 (UTC)

@Tuvalkin and Sameboat: ✓ Done (about 511 icons renamed). Outstanding issues include suffix order of -L/-R/-F/-G vs. a/e (I think it would be more correct to swap the suffix order for all of the terminal station icons) and whether   (exXBHFSHI1lr-M) needs to have an extra e/x in the middle (I don't think so, since it would be confusing and this particular icon can be split into parallel lines, but others may think it needs to). Jc86035 (talk) 10:23, 28 April 2018 (UTC)

Crossings?

@Useddenim and Tuvalkin: Could   (uCROSS),   (gSKRZ-YuEnd) and other similar icons be converted into a standard set of crossings? I would probably assign a suffix to indicate that a line has a break, perhaps uCROSS → ugKRZB (or another suffix).

The issue of assigning more capital prefixes and suffixes is that at some point they'll end up conflicting with roots (there's already DST = embankment + road crossing railway, although this doesn't exist and should be extremely rare), so it could be time to expand into Unicode. Jc86035 (talk) 11:15, 25 February 2018 (UTC)

@Jc86035, Bob1960evens, and Zin92: :
  • Converting: I’m all for homogenizing the filenames, but it’s better to first ascertain what are these icons being used for. If it’s mere crossing and the gap is only a visual aid, then they should be redrawn to match all the standard crossings like   (mKRZo), or even   (mKRZ), and renamed trivially. If the gap is meaningful (filled up canal with road running across), then a renaming is in order but also a homogenous redrawing. (For the latter I suggest something like  , which doesn’t include the crossed line — reducing the number of needed icons.)
  • Renaming: I agree with adding an uppercase prefix or suffix. The ambiguity issue raised above can be solved (or significantly reduced) if all icon roots are made of exactly three letters (not two, not four). Unicode (meaning non-ASCII Unicode) is a possibility, but seeing how people still have difficulties with "Ü" as if this was the 1970s, we should be wise to avoid more of these.
-- Tuválkin ✉ ✇ 12:48, 25 February 2018 (UTC)
@Tuvalkin: I agree with your points, though an issue with using lENDEf/g might be if two of the icons are used in a row. Renaming CONT, ENDE, SHI(1–4), etc. might be seen as unnecessary but since almost no one took notice of the proposed wide-ranging CPIC renaming above (and I advertised it in multiple locations on enwiki), it might not really be an issue. Jc86035 (talk) 05:28, 26 February 2018 (UTC)
current suggested
  (uCROSS)   (umgGAP)
  (gSKRZ-YuEnd)   (gGAPSRYq)
  • Okay, both have been redrawn. Lets go back to a renaming discussion: I think we can agree that this kind of crossing (or rather, a non-crossing!) is distinctive enough to have its own iconID. While akin to bridges and regular crossings (and even though it’s likely that there will be a much smaller number of icons involved here), in this feature the “broken” line should be always secondary, so there’s synonimity issues concerning u/o vs. -/q. For the icon ID I suggest GAP, a nice descriptive 3-letter word, even if it’s not German. -- Tuválkin ✉ ✇ 15:32, 29 April 2018 (UTC)
current suggested
  (uCROSS)   (gGAPq+uSTR)
  (gSKRZ-YuEnd)   (gGAP+RYq)
  • New idea: The gap is the feature, and it can even be standalone — compare   (GAP) and   (GAPq). An unbroken line may go through the gap as an overlaid   (STRq) (or   (STR)), either in a diagram or as a new icon — see the 2nd table. -- Tuválkin ✉ ✇ 16:10, 29 April 2018 (UTC)
@Tuvalkin: ENDEea (from   (tSTRea) = tSTReg + tSTRaf; ENDEea would be equivalent to ENDEe@G + ENDEa@F under new schema)? Jc86035 (talk) 17:19, 29 April 2018 (UTC)

Beta what?

@Jc86035: I came across   (hvSTR3- β) and   (hv-STR+1 β), wich were moved from the more usual   (hvSTR3-) and   (hv-STR+1) two years ago; the redirects were deleted recently. What’s this? -- Tuválkin ✉ ✇ 20:08, 6 April 2018 (UTC)

I say "Just move them back". Useddenim (talk) 11:57, 7 April 2018 (UTC)
@Useddenim and Tuvalkin: This was because of   (hv-STR3 β), which I renamed last September so I could upload   (hv-STR3). Since the geometry type is probably never going to be used (predating YLSS's 2014 geometry change), and the filenames were both valid under the current naming conventions, I moved the other two as well in case someone wants to upload the icons. In the current naming scheme the icons for the curve in the ptwiki diagram would probably be hvSTR3, hvSTR3+L, hvSTR3+R, hvSTR+1, hvSTR+1+L, hvSTR+1+R, and two masks. Jc86035's alternate account (talk) 13:13, 7 April 2018 (UTC)
@Jc86035 (1): Thanks for explaining. Lets rename those icons properly, then? The fact that they are used in a diagram should be proof that they are needed. -- Tuválkin ✉ ✇ 02:49, 9 April 2018 (UTC)
@Tuvalkin: It turns out that with the proposed/de facto use of ~L and ~R (see #Suffixes and #Tildes) they all have perfectly valid names under the current system, so I've renamed all of them. They still need to be reuploaded (for narrow formations and 117.85px parallel lines spacing). Jc86035 (talk) 12:06, 29 April 2018 (UTC)

Suffixes

@Useddenim, Tuvalkin, Sameboat, Lost on Belmont, and Newfraferz87: @Axpde and C21H22N2O2: I spent some time thinking about how to separate the various meanings of L, R, F and G suffixes, and this is what I came up with. It's not perfect, and the suffixes could be changed to clearer or more readable ones, but I think it's better than the somewhat arbitrary mess that we currently have. There are almost 100,000 BSicons now (of which almost all have fairly simple names and are validly named to be consistent with current naming conventions), and the current system does limit us in terms of the combinations of features that an icon can have, and how specific the suffixes can be. This would solve various issues, such as   (hSTR-R) vs.   (uhSHI1+l-R), and the myriad naming issues in finding a good name for   (uhBHFrf) which is consistent with other icons.

  • l, r: curves (STRl)
  • f, g: forward and backward arrow indicators (STRf)
  • L, R, F, G: reserved for prefixes
  • +L, +R, +F, +G: full transform of the icon boundaries in the respective direction (hvSTRa+L) [No pattern] [NOT AFFECTED BY PARALLEL LINES SYNTAX]
  • +l, +r, +f, +g: line connecting from respective direction (STR+l) [Pattern: +lf]
  • ~L, ~R, ~F, ~G: transform all objects from centre of icon to respective icon boundary (lBHF~F, currently lBHFf) [Pattern: ~LF] [NOT AFFECTED BY PARALLEL LINES SYNTAX]
  • ~l, ~r, ~f, ~g: only this side of the primary object(s) is shown (vSTR2~l, currently vSTR2-L / utvSTRa@g~g, currently utlvSTRag) [Pattern: ~lf (¾) or ~l~f (¼)]
    • A halved track is STR~ or ~STR. Somehow, this magically avoids naming conflicts.
  • @L, @R, @F, @G: transform secondary object(s) in respective direction relative to the line or other primary object (lvINT@F-, currently lvINT~f-) [Pattern: @LF]
  • @l, @r, @f, @g: transform auxiliary object(s) in respective direction relative to the line or other primary object (tSTR2a@f, currently tSTR2af / tBHFa@f, currently tBHFaf) [Pattern: @lf]
  • -L, -R, -F, -G: secondary object connection in respective direction (BHF-L) [Pattern: -LF]
  • -l, -r, -f, -g: auxiliary object connection in respective direction (tSTRa-l, currently tSTRal) [Pattern: -lf]
  • (L), (R), (F), (G): only this side of the secondary object(s) is shown (BHF(L)f, currently BHFlf / KRZo(L), currently KRZo-L) [Pattern: (LF) (¾) or (L)(F) (¼)]
  • (l), (r), (f), (g): only this side of the auxiliary object(s) is shown (lhSTR(l), currently lhSTR-L) [Pattern: (lf) (¾) or (l)(f) (¼)]

A somewhat related issue is that icons like   (KBHF-La) would probably appear to have an incorrect suffix order, especially after renaming a bunch of others, and might need to be renamed to KBHFa-L. Maybe this should be done. I'm not sure. Thoughts? Jc86035 (talk) 06:29, 27 April 2018 (UTC)

  • I'm strictly against those "~" or "@" suffixes, because the icon names should be understandable by general public! The names have become incomprehensible enough, so please no more confusion :-( a×pdeHello! 08:44, 28 April 2018 (UTC)
And Your example   (KBHF-La) should indeed be KBHFa-L :-) a×pdeHello! 08:45, 28 April 2018 (UTC)
  • @Axpde: Do you have any better suffix suggestions? There are already icons using ~L and ~R suffixes, and I don't see how they are less comprehensible than -L or -R. I suppose we could use suffixes like .L/.R or ,l/,r instead? Jc86035 (talk) 09:25, 28 April 2018 (UTC)
Connector
 Suffix
L R F G l r f g (none)
  (none)

not used

l/r: curves   (STRl)

regular icons

f/g: directionals   (STRf)
+ transforms icon in direction   (hvSTRa+L) connects from direction   (STR+l)

not used

~ transform objects from centre to boundary   (lBHF~F) half of primary object   (vSTR2~l)
  (utvSTRa@g~g)		 halved track   (uSTR~)
@ transforms secondary in direction wrt line/primary   (lvINT@F-) transforms auxiliary in direction wrt line/primary   (tSTR2a@f)
  (tBHFa@f)

not used

- secondary connects in direction   (BHF-L) auxiliary connects in direction   (tSTRa-l) single parallel line   (vSTR-)
( ) only part of secondary shown   (BHF(L)f)
  (KRZo(Ll))		 only part of auxiliary shown   (lhSTR(l))

not used

Useddenim (talk) 01:37, 30 April 2018 (UTC)

@Useddenim: By "halved track" I meant something like half of   (mSTR yellow~exteal), specifically for situations like   (uehbnvÜSTl) where currently the narrow track has to shift back to the centre even though the icon is paired with   (uehbnvSHI4gr). Now I'm not sure whether this means objects on the track would be halved [edit: they probably wouldn't, since this schema also includes suffixes for that purpose]. Jc86035's alternate account (talk) 15:02, 2 May 2018 (UTC)
Wouldn't ICON~nothing mean “halved icon”, as in   (uBHF~)? Useddenim (talk) 17:48, 3 May 2018 (UTC)
@Useddenim: I thought it would work like that at first, but we might also want to have, for example, a station centred on the half of the line, and it wouldn't make sense for ~HST on its own in a diagram to have half of a station circle; or we might want to extend the system logically for e.g. mINT u~grey~orange with the lines being 150px wide in total (allowing this would in turn require something like a mSHI.2+r u~grey to shift the driver's rightmost two lines back to the middle, and then we would probably have to extend SHI to diagonals). Jc86035's alternate account (talk) 08:15, 4 May 2018 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Talk:BSicon/Renaming/Archive_11&oldid=862123598"