Talk:BSicon/Renaming

See also: Talk:BSicon/Renaming/SPL,
Talk:BSicon/Renaming/ABZ,
Talk:BSicon/Renaming/k,
Talk:BSicon/Renaming/Canals and
Talk:BSicon/Renaming/Roads

For an explanation of BSicon naming see BSicon/Catalogue#Naming logic.

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)

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)

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)

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)

KRZ k-corners

We seem to have 131 icons named using the naming format of  (KRZ+k2) and 109 icons named using the same format as  (kKRZc2).

The former group of icons were renamed in 2017 to their current pattern following a discussion on this page in which all of the participants (Useddenim, Tuvalkin and Sameboat and myself) agreed to the proposed changes. The other icons seem to have all been uploaded by Lantus in 2021, except for 9 that were renamed by them, and all of the icons except for the 9 renamed ones appear to be duplicates of ones that already existed.

Am I missing something? Was there a discussion somewhere I can't find where the new naming scheme was agreed? Did nobody notice that this happened for two years? Jc86035 (talk) 15:56, 23 February 2024 (UTC)

The older naming convention  (KRZ+k2) seems more intuitive to me. I would support removing the redundant ones and renaming those with the new format that have no equivalent in the original format (if any such icons exist.) Hotdog with ketchup (talk) 16:50, 23 February 2024 (UTC)

The incorrectly-named ones were probably uploaded without sufficient checking of what already existed. There may also be some icons with a +kc suffix. Useddenim (talk) 18:28, 23 February 2024 (UTC)

It seems there were only ever about 2 such icons, and they were both renamed to remove the c in 2018. Jc86035 (talk) 18:44, 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

I am starting 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?

•  (eBHFq+KSTRa), from  (feBHFq※ KSTRa) 
•  (eKBHFa+fSTRq), from  (eKBHFa※ fSTRq) 

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)