Talk:BSicon/Renaming/Archive 13

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

Rename hKRZWaeq and similar

With the advent of WKRZ, these can often be titled WKRZhlr, instead of depending on q for quarter turn / across / quer. This is a systematic change, affecting icons from the standard and other color sets. The common, more general naming practice of icons revolving around KRZ root is to focus on the through line for naming and reserve q for exotic cases: observe abscence of q with the name pair   (mKRZo) /   (umKRZu) - with KRZW and WKRZ this is extendable to (unnavigable) water crossings. Historically there was WBRUECKE which obscured a more generalized view now apparent with WKRZ.

A benefit will be greater similarity/predictability of name patterns for canal (navigable, set u) and unnavigable water icons, which will allow building water-related route diagrams more easily in the long run. --91.55.164.1 12:37, 16 July 2021 (UTC)

NO! The h prefix/suffix is specifically for formations at 125 and 375 px. (See   (hKRZho) et al.)   (KRZo) etc. icons use the smaller   (BRIDGE) formation. (Note the difference to   (lhSTRae).) AlgaeGraphix (talk) 00:11, 28 July 2021 (UTC)

~RRR and ~LLL suffix

  (hdvBHF~RRR) and   (hdvBHF~LLL) seem to have questionable names. Besides the fact the l (legend) prefix is missing, I don't think there's any definition of a triply-repeated letter. Per BSicon/Catalog#Suffix modifiers, I believe these should actually be named   (lhdBHF+R) and   (lhdBHF+L) (based on   (lhBHF) and + transforms icon in direction so that the auxiliary object is at the icon edge; the example shown is   (hSTR) →   (lhSTR+R)). @Jc86035: ? AlgaeGraphix (talk) 23:56, 27 July 2021 (UTC)

@AlgaeGraphix: The usage of l is consistent with other formation icons; where the l prefix would make no difference, it is usually omitted. In   (lhSTR+R), the side of the formation is aligned with the side of the icon, and doesn't match up with other formations. This isn't the case for the actual station formation icons.
In   (hdBHF~RR), the centre of the station icon is a full icon width (250px, so 100%, since it's a half width icon) to the driver's right measured from the centre of the image, and ~R means transformed to the right by half an icon, so ~RR is used. In   (hdvBHF~RRR), the centre of the station icon is one and a half icon widths (375px, so 150%) to the driver's right measured from the centre of the image, so ~RRR is used.
Most of the icons like this are linked in the icon descriptions of BSicon/Catalogue/parallel stations (in the "use with" notes). Jc86035 (talk) 07:11, 28 July 2021 (UTC)

Unexpected nonexistant icon

If   (hSTRae) exists, why doesn’t   (hvSTRae) exist, not even as a redirect? -- Tuválkin ✉ ✇ 10:24, 2 November 2021 (UTC)

✓ Done. Useddenim (talk) 17:39, 3 November 2021 (UTC)

hvSHI2+r(l)- vs. vSTR+4-~F

Moved from Talk:BSicon/Renaming/SPL

  (hvSHI2+r(l)-) and   (vSTR+4-~F) are the same icons with the former being elevated but with totally different names and on different pages (BSicon/Catalogue/parallel crossings and crossovers vs. BSicon/Catalogue/parallel 45° branchings). Same with other related icons. They should be renamed for consistency and put on the same page. Xeror (talk) 17:25, 16 January 2022 (UTC)

Renaming for Roads Needed

Moved to Talk:BSicon/Renaming/Roads#Renaming for Roads Needed. Useddenim (talk) 23:23, 31 July 2022 (UTC)

Crossings

One (or more) IP editor(s) suggested (if I correctly interpret their screed) that short-form mixed crossings (  (mfKRZ),   (uKRZWu), et al.) be changed to follow the same scheme as mixed colours; i.e.   (mfKRZ)→(KRZ +f),   (uKRZWu)→(KRZu u+WASSER), etc. Useddenim (talk) 12:26, 15 March 2022 (UTC)

Discussion

Redirects are possible, adn people who think they’d rather use those alternate filenames instead, should go ahead and create those redirects. The old names with m and such, should not be made unusable, of course. -- Tuválkin ✉ ✇ 15:25, 25 March 2022 (UTC)

A better name for ulpBHF icon

File:BSicon ulpBHF.svg

I think this icon has to be renamed because it is not coherent with icons

  •   (lpHST),
  •   (exlpHST),
  •   (ulpHST) and
  •   (uexlpHST).

ZandDev (talk) 17:04, 9 April 2022 (UTC)

I realized that the problem described above does not exist. 18:34, 9 April 2022 (UTC)

Roads

Road-related discussions now have their own page at Talk:BSicon/Renaming/Roads. Useddenim (talk) 15:13, 1 August 2022 (UTC)

Interchanges

I think I've figured out a rational naming scheme for the motorway interchange icons; please comment at Talk:BSicon/Renaming/Roads#Motorway interchanges. Useddenim (talk) 15:13, 1 August 2022 (UTC)

Non-ASCII characters in BSicon name

The icons   (lNULWYEBHFgr+r⟳) and   (NULWYEBHFgr+r⟳) end with the non-ASCII mathematical symbol ⟳. I don't believe this is appropriate, but I don't really understand the BSicon naming conventions fully enough to suggest a replacement name, but I think it would be good to get this name fixed. VanIsaac (en.wiki) 18:42, 26 February 2023 (UTC)

See Talk:BSicon/Renaming/Archive 12#Fractional shifts. Useddenim (talk) 19:52, 26 February 2023 (UTC)

Page need updating to reflect correct icon names

On BSicon/Catalogue/formations,   (lhvSTR-Rq) &   (lhvSTR-Lq) should be changed to the correct names   (lhvSTR(r)q) &   (lhvSTR(l)q) (I don't know how to change it on that page). -- ThylacineHunter (talk) 09:55, 2 May 2023 (UTC)

Also need to change   (vBRIDGEv) to it's correct name   (lvMKRZvo). -- ThylacineHunter (talk) 10:00, 2 May 2023 (UTC)

Right icon names needed

I created   (utKRZ3tul+4) and k versions of   (uKRZ3ukl+4) &   (utKRZ3tukl+4). I based what I think the name would be on   (KRZ3ul+4), but I am absolutely not sure as it's getting a little confusing. Would someone be able to confirm/fix the files with the right naming convention?  - oahiyeel talk 13:10, 8 May 2023 (UTC)

@Oahiyeel: They are named correctly. Also, the convention has been to use a ! suffix to indicate that an icon is experimental. Useddenim (talk) 17:57, 9 May 2023 (UTC)
I see, thanks!  - oahiyeel talk 05:18, 10 May 2023 (UTC)

"e" and "x" prefixes for double-width forks

I'm looking at   (bSHI2rxl)/  (ubSHI2rxl),   (bSHI2lxr)/  (ubSHI2lxr),   (bbSHI2+rxl)/  (ubSHI2+rxl) and   (bbSHI2+lxr)/  (ubSHI2+lxr), and I'm wondering why those shouldn't be named with the "e" and "x" prefixes for   (bSHI2lr) and   (bSHI2+lr), considering that   (exbSHI2lr) and   (exbSHI2+lr) are valid (along with their "u" versions). Am I completely off base here that those would be far more intuitive names? Is there some hidden reason behind   (ubSHI2lxr) and   (ubSHI2rxl) for a single out-of use track instead of   (uebSHI2lr) and   (uxbSHI2lr) when   (uexbSHI2lr) for both tracks being out of use is valid? VanIsaac (en.wiki) 21:07, 14 May 2023 (UTC)

@Vanisaac: x indicates the primary route is out of use, and e indicates the secondary route is out of use. For the bSHI2 icons, because the branches mirror each other they are considered equal and there is no primary and secondary route. ex is valid because everything is out of use. Useddenim (talk) 21:55, 14 May 2023 (UTC)
That is not followed by the through and 90° curve icons, double curves, shift and curve, etc. which pretty clearly indicate the "e" prefix for the right line and "x" for the left:
  e x ex t et xt ext u ue ux uex ut uet uxt uext
vSTRr-STR                                 to right – straight
vSTR+r-STR                                 from right – straight
vSTR-STRl                                 straight – to left
vSTR-STR+l                                 straight – from left
Double curves
vSTR+r                                 from right both
vSTRl                                 to left both
vSTR+l                                 from left both
Shift and curve
vSTRr-SHI1r                                 turn to right – shift to right
vSTR+r-SHI1+r                                 turn from right – shift from right
vSHI1l-STRl                                 shift to left – turn to left
vSHI1+l-STR+l                                 shift from left – turn from left
Mixed
mvSTRr-SHI1r                                 turn to right – shift to right
mvSTR+r-SHI1+r                                 turn from right – shift from right
mvSHI1l-STRl                                 shift to left – turn to left
mvSHI1+l-STR+l                                 shift from left – turn from left
  e x ex t et xt ext u ue ux uex ut uet uxt uext
A bunch of these were named that way by you over the course of several years around a decade ago. If the "rules" for BSicon names are utilitarian, and not simply rules for rules' sake, then I am having a lot of trouble with why this pretty simple convention shouldn't be applied to forking icons. If it's a question of formalizing the convention, then let's do it. Formalized or not, we are already using this convention, why not do it right? VanIsaac (en.wiki) 04:22, 16 June 2023 (UTC)
@Vanisaac: You're trying to compare apples and oranges. The forks are single-line icons, whereas the new examples you cite are for parallel lines. And yes, I named them, following conventions that were already in place (although I never understood why the left line was considered primary and the right secondary). But by all means go ahead and draw up a formal proposal for consideration. Useddenim (talk) 08:53, 16 June 2023 (UTC)

Category:BSicon/railway/stations and stops/express

Moved to Talk:BSicon/Categorization#Limited
18:05, 26 July 2023‎ (UTC)

Two-colored BSicons with ~ in name

Moved from User talk:Tuvalkin

Dimlys1994 has been adding icons such as   (mINT-L green~yellow). In the past when I've wanted to illustrate that situation I'd use overlays  (lINT-L※ udBHF~L※ BHF) . Any thoughts about the correctness of this naming, and/or alternative suggestions? Useddenim (talk) 14:00, 25 August 2023 (UTC)

(Not to mention the geometry of things like   (mSTR+l~STR ruby~yellow).) Useddenim (talk) 14:05, 25 August 2023 (UTC)
@Useddenim: I’m totally against that kind of two-color lines, for the same reasons I’m against half-width lines and more! -- Tuválkin ✉ ✇ 15:24, 25 August 2023 (UTC)
Notwithstanding, I think   (STR yellow+uKRW+r~r) correctly describes this icon? (And the example above could be   (STR ruby+STR+l~l yellow)). Useddenim (talk) 02:18, 24 September 2023 (UTC)
I think your approach to filenaming of these is much better and matches existing convention. But I think it’s eitherway flimsy, even if yours is the best possible naming scheme, as it still could/will easily break apart for more complex arrangements as where the cleaving between the two colors goes is unclear from the name. In my opinion, this happens because the naming system rests on the notion that segments of a line are only to be divided across the running direction, not along it (and that’s how it makes sense to have these diagram elements at all).
In general things like this   make no sense to me — two color stations should be shown as   (see the well known discussion about diagrams of tracks v.s diagrams of services). Afterall, if   is acceptable instead of  , how to use this approach to convey what can be easily shown as, say,  …? Just slice it in three parts to have three colors sharing the same line!? The naming of that sort of icon, envolving two ~s, would be the least of the problems it would bring. And if it doesn’t work for three or more colors, then it should not be used for two.
In my opinion, since you ask, mixed-color icons should be either for things like  , showing parallel lines, or things like   or even  , showing a transition in the charactericstics of a line orthogonally to its running direction. Things like   are just nonsense waiting to breed more nonsense.
But with all this feverish activity going on, the cat is out of the bag. The people behind this will need to run their train to a crash halt themselves, before having to stop and remake it all properly. (Or more likely, rather having to stop and then vanishing away from BSicons to go mess up something else, leaving the clean-up job for us.)
-- Tuválkin ✉ ✇ 10:25, 24 September 2023 (UTC)
@Tuvalkin: see {{Athens Metro Line 3 RDT}} and {{Athens Suburban Railway RDT}} for a better solution using c-width icons. Useddenim (talk) 19:32, 24 September 2023 (UTC)
Still wrong, but at least doesn’t inflict fundamentally flawed icons (and the issue of their naming) on us. -- Tuválkin ✉ ✇ 19:54, 24 September 2023 (UTC)

Question before I upload

Apologies for this being not quite on-topic, but I figured this would be a decent place to ask before I upload a variation of a previously uploaded icon.

I have   (mhbvHST-STR orange+) already uploaded, but if I wanted the station closed (both lines still open,) would mhbveHST-STR orange+ be the correct prefix order? I try to mimic other icons that pop up in the search bar so as not to upload them incorrectly, but there appear to be no similar ones this time.

Again, I already have the image prepared, but I just wanted to inquire before possibly finding a wrong way to do it. Thanks. Hotdog with ketchup (talk) 06:00, 2 October 2023 (UTC)

Yes, that is the correct name. Useddenim (talk) 14:06, 2 October 2023 (UTC)
Okay, but why not have this as two separate icons?, like this  … -- Tuválkin ✉ ✇ 04:39, 30 October 2023 (UTC)
The   (mhbveHST-STR orange+) icon has already been implemented, but I will keep this in mind in the future, thank you.
(To be fair, I am not a big fan of multicolored icons either and I try to limit my use of them to where they appear necessary, after failing to achieve a practical goal with stacked icons.) Hotdog with ketchup (talk) 05:36, 30 October 2023 (UTC)

2SHI2

@Useddenim: Just checking, is there a special meaning for the "a" and "e" suffixes for icons like   (2SHI2la)? They don't seem to be necessary, since the starting or ending point of the curve is already implied by the (+)l/r suffix. Jc86035 (talk) 13:57, 19 February 2024 (UTC)

Yes; because the shift extends over two rows, I figured that the start (upper row) and end (lower) would need to be indicated. If they are superfluous feel free to rename them. Useddenim (talk) 14:02, 19 February 2024 (UTC)
@Useddenim: I've started renaming the icons to remove the a/e suffix.
I wasn't sure what to do with v-2SHI2+re-ABZg2 so I renamed it to   (v-2SHI2+r;ABZg2). If this works then we could establish that if an icon name contains ;, then the root before the semicolon forms the primary shape of the root after the semicolon. This would allow us to rename some other icons with nonstandard names like   (ABZ3+1lr) (which would become STR3+1;ABZgr+l). Jc86035 (talk) 20:22, 19 February 2024 (UTC)

TBHF

Given   (TBHFo) and   (BHF), shouldn't   (TBHFu) actually be TBHFoq (akin to   (BHFq)? Useddenim (talk) 03:39, 24 October 2023 (UTC)

After more consideration, I've found
TBHF – e– x– ex–
–        
–x        
 
TBHF – e– x– ex–
–o        
–xo        
 
TBHF – e– x– ex–
–u        
–xu        
which I think should be properly name as
  (TBHF)   (eTBHF)   (exTBHF)
  (TBHFqxg)   (TBHFxq)
  (exTBHFq)   (exTBHFqg)
etc. Useddenim (talk) 17:28, 24 October 2023 (UTC)
So it looks to me like there was a decision to use "o"ver and "u"nder suffixes instead of the "q"uarter turn suffix when these were originally named. I think it would definitely be good to rename these in accordance with the standard naming scheme. The over/under distinction is too bespoke to really become a legitimate convention to add in to the catalogue naming logic. VanIsaac (en.wiki) 01:12, 25 October 2023 (UTC)
@Tuvalkin? Useddenim (talk) 13:33, 29 October 2023 (UTC)
I’ll have to think about this one. -- Tuválkin ✉ ✇ 04:40, 30 October 2023 (UTC)
I think the current naming scheme makes sense, given that the suffix logic is basically identical to that of the KRZ root (e.g.   (hKRZhu) →   (hTBHFhu),   (exhKRZhu) →   (exhTBHFxhu)). The main difference is that the x suffix is applied to the line across, but h and t are also used as suffixes in this manner for both KRZ and TBHF. Jc86035 (talk) 15:35, 20 February 2024 (UTC)

Correct icon names

I created   (tvSTR+4~l!) and   (tbvSTR+4~l!), based on   (tvSTR+4~l), but couldn't figure out correct naming. Any suggestions? Useddenim (talk) 15:30, 1 October 2023 (UTC)

Don’t they have non-tunnel equivalents? Tuvalkin (talk) 16:52, 1 October 2023 (UTC)
It doesn't appear so. Useddenim (talk) 03:04, 2 October 2023 (UTC)
For the first icon, I think tSTR+4.L would make sense, based on   (STR+4.L), but the line would have to be moved to the left so that it ends at (375,500). I don't think we have any suffix that transforms an object by ⅛ of the icon width.
I've renamed the latter icon to remove the exclamation mark, since it appears to make sense to me. Jc86035 (talk) 11:44, 22 February 2024 (UTC)

Parallel 90° curves

It appears that some inconsistencies between icons with parallel lines 90° curves have been gradually introduced (e.g.   (exvSTR+l~l~R),   (exvSTR+lf-),   (vSTR+lf-)). Given that the .F and .G suffixes have been made official since the last time these icons were discussed, and are probably more appropriate here than the f and g suffixes, I think it might be appropriate to rename and redraw these icons so that they actually make sense logically and functionally. (The f and g suffixes are nominally supposed to indicate the direction of the line in this context.)

There are approximately 1,200 images that would have to be renamed under this proposal, which I would have to do with Pywikibot.

Current icon Proposed name Notes
  (vSTRr) No change
  (vSTRrg-) vSTRr~r
  (v-STRrf) vSTRr~l
  (vSTRrf-) vSTRr.F-
  (v-STRrg) v-STRr.G
  (vSTRo-STRrf) vSTRo-STRr.F
  (vSTRrf-STRlf) vSTRr.F-STRl.F
  (evABZgr) No change
  (ev-ABZgrf) evABZgr~l
  (vSTRr-exABZgr) vSTRr.G-exABZgr.F
  (vABZq+rl) vABZq+r-ABZq+l
  (uvABZqr-) uvABZqr~l It is the left track and not the right track that goes across, so the suffix ~l would be used even though the curve by itself would be uvSTRr~r.

Alternatively, to avoid confusion, this could be called uvABZqr.G-.

  (uvABZql-) uv-ABZqr.G The current icon name is definitely wrong.
  (vSTRr-ABZle) vSTRr-SHI1r;ABZgl We could shorten such icon names by defining that ;ABZ is to be truncated to ;, making this icon name vSTRr-SHI1r;gl. I don't know if this would be an improvement.
  (vABZgrg-ABZgrfo) vABZgr.G-ABZgro.F
  (mvABZg+rg-ABZg+rf) mvABZg+r.G-ABZg+r.F
  (vABZglgu-ABZglf) vABZgl.G-ABZgol.F I'm assuming that the o suffix can modify g. It seems to be very rare, with only about 12 current examples; i.e. other icons in this series, and a few JCT icons like   (utvJCTgol).
  (umvABZr-s2lf+WYErfo) umvSHI2l;ABZgr.G-SHI2r;ABZgor+r.F This would set a precedent for how ; interacts with .F/.G and v. I don't really like the name, but I don't think anything less specific would accurately describe this icon.

This could be shortened slightly to umvSHI2l;gr.G-SHI2r;gor+r.F if the changed definition for ; suggested above is established. This name would be 27 characters long; the original name is 19 characters long.

Jc86035 (talk) 11:25, 22 February 2024 (UTC)

@Useddenim, Tuvalkin: Do you have any thoughts/opinions about this? Jc86035 (talk) 08:53, 23 February 2024 (UTC)

Implementing the new ; connector

Since ; is now listed as a thing on BSicon/Catalogue, it's probably worth taking a look at how it might actually be implemented. Only one icon uses it at the moment.

My instinct is that this would mainly be used for combining various things with ABZg and KRZ, or at least that's what I think I would use it for. As such, I think it might make sense to abbreviate certain icon names in the following ways:

  • Abbreviation 1: STR...;ABZ and STR...;KRZ could be abbreviated as ABZ...; and KRZ...;.   (uKRZ3ukl+4) would become uKRZ3;l+4ku instead of uSTR3;KRZl+4ku.
  • Abbreviation 2: ;ABZg could be abbreviated as ;g, so   (eSHI1lABZg+r) would become eSHI1l;g+r instead of eSHI1l;ABZg+r.
  • Abbreviation 3: ;KRZ could be abbreviated as ; as well, with the possible exception of ;KRZg, since that would conflict with abbreviation 2.   (SHI1+rKRZ3+1t) would become SHI1+r;3+1t instead of SHI1+r;KRZ3+1t.
  • Abbreviation 4: If the element preceding the semicolon connects to the left or right edge (not including corners), then ;KRZg could be abbreviated as ;, so   (STR+uSHI1loq) would become umSHI1lq;o instead of umSHI1lq;KRZgo.
Icons to be renamed
Current icon Proposed name Notes
  (KRZ3or+1) KRZ3;r+1o
  (utKRZ3tukl+4) utKRZ3;l+4ktu
  (ukWKRZl+4) uWKRZ3;l+4ku
  (uetSHI1+lKRZ2+4tu) uetSHI1+l;2+4tu
  (ABZ3+1lr) ABZ3+1;gr+l
  (v-2SHI2+r;ABZg2) v-2SHI2+r;g2
  (vÜSTr3+1) vSTR3+1;ÜSTr The current naming scheme for these icons is flawed, since   (vÜSTl+4) could also mean   (vÜST) in the shape of   (vSTRl+4).
  (SPLag+r) SPLa;g+r ~r could be added to avoid ambiguity about which side the curve connects to, but I don't think this would be helpful in most cases. It probably makes sense to assume that the curve connects to the closer primary line.
  (SPLag+lr) SPLa;g+lr It would not be possible to use ~l or ~r here.
  (SPLal+aq) SPLl+rg Calling it something like SPLar;g+r~lr would technically be possible but I don't think it would be preferable.
  (SPL2+4g azure) SPLg+2;g+4 azure Previously discussed in 2017.
  (vSHI2g+l1- azure) vSHI2g+l;g+1- azure
  (STRq+SPLao) SPLa;o The secondary line for   (KRZ) is already   (STRq), so we probably don't need to specify the secondary line here explicitly.
  (KRZur+12) ABZr+12;o
  (tSHI1rKRZt) tSHI1r;SHI1rq;t The creator of this icon seems to think that this is what KRZ without a suffix should produce, but I don't think this really makes sense since in most cases it creates a non-symmetrical icon that would not have much (if any) practical purpose. If it has to exist, I would use ; to form the icon name instead of + or ≡ so that the KRZ suffixes can still be used; theoretically hSHI1r;SHI1rq;hlr+lr would be a valid icon name.
(Cmuelle8 has a history of creating bespoke and esoteric icons that are extremely unlikely to ever be used. Useddenim (talk) 18:24, 23 February 2024 (UTC))

I don't know if these ideas make sense, so I'll wait to see what others think before renaming anything to use ;. Jc86035 (talk) 17:42, 22 February 2024 (UTC)

Seems to be reasonable; we will just have to learn a little more syntax. However, in some cases it seems that the "abbreviated" name is actually a bit longer. Useddenim (talk) 18:24, 23 February 2024 (UTC)
In most of the cases where the names are longer than the current ones, I think some form of separator is actually necessary because the current naming schemes create ambiguities or make certain icons impossible to draw. Maybe some other change could be implemented for the SPL icons, but it would be hard to introduce other changes without making the syntax even more complicated and esoteric. Jc86035 (talk) 18:34, 23 February 2024 (UTC)

.L/.R/.F/.G and .l/.r/.f/.g suffixes

@Useddenim: Do you have a particular meaning in mind for the .f/.g suffixes as used in icons like   (ldNULfq.g)? It doesn't appear to be functionally different from the .F/.G suffixes in this context. There are apparently 27 icons that use these suffixes; the only ones that aren't directional arrows are ones like   (uvSTR3+1.f) that were uploaded by AlgaeGraphix, and I think those also would work with .F/.G suffixes.

If they are all renamed then the suffix could be re-used for other things, like perhaps the ⅛ transforms that appear in some icons like   (exKSTRe-uexKSTRe.L), although icons like   (utSHI2½+4) might also need some other kind of syntax addition to make sense (maybe SPL½?).

I made an unimplemented proposal for these suffixes in 2020 in which ⅛ transforms would be written as ~8L/~8R; the proposal does still seem logical to me, but it might be overkill since it technically enables some completely unnecessary things like ⅕ transforms and people might make those icons just because they can. Jc86035 (talk) 08:38, 24 February 2024 (UTC)

Double-width shifts

Moved from User talk:Jc86035#Mass renaming concern

I have 18 files on my watchlist that you have renamed, and I'm concerned about the renaming not being evidenced anywhere in the BSicon/Catalogue#Naming logic. Specifically, I'm seeing the addition of ".LL" and ".RR" to wide shift icons, and I cannot find any justification or precedent for this. Please check the files

and any others you have applied the same renaming to, and either revert your actions if they were made in error, or bring it to the Talk:BSicon/Renaming board if you still believe it is justified. VanIsaac (en.wiki) 03:27, 24 February 2024 (UTC)

@Vanisaac: The .L and .R suffixes are already documented (although not precisely enough, I think) at BSicon/Catalogue#Suffix modifiers. They were introduced in late 2018 to cover some edge cases, although they don't seem to have been used much.
The start or end of the track is supposed to be aligned along the central axis of the icon unless specified otherwise. This also applies for double-width icons, or at least I have previously renamed icons for that reason. Some icons like   (utbvSHI5gr-~L) were renamed by me in 2020 to specify clearly where the track starts or ends. Other icons like   (uehbvv--SHI4ngnr) were renamed by me in 2018 before the .L and .R suffixes were created.
There are now three different ways to transform an object in an icon to the left or right. ~L/~R transforms an object to the left or right by half of the icon width, regardless of how wide the icon is, and the other two methods (parallel lines syntax and .L/.R suffixes) transform an icon to the left or right by a quarter of the icon height.
Typically, if multiple naming methods would work for a set of icons, the shortest or clearest method would be chosen. The other possible option for renaming   (bSHI4r.LL) would have been to use parallel lines syntax to make bvv--SHI4r, which is longer. ~L/~R wouldn't work here because the smallest transformation possible in either direction (half of the icon width) would have been twice the amount needed. This is also consistent with the naming of   (bv2SHI5r.LL), which I also renamed because it doesn't appear to have any other possible names that work within existing naming logic.
Where the repetition of a suffix changes the icon linearly, the suffix modifier is not repeated, such as in   (hdBHF~RR) or   (BHFr@FF).
I may create a new section at Talk:BSicon/Renaming in case anyone is interested (I previously proposed changes to these suffixes and the possible .l/.r suffixes in 2020 and got no response), but I am fairly sure that each of the individual components of the renaming logic used here is already established in some way. Jc86035 (talk) 05:29, 24 February 2024 (UTC)
I have a concern with that logic. The "." operator really only makes sense as a shift away from being centered, which none of the above are. That allows for symmetric shifting, and makes the shifts intuitive. For the life of me, I have no idea why you would have opposite shift directions for File:BSicon exbSHI4r.LL.svg and File:BSicon exbSHI4l.RR.svg. Please take this to the renaming noticeboard so it can be discussed before implementing any other name changes, because this seems like a change towards confusion with no commensurate benefit. VanIsaac (en.wiki) 06:06, 24 February 2024 (UTC)
@Vanisaac: I know the names you chose are simpler, but they don't fit with how shifts work outside of this specific context. Absent any modifying syntax, they start or end at the midpoint of one edge of the icon in order to connect with the previous or next row in the diagram, so   (STR) connects with   (SHI3l), and each of the lines in   (bvvSTR) would connect with   (bvvSTRl--SHI2ro). As such, as far as I can tell, bSHI4l (or bKRWl) would start at the midpoint of the top edge, just like   (KRWl) or   (dSHI4l) or   (bSHI2lr). (I think bSHI2l and bSHI2r would create bSHI2lr, but they wouldn't if they were centred horizontally.)
There isn't any real reason for double-width icons to be named with different logic to all other icons for where lines start and end, and the start/end point of the line has to be decided for odd-numbered shifts like   (bSHI5l.RR), because if you centred them exactly in the image frame they wouldn't line up with about 99.99% of icons.
The icons have opposite transformation directions because it creates shorter names. This practice already exists in icons like   (vSHI2l-) and   (v-SHI2r), which have been named like that for over 10 years. One is a shift to the left transformed to the right, and vice versa.   (v-SHI2+r) and   (vSHI2+l-) respectively redirect to each of them.
I was already drafting up a section about these suffixes on Talk:BSicon/Renaming but I'm not sure if it would make sense to focus it on the suffixes, since I think your concern specifically applies in the context of double-width icons? If we wanted to propose a change to the definitions so that your original icon names are explicitly the correct way to do it (in the context of double-width shifts or all double-width icons), that is also possible, but I personally think it would be hard to logically justify that within the existing naming system. Jc86035 (talk) 06:41, 24 February 2024 (UTC)

I am moving a discussion here in response to Vanisaac's comments on my talk page, since I neglected to do so before renaming icons that he uploaded.

There are about 179 double-width shift icons at present. We nevertheless have several different forms of syntax to specify where the line connects to at the top or bottom edge.

  •   (bSHI2lr) (no transform)
  •   (bv-SHI6l~R) (transformed using both parallel lines syntax and ~L/~R suffixes)
  •   (uhbvv--SHI4ng+nr),   (utbvvSHI5gl--+utbvvv---SHI5gr),   (bvvSTRlo--SHI2r) (transformed using parallel lines syntax only)
  •   (bSHI4r.LL),   (bv2SHI5r.LL) (transformed using .L/.R suffixes)

As far as I can tell, all of these names do actually fit within established naming conventions. However, the syntax is used mostly due to my personal efforts to make the naming of double-width icons "logical" and explicitly specify horizontal alignment, possibly at the expense of the comprehensibility of the icon names, and maybe it would be worth revisiting the naming of all of these.

Personally, I think a name like   (utbvvSHI5gl--+utbvvv---SHI5gr) is not really reasonable and I would just split it into two regular-width icons, and I wouldn't change   (bvvSTRlo--SHI2r). The naming of most of the others could potentially be unified, such as if they were all renamed to use .L/.R. Jc86035 (talk) 09:04, 24 February 2024 (UTC)

Horizontal parallel lines

I've just come across   (xvSTR-STR2q). It appears that based on our current naming conventions for horizontal parallel lines, we might not be able to name it correctly, because exSTRq-STR2+r could mean that both lines are disused.

About 120 icons currently use both halves of the horizontal parallel lines syntax, of which about 60 have ambiguous prefixes. A few of them, such as   (uexKDSTeq-KDSTeq) and   (emKRZu-KRZu), are named such that the starting prefixes don't affect the lower line, but others aren't, such as   (exSTR+r-STRro) and basically all of the set u ones.

Assuming that we were to change parallel lines syntax to allow this icon to be named correctly,

  • We can't just add v to any ambiguous names, because of icons where this would cause other naming conflicts like   (mKRZo-KRZo). A different prefix would be needed. The remaining available lowercase letters in the English alphabet for prefixes are a, i, j, y and z. (q is used on some icons like   (qDST+exBHF) and   (qLIN brown), and r is used on some experimental icons like   (rBHF).)
  • It would be fairly disruptive to rename all icons featuring horizontal parallel lines syntax without the v prefix, of which there are approximately 7,000. We would want to make any new syntax optional.
  • This wouldn't be a problem if there were a prefix to indicate icons with regular width. In various contexts, we use " " (space) and "+" to represent that width, so theoretically we could rename   (exSTR+r-STRro) to ex STR+r-STRro or ex+STR+r-STRro. This would probably just be confusing.

Potentially, we could rename all of the icons with ambiguous names so that the prefixes are always specified separately for the top and bottom halves. I don't think it would cause problems or require any new syntax, but it's not necessarily a great solution. Jc86035 (talk) 19:04, 24 February 2024 (UTC)

Apparently in 2018 the favoured idea was to use a caret where the v prefix would go in cases where it would be necessary, but it was never implemented. Jc86035 (talk) 19:53, 24 February 2024 (UTC)

~L/~R on parallel lines

@Vunz: I don't think your new icons like   (evSHI2+r-STR+4~L) are named correctly, because the "~L" would transform the   (v-STR+4) part to become   (STRc1~R), and the suffix's position at the end of the icon name is ambiguous and implies that it also affects the other half of the icon.

I think this particular icon could probably be called something like evSHI2+r-STR+4.GG (we can take advantage of the .F/.G suffixes not being used much to define that they always go inside parallel lines syntax), but maybe there is a better name for it that I can't think of. Jc86035 (talk) 19:15, 24 February 2024 (UTC)

One possibility is that we could explicitly redefine the ~L/~R/~F/~G suffixes so that they do go inside parallel lines syntax, which would allow us to make the icon names more consistent here. Other than icons uploaded by Vunz, there are about 50 icons which use the ~L/~R/~F/~G suffixes for separate parallel lines, and in most cases the suffix is used once to affect both halves of the icon. However, there are also about 1,300 icons that would have to be renamed to move the hyphen to the right of the suffix. Jc86035 (talk) 19:44, 24 February 2024 (UTC)

Meaning of ≡

@Useddenim: How is "≡" different from the connector "+"? So far it seems to be used in 5 icons, but I can't really tell why it's more suitable than "+" for those icons. I also can't tell if the prefixes are supposed to affect both parts of the icon, since they do in   (muSTR≡ABZq+lxr)fixed 16:19, 28 February 2024 (UTC) but they don't for the others like   (hSTR+l≡STR). Jc86035 (talk) 20:55, 24 February 2024 (UTC)

@Jc86035: When I stated that the "≡" symbol "overlaid" one icon over another, I meant that the first one partially obscured the second. If that wasn't the case, the junction/crossing icon would be   (muSTR+ABZq+lxr), because heavy rail takes precedence over set u. Useddenim (talk) 16:19, 28 February 2024 (UTC)
@Useddenim: It doesn't seem like we have consistent practice for how prefixes and suffixes work with the + connector.
  • In   (eSTR+BSl) and   (xSTR+GRZq), the prefixes affect both parts of the icon, but the suffixes don't.
  • In   (xvSPLe+GDqo) and   (eABZ2x3+exKRZo), only the o suffix affects both parts of the icon, and the other affixes don't. (These icons would probably be renamed to xvSPLe;SKRZ-GDo and exABZ23;o+c2 per the proposal above to implement the ; connector.)
  • In   (nvSTR+vvSTRq), only the q suffix affects both parts of the icon, and the other affixes don't.
  • In   (uexSTRr+uBS2c2),   (STR+lBUEq),   (WDOCKSm+lhvSTR~LL),   (nvSTR+vvSTR),   (fSTR+l+WSHI1r),   (XPLTq+uexSTR),   (exSTR orange+GRZq),   (uexSTR+lCJCTfq) and   (htBHFa@f ochre+RMq), the affixes each only apply to one part of the icon. In   (ndSTR+dvBHF) and   (udSTRr-+udSHI2l), even the d prefix is repeated for both elements.
  •   (vWDAMM+uWLOCKg) seems to be misnamed and probably should just use - instead of +, but I'm not sure if I actually understand what it is meant to depict.
Based on usage of the + connector, I would say that it is more common for the prefixes and suffixes to not affect both parts of the icon, but also that in most instances the higher element in the icon (if any) is after the connector. As such, I don't see why we couldn't rename   (muSTR≡ABZq+lxr) to ABZq+lxr+uSTR (implying that the uSTR part is on top). To actually make the logic consistent across all the icons that use the connector would take quite a few more renames, however.
If we want to keep using ≡, we should more clearly define how + and ≡ are distinct from each other, and each of them should be able to do something that the other connector can't be used for. At minimum, I think we must clearly define how + works, since it is already used in a lot of icons, and the intended usage should probably be described on BSicon/Catalogue instead of only being implied by the icon names. (In general, I think that page needs to be more specific.)
Additional notes:
  • There were some icons in Category:BSicon/railway/set mixed/crossing+junction that apparently used u as a suffix to mean that a line was in set u, even though u as a suffix pretty much always means "under". I've renamed them to use m instead, based on icons like   (STRl+mr).
  • There are a lot of icons in Category:BSicon/railway/set f/set mixed/crossing/BHF/terminus which are named in a seemingly nonstandard way to explicitly indicate what colour the station circle should be (e.g.   (emfTBHFa~f) vs.   (emfTBHFa)), but I don't know if this reflects established practice.
Jc86035 (talk) 18:00, 28 February 2024 (UTC)
The emfTBHFa icons are more of Cmuelle8's fantasmagorical creations that follow his own naming (il)logic and will never be used. But I agree with the rest of what you said. Useddenim (talk) 18:56, 28 February 2024 (UTC)
Hm, why not these?
Doesn’t work? -- Tuválkin ✉ ✇ 21:37, 30 March 2024 (UTC)
It'd work, although the order should presumably be swapped so that STR goes before BHF.
I think doing this for all ambiguous cases makes some amount of sense, but the convention for TBHF has been that the station colour in mixed same-level crossing stations matches that of the "primary" line (e.g.   (emtTBHFt)), and that doesn't seem to need to be renamed. We could retain the TBHF naming for most of the icons and only rename the TBHF icons that have ~f/~g suffixes (including e.g.   (mtTBHFt~fg), which would become tSTR+utBHFq).
Alternatively, we could rename all of the mTBHF icons to be TBHFm so that the m prefix is freed up to indicate the colour of the station, but that seems like it would be an unnecessary complication. (I don't think it would be appropriate to use the m suffix to indicate the colour of the station, since most of the other suffixes affect the secondary line and not the station.) Jc86035 (talk) 22:41, 30 March 2024 (UTC)

Platforms

If + is standardized as described above, that would affect about 75% of icons with platforms. If they are all to be renamed, it might as well be done properly.

Incidentally, I've disliked that the current naming scheme makes it impossible to create curved platforms.

There are a few different approaches we could potentially take:

  • Retain the BS root and only rename icons with e/x prefixes; i.e.   (exSTR+BSl) → exSTR+exBSl.
  • As above, but also replace BS with PLT across all platform icons; i.e.   (exSTR+BSl) → exSTR+exPLTl.
  • Repurpose the X prefix (obviating the need for the + connector altogether) and standardize suffixes; e.g.   (STR+BSl) → XSTR(L),   (ENDEe+BSel) → XENDEe(LF). Legende icons would use lXSTR and lXKSTR, although some would probably be renamed to use PLT as above if they don't fit in this naming scheme.
  • We could create a different prefix such as P and use that instead of X.

I would prefer renaming most of the icons to XSTR/PSTR, since to me this would be more logically coherent than the other options, but what does everyone else think? Jc86035 (talk) 21:39, 29 February 2024 (UTC)

My preference would be for the STR+BS icons to be moved to PSTR, and the platform-only legend icons renamed to PLT (de:
Plattform
). I don't think it would be a good idea for the X prefix to mean "cross-platform interchange" when applied to stations but "(loading) platform" when applied to lines. Useddenim (talk) 02:21, 1 March 2024 (UTC)
I like these ideas! -- Tuválkin ✉ ✇ 00:49, 25 March 2024 (UTC)
@Tuvalkin, Useddenim: I've renamed most of the platform icons and updated BSicon/Catalogue. There are about 27 remaining icons at the moment.
I'm not sure how to rename icons like   (hSTR+heBSr) that have elevated formations for the platform itself, although just replacing BS with PLT might work. Jc86035 (talk) 20:37, 30 March 2024 (UTC)
Elevated platforms are hPLT, right? (And thanks for all the renaming!) -- Tuválkin ✉ ✇ 21:29, 30 March 2024 (UTC)
@Tuvalkin: They would be, so this icon would be called hSTR+hePLTr, but the use of "e" as a nonstandard prefix is only necessary because as a suffix it has a different meaning in the context of PLT.
If we were to rationalize the PLT suffixes (e.g. by changing "a" and "e" to "f" and "g") then it would be possible to name this icon hSTR+hPLTre, but currently it would conflict with the "e" suffix in   (PLTe). I initially left all of the suffixes unchanged when renaming icons from BS to PLT, but maybe those should be updated as well? (I avoided using the bracketed suffixes because they're supposed to apply to the secondary object, and it's implied that the platform is the primary object in PLT icons.)
As an alternative to only changing the suffixes, we could rename most of the PLT icons using the format   (PLTlr) → lPSTR,   (PLTal) → lPKSTRa(LG). The l/r/f/g suffixes for PLT would be retained for edge cases like hSTR+hPLTre.
There also remain to be renamed some experimental crossing icons such as   (hKRZ+BSael), which I think would have to be renamed to a pattern like PSTRq+hPSTR(L). Jc86035 (talk) 21:51, 30 March 2024 (UTC)
Never mind, I've figured out what to do with   (hSTR+heBSr). I'll rename it to hPSTR(Rlf) (based on   (lhKRZhe(Rlf))). This does mean that the other elevated platform icons will need to be re-renamed, e.g. to hPSTR(Rl), to indicate that the platform doesn't have formations at the start or end. Jc86035 (talk) 06:32, 31 March 2024 (UTC)

New icons

I created   (uSTR2+1d!),   (uSTR3+4d!) &   (utSTR3+4da!) (related to   (uSTR2+1) &   (uSTR3+4)) which connect uw lines that are offset by 1/4, but I'm not sure about naming them. Useddenim (talk) 16:52, 30 March 2024 (UTC)

@Useddenim: Since   (vSTR3+1~r) is offset from   (STR3+1) by 166⅔ pixels along the x-axis, and these icons have the start of the line offset by 125 pixels along the x-axis, the diagonal shift is ¾ quarters (in the sense that the diagonal shift of the S-curve in   (vÜSTl3+1) is 2 quarters).
If we were to use the idea introduced in   (utSHI2½+4) that a shift can be along a curve, we could call   (uSTR2+1d!) something like uSTR2+1;SHI¾+r (and if we did this we would rename utSHI2½+4 to utSTR+4;SHI½l). It's not very comprehensible, but it seems at least somewhat logical. Jc86035 (talk) 22:17, 30 March 2024 (UTC)

Proper suffix to replace "hq"

In icons like   (STR2hq+1hq), should we use μ (Greek lowercase mu) as a suffix instead of hq to indicate that a line connects horizontally to a corner? (The letter "μ" happens to be the first search result for "upside down h", and there are only a few remaining Latin letters that could be used as suffixes.) Jc86035 (talk) 19:21, 31 March 2024 (UTC)

Sounds like a good idea to me (says the guy who has used ½ and ↻ in icon names). Useddenim (talk) 00:35, 1 April 2024 (UTC)
Same here! -- Tuválkin ✉ ✇ 01:12, 4 April 2024 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Talk:BSicon/Renaming/Archive_13&oldid=932449652"