Talk:BSicon/Renaming/Archive 13

Latest comment: 7 months ago by Tuvalkin in topic Two-colored BSicons with ~ in name
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

  (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)
  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-LudBHF~LBHF) . 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)
Return to "BSicon/Renaming/Archive 13" page.