Talk:BSicon/Renaming/Archive 10

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

h suffix

@Useddenim and Tuvalkin: The h suffix is a bit problematic, as it's used for denoting both an elevated structure and a vertical line at an icon edge, meaning that   (KRZ2h+4hu) could also mean hSTR2h+4 over STR. Maybe the uses indicating the line at the icon edge could have the suffix changed to something else? d is unused, except for a bunch of canal icons which still use down/up, a few narrow lines like   (uexnABZgd+1), and   (xBHFABZdre). (We also still have b, i, j, p, s, y, z, and most of the capital letters. Why did we use the same letter for two different things?) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 16:38, 3 March 2017 (UTC)

h=half-width (line at edge). Useddenim (talk) 22:08, 3 March 2017 (UTC)
@Useddenim: Yes, but the etymology's not really the issue, it's that it creates ambiguity. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 05:08, 4 March 2017 (UTC)
@Jc86035: IIRC, the h suffix for elevated lines hadn't been implemented yet. I have no objection to changing the suffix for lines at edges: perhaps n for narrow, analogous to 50px narrow line icons? Useddenim (talk) 12:35, 22 March 2017 (UTC)
@Useddenim: I don't think we should use n, since that's also a prefix and could create more problems (e.g. uSTR+1un =   or  ?). We could use i for vertical lines and z for horizontal lines (usinq q could be messy with junction icons). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:56, 22 March 2017 (UTC)

@Useddenim and Tuvalkin: Another issue is that if we renamed   (STR-R+STR+1u) based on   (STR+1u) and the suffix, we would end up with   (STR+1uh), which already exists. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:04, 19 March 2017 (UTC)

Icon asymmetry

Legend
evSTRq\evSTR+r
\evSTR
Legend
evSTRq\evSTR+r
\evSTR

@Useddenim and Tuvalkin: Following the rule that the q suffix indicates a 90° anticlockwise rotation, do   (evSTRq) and   (xvSTRq) (plus u, tunnel, interrupted, CONTaq/eq variants, as well as   (uevENDEaq)/xv/eq, but not elevated variants) have their lines the wrong way round? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:39, 16 March 2017 (UTC)

It's not possible to serve bothe curves ... compare the routemaps! a×pdeHello! 15:36, 22 March 2017 (UTC)

@Axpde: Of course it isn't; I just used that to illustrate a 90° anticlockwise rotation. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 15:47, 22 March 2017 (UTC)

NULs

@Useddenim and Tuvalkin: Is there a reason for using NUL for both bridges   (hNULl) and arrows   (lNULf)? Maybe it might be better to just eliminate the root entirely; the bridges could be treated as special cases of   (BRIDGE), and the arrows could be renamed to ARR or lSTR or something which makes more sense (as well as having DNUL changed to normal 2+4/1+3 suffixes). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:41, 5 March 2017 (UTC)

  • I don’t disagree: NUL was meant as a stand-in for STR for icons lacking a line. Not so sure about ARR when comparing things like   (STRf) with   (NULf) and   (lNULf), though (N.B.: lNUL shows black arrowheads while NUL shows white arrowheads). As for the suffixes in the DNUL set, I had already said I agree. -- Tuválkin ✉ ✇ 12:59, 15 March 2017 (UTC)

@Tuvalkin: Should the HNULs use a/eq or l/r?

Current Proposed
  (hdNULl) dBRIDGEaq or dBRIDGEl
  (hdNULr) dBRIDGEeq or dBRIDGEr
  (hNULl) BRIDGEaq or BRIDGEl
  (hNULr) BRIDGEeq or BRIDGEr
  (hNULm) BRIDGEmq
  (lNULf) etc. lARRf
  (DNULg) etc. ARR2+4g
All arrow prefixes and suffixes remain the same, except for DNUL icons

Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 05:11, 21 March 2017 (UTC)

  • Those elevated NULs were not created by me, but I prefer a/eq to l/r. Not so hot about BRIDGE, though: Whatever happened to the BRK idea? -- Tuválkin ✉ ✇ 13:29, 22 March 2017 (UTC)
    • @Tuvalkin: I think we just didn't do anything about it. We would need to work out how the legende icons fit with renaming   (BRÜCKE1) to BRK; do we just change the root for these icons to BRG or something or do we add l/M prefixes as well? Jc86035 (talk) Use {{re|Jc86035}}
      to reply to me       16:16, 23 March 2017 (UTC)

Switching stations

@Useddenim, Tuvalkin, and Axpde: Would   (muBHFa) etc. be fine as mBHFa, or do we need an extra prefix? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:00, 4 March 2017 (UTC)

now suggestion now suggestion
  (muBHFa) mBHFa   (exmKBHFxa) exmBHFa
  (muBHFe) mBHFe   (exmKBHFxe) exmBHFe
  (muBHFa+GRZq) mBHFa+GRZq   (umBHFa+GRZq) OK
  (muBHFe+GRZq) mBHFe+GRZq   (umBHFe+GRZq) OK
  (umSWBHF) ???   (emSWBHF) ???
  (umSWBHFr) ???

Yep, seems ok to me, but what about the rest? a×pdeHello! 12:05, 4 March 2017 (UTC)

Perhaps an alternate design such as   (mKBHFea)/  (umKBHFea), etc.? Useddenim (talk) 13:29, 4 March 2017 (UTC)
@Axpde: I personally don't think SW is a good prefix, as we also have two different S prefixes (roads/S-Bahn) and a W prefix. I guess they could be named mHSTBHF, but that seems like a bit of a stretch. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:52, 4 March 2017 (UTC)

@Useddenim and Axpde: ✓ Done renames as suggested in the table, as well as   (mtvBHFaq yellow+). How should   (emKBHFxa azure+lime) and {{bsq|  (emKBHFxe azure+lime) be dealt with? Should they be renamed to match the colours, or should they be reuploaded to match the names? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:30, 25 March 2017 (UTC)

These other combination icons should also be discussed:

now suggestion now suggestion
  (HSTeBHF) HSTxBHF   (exvBHF+vHST) vHSTeBHF
vHSTxBHF
  (exKBHFa+KHSTa) KHSTeBHFa
KHSTxBHFa 		  (exKBHFe+KHSTe) KHSTeBHFe
KHSTxBHFe
  (exBHF+KHSTa) KHSTeBHFxa
KHSTxBHFxa 		  (exBHF+KHSTe) KHSTeBHFxe
KHSTxBHFxe

i.e. everything in Category:Icons for railway descriptions/stations and stops/exBHF+HST (and also   (uHSTeBHF) &   (HSTeBHF!).
There may also be some icons like   floating around. Useddenim (talk) 13:29, 4 March 2017 (UTC)

 Agree with all, although "HSTxBHF" might be better because the e suffix is usually for line endings. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 05:24, 5 March 2017 (UTC)

Double parallel split

@Useddenim, Tuvalkin, and Fukuokakyushu2012: Should   (SPL1+3f azure) be vABZ1+3f azure? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:48, 29 January 2017 (UTC)

No. See alternate naming suggestion below. Useddenim (talk) 17:42, 29 January 2017 (UTC)
@Useddenim: Yeah, I suppose my suggestion would actually end up being  . I don't think we should really use v as a suffix here, but it makes sense. vABZ1+3f-ABZ1+3f azure would probably be valid, but seems a bit too cumbersome. Similarly with SPLa+1+STR3+1 azure. Maybe SPLa+1+3 azure? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:37, 30 January 2017 (UTC)
@Jc86035: Wouldn't SPLa+1+3 be   (shown in two colours for clarity)? Useddenim (talk) 10:49, 30 January 2017 (UTC)
@Useddenim: Probably, although that would be better named SPLa1+3f. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:52, 30 January 2017 (UTC)

Likewise:

Current Proposed Alternate
  (SPL2+4g azure) vABZ2+4g azure ABZ2+4vg azure cf.   (ABZ2+4g)
  (SPL3+1g azure) vABZ3+1g azure ABZ3+1vg azure cf.   (ABZ3+1g)
  (SPL4+2f azure) vABZ4+2f azure ABZ4+2vf azure cf.   (ABZ4+2f)
  (SPL1+3f azure) vABZ1+3f azure ABZ1+3vf azure cf.   (ABZ1+3f)

Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:51, 29 January 2017 (UTC)

  • This matter should not be a major point of contention (and it sure seems one of those cases of complex features most easily named with + joining two separate icon names), but I think there’s a fundamental principle that should not be abandoned: That any icon whereon a line starts as simple and ends as double (or the opposite) should always include SPL in its name. -- Tuválkin ✉ ✇ 02:04, 30 January 2017 (UTC)
@Tuvalkin: I would agree if the SPL was the only feature on the icon. (In this case, there is also a junction.) Otherwise, follow the KISS principle. Useddenim (talk) 10:49, 30 January 2017 (UTC)
Ah, we agree, then! The way I “kiss” it, the split is the major feature, and naming it based on SPL yields the simpler, most clear names. -- Tuválkin ✉ ✇ 19:26, 30 January 2017 (UTC)

Also, is   (vSHI2g+l1- azure) fine as it is, or should it be g+1l? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:40, 30 January 2017 (UTC)

This one looks more like vSTR+1-+vSHI2g+l- to me. However, there is the question: How often are these complex, unusual icons going to be used? (Why not just use an overlay in the one spot where it is needed?) Useddenim (talk) 10:49, 30 January 2017 (UTC)
@Useddenim: I don't think this one is ever going to be used (it's unused right now), especially since Fukuokakyushu has been inactive for quite a while. Maybe it's better to delete it. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:55, 30 January 2017 (UTC)
As for the others, they could be useful for diagrams of large rail yards, although of course there's overlaying pretty much everywhere. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:57, 30 January 2017 (UTC)
(Guys, guys — deleting something just because it’s hard to name it is bad. See it as a challenge to the naming rules, instead of a nuisance!) -- Tuválkin ✉ ✇ 19:26, 30 January 2017 (UTC)
@Tuvalkin:   (vSHI2g+l1- azure) → vABZg+1-SHI2r azure? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 08:59, 5 February 2017 (UTC)
@Jc86035: , I said that in my opinion these should include SPL in their names. I frankly dont have any strong opinion about these icons, apart from that, but my approval is not necessary anyway — so, no need to ask. -- Tuválkin ✉ ✇ 02:04, 7 February 2017 (UTC)
@Tuvalkin: Perhaps   (vASHI2g+1l-) might work? I don't think it should use the SPL root because a SPL icon can't be created from combining any two of its lines. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:56, 26 March 2017 (UTC)

S-Bahn tunnel portals

@Useddenim and Tuvalkin: Should   (tSBHFae) etc. be renamed back to use BHFCC? They were renamed by YLSS in 2014, but he seems to have gotten stuck on how terminus icons should be renamed and given up on renaming the rest of the *CC icons. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:26, 17 February 2017 (UTC)

also BST and S+BHF. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 16:19, 17 February 2017 (UTC)
Personally, I never liked the *CC suffix, so I have no problem moving everything to t*ae, but regardless, naming should be consistent one way or the other. Useddenim (talk) 12:33, 18 February 2017 (UTC)
@Useddenim: So rename them back to *CC? I do think it would be better in the long term to get rid of the CC suffix, but there doesn't seem to be a satisfactory way of renaming the terminus icons unless we tack the suffixes onto the t prefix like with   (haCPICl) (i.e.   (tKBHFCCa) → tefKBHFa). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:41, 18 February 2017 (UTC)
That seems to be a neat solution, but I think it would be best to wait for additional input before eliminating the ~CC suffix. Useddenim (talk) 21:52, 18 February 2017 (UTC)
@Axpde, Sameboat, Circeus, and Lost on Belmont: thoughts? should the S-Bahn icons simply revert to using the *CC suffix, or should the *CC suffix be obsoleted? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 08:35, 19 February 2017 (UTC)
I never liked the CC suffix ... at least the 'e' and 'a' suffixes are quite consistent ... keep it that way! a×pdeHello! 08:52, 19 February 2017 (UTC)
@Axpde: Are you fine with tacking the af/eg affixes behind the t prefix, if we choose to deprecate *CC? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 08:54, 19 February 2017 (UTC)
First of all, if there are 'e' and 'a' within the same icon, there's no need for 'f' and 'g'.
Secondly, a starting track, an ending tunnel ... I always prognosed that it might be no good idea to change TUNNELa/e into tSTRa/e ... now you got a big problem and I'm unsure to solve this gordian knot :-( a×pdeHello! 10:04, 19 February 2017 (UTC)
@Axpde: I agree that there's not really a need for f or g, but it's to be consistent with   (tBHFa) etc., which have the formation on the station instead of next to it.
As for changing TUNNEL to tSTR, that was before my time and I don't think the decision would really affect these particular icons (tBHF has always been tBHF). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:52, 19 February 2017 (UTC)
  •   (tBHFa): track changes from surface to tunnel within station limits,
  •   (tBHFe): track changes from tunnel to surface within station limits,
  •   (tBHFae): track on surface, station in tunnel,
  •   (tBHFea): tunnel track, station outside,
  •   (KBHFa): track starts,
  •   (KBHFe): track ends,
  •   (tKBHFa): track starts, station and track in tunnel,
  •   (tKBHFe): track ends, station and track in tunnel,
Leaving mess for some more KBHF's, here's my proposal:
  • track starts, track in tunnel but station outside →   (KBHFata)
  • track ends, track in tunnel but station outside →   (KBHFete)
  • track starts, track on surface but station in tunnel →   (KBHFate)
  • track ends, track on surface but station in tunnel →   (KBHFeta)
Consistent with tKRZt (where 't' can be used as suffix for the crossing track, etc.) a×pdeHello! 11:29, 19 February 2017 (UTC)
@Axpde: Seems reasonable, although the last two could be tKBHFate and tKBHFeta (as the station is in tunnel). We could apply this for CPICs as well (e.g.   (utCPICCCre) → u(t?)CPICtef), since they (for some weird reason) don't use the K prefix to denote a terminus. (See also Useddenim's renaming proposal for them above, although I would rather use KCPB than CPK.) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:33, 19 February 2017 (UTC)

@Useddenim and Axpde: Do you think it's fine if we rename the non-terminal stations first and deal with the rest of them later? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 06:32, 26 March 2017 (UTC)

Of course; there seems to be consensus there. Useddenim (talk) 11:42, 26 March 2017 (UTC)
@Useddenim: were you replying to my last comment in the section above or the one in this subsection? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:50, 26 March 2017 (UTC)

CPIC tunnel portals

And of course we had to have   (tCPICCCle) [terminus] and   (utCPICCCle) [through station]. I would go with renaming (all of them?) according to Useddenim's solution above (but would probably use a prefix (X?) instead of "CP(B/A/I)" and K prefix instead of "CPK" as root, and use l/r/+l/+r for the legende turns). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:50, 19 February 2017 (UTC)

BS2 to SHI2

Should the 308 icons using the BS2 root be renamed to use SHI2? I wouldn't endorse just changing the root, as some icon names like   (uxBS2lxr) and   (ueBS2lr) are a bit unintutitive (possibly rename to ueSHI2lr/uSHI2lxr and uexSHI2lr+c23). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:39, 19 March 2017 (UTC)

notifications Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:07, 19 March 2017 (UTC)

Yes! (But I suspect there would be extreme push-back from wp:de and possible elsewhere.) Useddenim (talk) 18:45, 19 March 2017 (UTC)
@Useddenim: I don't think it would be that bad, considering there's no change required on their part and we've already renamed several Bilderkatalog icons (  (ABHFl+l) etc.). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:55, 21 March 2017 (UTC)

@Axpde, Nenntmichruhigip, C21H22N2O2, Kleeblatt187, and MBxd1: Are there any problems if the BS2 shift icons are renamed to use the SHI2 root? (pinging Sameboat, Lost on Belmont) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:38, 22 March 2017 (UTC)

The only reason I accept for renaming "BS2" is getting rid of the "2" which indicates a track running to the lower right corner. But "SHI2" uses the "2" too, so why replacin one evil with another? Sorry, but back to the drawing board! a×pdeHello! 15:53, 22 March 2017 (UTC)
The template for the 2-column BS-table is named BS2 in the most of the Wikipedias using BS. So its logical to name the icons also BS2--C21H22N2O2 (talk) 15:59, 22 March 2017 (UTC)
(Edit conflict) @Axpde and C21H22N2O2: …because we also have   (SHI1),   (SHI3) and   (SHI4)? It wouldn't make sense for projects not using the Bilderkatalog to use a different root, without changing the rest of them as well. I agree that it's a bit confusing to use it to denote the number of quarters the line is shifted, but if we can't find anything better (or don't want to bother renaming as many files) then we may as well keep them consistent. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 16:07, 22 March 2017 (UTC)
SHI2 could also be read as „shift to fit with BS2“ by those not knowing about the quartering system. On the other hand it’s easier to understand the other shifting symbols once one knows about SHI2 (though they may be not used on some wikis). Also even with the current name I always look at another article with those icons, because it’s not totally obvious how to use them. So I don’t think this is a large issue.
Regarding the argument about the number not beeing dropped: It’s still a unification so all symbols which shift the line around will have the same base name. Renaming the other ones as well would be a different task and will likely be easier to discuss once there can’t be a side discussion about those beeing different. Also the current/old title will be kept as a redirect, right? So I don’t see how dewiki’s Bilderkatalog would be affected in any way. As you might’ve noticed from my reply, I don’t care that much about renamings of BS icons. So if you really want my opinon feel free to ping me, but I won’t be watching this page. --Nenntmichruhigip (talk) 20:24, 22 March 2017 (UTC)

@Useddenim, Axpde, and C21H22N2O2: I suppose we could rename all 1,672 of the SHI1/2/3/4 icons to use KRS/KRT/KRV/KRW or SH1Q/SH2Q/SH3Q/SH4Q or something to remove the trailing number, but it doesn't seem worth it for something which isn't really a problem except for 45°/shift combination junctions (where it wouldn't cause any actual issues except for potentially being confusing). In addition, there are actually more SHI2 icons than BS2 icons now. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:51, 26 March 2017 (UTC)

... just an idea, if you really wanne get rid of the digits, why not use the prefixes "d" or "c" as suffixes to indicate the shift gap? a×pdeHello! 14:18, 26 March 2017 (UTC)
@Axpde: If we have consensus for doing that, it seems like a workable solution (possibly using KRW as a root to reduce the number of necessary page moves), but it's not strictly necessary, and using "c" might not work well with corners. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:22, 26 March 2017 (UTC)
Keep as is. The only regret I have with respect to the naming is that I should have used SH# instead of SHI# as the root when I introduced it. Useddenim (talk) 16:42, 26 March 2017 (UTC)

90° curves

@Useddenim, Tuvalkin, Axpde, and Sameboat: Maybe it might be time to finally get rid of the lf/rf/lg/rg suffixes? We now have a working bot (on enwiki, anyway), so the large number of conflicting redirects shouldn't have to be manually replaced. (I think having to file 50 different bot requests for approval on the various wikis could be problematic so we could request adding it to CommonsDelinker?) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:47, 27 March 2017 (UTC)

If I remember correctly (and yes, it has been a while) some of these names overlap with curves and stations/directional stations. What about them? Lost on  Belmont 3200N1000W  (talk) 03:11, 28 March 2017 (UTC)
@Lost on Belmont: We've already renamed all of them, I think. The only somewhat-problematic icons left are   (KBFlg) etc., which could either be   (BHFlf) (exists) or BHFll (redirect to   (BHFlfq)). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 04:00, 28 March 2017 (UTC)

Suffixes

@Useddenim, Tuvalkin, and Axpde: There are some inconsistencies with how the -L/R and l/r suffixes have been applied, particularly with   (hBHF-L) and   (uhBHF-L). So maybe this might help a little bit.

Current Proposed
  (BHF-R) etc. BHF-R
  (hBHF-R) etc. h(r)BHF
  (VIADUKT-L) etc. h(l)STRae
  (CSTR-Rag) etc. C(r)STRag
  (lhSTR+1-L+c2) etc. lh(l)STR+1+c2?
  (exhWBRÜCKEe-L) etc. exh(l)WSTRe (This isn't really a BRÜCKE anyway.)
  (CINT-R) etc. C(l)INT-R
  (CBHFCCq) etc. C(r)BHFCCq
  (STR-R) etc. STR-r
  (BHFlf) etc. BHF(l)f
  (BHFrgq) etc. BHF(l)gq
  (BHFlr) etc. BHF(l)
  (KRZo-L) etc. KRZ(l)o?
  (heCPICr) etc. heCPB-R? (see Useddenim's table above)
  (MASKr) etc. v-MASK
  (MASKrr) etc. MASK-r?
  (dMASKr) etc. dMASK-r?
  (MASKa) etc. MASK-

I haven't added platforms to this, as I'd rather not propose another affix just yet. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:16, 31 December 2016 (UTC)

I don't think it's necessary to rename the MASK icons. Useddenim (talk) 16:24, 31 December 2016 (UTC)

Although I think we could probably do without the brackets, it would still help to introduce several more suffixes to prevent ambiguities like   (HSTf) vs   (lHSTf) and   (BHFlf) vs   (BHFlf!) vs   (KBFlg) (would probably be BHFlf). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:38, 27 March 2017 (UTC)

How do I need to rename for black arrow for   (HSTf) and   (HSTg)? I know   (lHSTf) and   (lHSTg) already occupied the affixes. But who know, there will be a user need the black arrow of these   (HSTf) and   (HSTg) version. SNN95 (talk) 13:57, 29 March 2017 (UTC)
@SNN95: I don't think black would contrast well with the dark red, but if you really want to use it, it's probably best to just overlay   (lNULf) over   (HST). Icon overlays can be used in most Wikimedia projects so it shouldn't really be a problem if anyone actually needs it. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 15:21, 29 March 2017 (UTC)
Completely agree. something needs to be done to separate the two types of icons. All overlapping types need to be killed (with or without fire). Unfortunately, at the moment, I have nothing specific to suggest. I may have the brainpower to devote to that when I have finished with writing my novel (which should be sometime during the next epoch). Lost on  Belmont 3200N1000W  (talk) 02:49, 31 March 2017 (UTC)

k curves

Is it just me, or is the naming of the icons in Category:Icons for railway descriptions/k/curve (and various related categories) really inconsistent? Jc86035 (talk • contributions • uploads) 10:01, 12 June 2016 (UTC)

  • …and Yes. Useddenim (talk) 13:07, 12 June 2016 (UTC)
  • Not just you, for sure. But I suspect that the many such inconsistencies that plague the BSicon tree are being side-stepped by all of us while we keep on nonetheless doing improvement work on its categorization — starting with the basic error of misusing a generic category name to mean what should logically be categorized specifically as Category:BSicon. I think that once the proper approach gets a modicum of use (as was hinted at with this cat), it will snowball fast and the changes will smooth out these and other quirks and kinks. -- Tuválkin ✉ ✇ 23:59, 12 June 2016 (UTC)
File Should be Similar to
  (kSTRgr)   (kSTR3)   (STR3)
  (kABZgr)   (kABZg3)   (ABZg3)
  (kABZc4)   (kSTRc4)   (STRc4)
  (kSTRqr)   (kSTRr+1)   (STRr+1)
  (kABZqr)   (kABZq+1)   (ABZq+1)
 
File Should be Similar to
  (kSTRgl)   (kSTR2)   (STR2)
  (kABZgl)   (kABZg2)   (ABZg2)
  (kABZc1)   (kSTRc1)   (STRc1)
  (kSTRql)   (kSTRl+4)   (STRl+4)
  (kABZql)   (kABZq+4)   (ABZq+4)
  (kSTRq+r)   (kSTR2+r)   (STR2+r)
  (kABZq+r)   (kABZq2)   (ABZq2)
  (kABZc3)   (kSTRc3)   (STRc3)
  (kSTRg+r)   (kSTR+4)   (STR+4)
  (kABZg+r)   (kABZg+4)   (ABZg+4)
  (kSTRq+l)   (kSTR3+l)   (STR3+l)
  (kABZq+l)   (kABZq3)   (ABZq3)
  (kABZc2)   (kSTRc2)   (STRc2)
  (kSTRg+l)   (kSTR+1)   (STR+1)
  (kABZg+l)   (kABZg+1)   (ABZg+1)

I’m not sure how to name the kAB~ icons, though… Useddenim (talk) 10:35, 13 June 2016 (UTC)

@Useddenim: maybe (for example)   (kABlg) → kABZf+4r (like   (ABZf+4r))? Jc86035 (talk • contributions • uploads) 09:13, 17 June 2016 (UTC)
Ah, but notice which side of the corner the stroke goes to:   (kABlg) vs  (kSTRg+r※ STRlg) . Useddenim (talk) 10:21, 17 June 2016 (UTC)
@Useddenim: How could we put SHI+r (or similar, assuming you're not renaming the k shift icons) into the icon name? Jc86035 (talk • contributions • uploads) 12:02, 17 June 2016 (UTC)
Change the prefix from k to ks (for k-shift). We've done similar name-bending for HUBs (  (HUBsr) for example) and generic roads. Useddenim (talk) 16:59, 17 June 2016 (UTC)
@Useddenim: I think that leaves   (kBHFl+l) (and lr, qlr, TBHFlr),   (kBRKuf) (and ug), everything in category /formations/elevated/k and subcategory, and possibly category /k-crossing and subcategories. Jc86035 (talk • contributions • uploads) 05:40, 18 June 2016 (UTC)
Old New Comment
  (kBHFl+l)   (BHFk12)   (BHF+k12)
  (kBHFlr)   (BHFk14)   (BHF+k14)
  (kBHFqlr)   (BHFqk14)   (BHFq+k14)
  (kTBHFlr)   (TBHFk14)   (TBHF+k14)
  (kBRKug) BRKukf bridge, under, k feature, moved forward
  (kBRKuf) BHFukg bridge, under, k feature, moved back
In all cases, k becomes a suffix because it refers to the secondary feature. ( (kBHF3) , for example, should explain why.)

@Useddenim: Did you mean BRKukf and BRKukg? Jc86035 (talk • contributions • uploads) 05:56, 19 June 2016 (UTC)

I totally support standardising the kABZ/kSTR suffices to those of STR (aka UW). The transverse set of kABZ/kSTR in particular is the worst offender, they are downright not intuitive to remember. Also not to forget the 3-way junctions:   (kABZglr) and   (ABZg23). -- Sameboat - 同舟 (talk · contri.) 09:30, 29 July 2016 (UTC)
@Useddenim, Tuvalkin, and Sameboat: Renamed all the basic curves and corners (all sets) as well as all the junctions. Did I rename   (STR+k2) etc. correctly, and would   (kABZql-ABZ3rg) be kABZq+l4, kABZl+4fr, ABZq+4kl or ABZl+frk4? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:52, 8 March 2017 (UTC)
  (kABZql-ABZ3rg) →   (ABZq+k4l) (see   (ABZl+34),   (ABZql+l). Useddenim (talk) 01:58, 9 March 2017 (UTC)
@Useddenim: Thanks; done (as well as all the crossing icons). Is   (hkvSTR+4+Lq) correct, or would hkvSTRr+1+G or something else be better? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:06, 9 March 2017 (UTC)
@Useddenim and Tuvalkin: Should the corner icons   (hkSTRq2) etc. be renamed to hkSTRc2q, or are they fine as they are? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:34, 10 March 2017 (UTC)
Renamed: yes; q suffix: no. Useddenim (talk) 11:14, 10 March 2017 (UTC)
@Useddenim: Is there a better way to indicate "the other side of the curve"? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:27, 10 March 2017 (UTC)
hkSTRc2 hkSTR3+l hkSTR2+r hkSTRc3
hkSTRc2 hkSTR3+l hkSTR2+r hkSTRc3
hkSTR+1 hkSTR-c4 hkSTR-c1 hkSTR+4
hkSTR+1 hkSTR-c4 hkSTR-c1 hkSTR+4
hkSTR2 hkSTR-c3 hkSTR-c2 hkSTR3
hkSTR2 hkSTR-c3 hkSTR-c2 hkSTR3
hkSTRc1 hkSTRl+4 hkSTRr+1 hkSTRc4
hkSTRc1 hkSTRl+4 hkSTRr+1 hkSTRc4
  (hkSTRq1) →   (hkSTR-c1) etc. Useddenim (talk) 01:09, 11 March 2017 (UTC)
@Useddenim: Makes sense; would File:BSicon hkSTRq3.svgFile:BSicon hkSTRq1.svg  be hKRZho-hk13? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 04:55, 12 March 2017 (UTC)
@Jc86035: Why not simply hKRZho-c13? Useddenim (talk) 17:14, 12 March 2017 (UTC)
@Useddenim: It might be better if we indicate it's an elevated k curve, for consistency (since we'll probably end up using the notation for the inner corners of parallel k curves). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 01:59, 13 March 2017 (UTC)
✓ Done renamed all files in the group. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 16:23, 25 March 2017 (UTC)
Incidentally, now that we have the A prefix, should the   (kABrf) group be renamed to   (kASHIr) or something? (I'd use the corner numbers but that would be confused with the SHI1/2/3/4 naming.) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:27, 10 March 2017 (UTC)
@Useddenim: Could we add an extra k to indicate that a curve changes the direction of its bend (i.e.   (kSHIr) → kkSTR3;   (kABlg) → kkABZf+4r;   (kABlr) → kABZf+2k1)? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:15, 26 March 2017 (UTC)
I don't see why not; after all, we have LSTR and LLSTR icons. Anyone else have an opinion? Useddenim (talk) 11:36, 26 March 2017 (UTC)
✓ Done earlier today. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:40, 1 April 2017 (UTC)

Junctions

@Useddenim, Tuvalkin, Lost on Belmont, and Axpde: We have about 128 ABZs and WYEs with the f+ and g+ suffixes (as junction point indicators). Should they omit the g+/f suffixes (e.g.   (ABZf+1r) → ABZ+1r)? This would align them with   (ABZ+14) etc., and make it less confusing by not using g for two different things (geradeaus / Gegenfahrtrichtung) for ABZs and WYEs. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:42, 1 April 2017 (UTC)

Although I'm not sure whether there might be some special cases causing problems but in general I agree! a×pdeHello! 12:46, 1 April 2017 (UTC)
 Agree. Useddenim (talk) 15:05, 1 April 2017 (UTC)
 Agree. (I was never really too keen on that “new” g…) -- Tuválkin ✉ ✇ 01:16, 3 April 2017 (UTC)
@Useddenim, Tuvalkin, and Axpde: Renamed 224 files (missed a lot of them in the search due to omitting the x suffix). Should the kkABZ icons be renamed to use the 3xr type suffix instead of the e/x prefixes (e.g.   (ekkABZ+1l) → kkABZ+1xl)? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:07, 4 April 2017 (UTC)
Similar to the diagonal junctions, I think both the ‘correct’ name plus the redirect should exist (e.g.   (eABZ2+4r)/  (ABZ2+4xr). Useddenim (talk) 10:24, 4 April 2017 (UTC)
@Useddenim: So rename them and keep the redirects? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:25, 4 April 2017 (UTC)
Yes. Or simply create the redirect. Whichever is easier. Useddenim (talk) 10:30, 4 April 2017 (UTC)
✓ Done Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:53, 4 April 2017 (UTC)

Attention, there is a big difference with the "k"-icons: How do you manage to declare on which side of the corner the track runs? E.g.   (kABZgl) but   (kABZq+r) ... a×pdeHello! 11:18, 4 April 2017 (UTC)

@Axpde: The second k is added if the curve swaps the direction it's turning in;   (kSTR3) vs   (kkSTR3). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:20, 4 April 2017 (UTC)

Half-width curves

@Useddenim, Tuvalkin, and Axpde: Shouldn't   (edSTRr+1h) etc. be xdSTRr+1h, since the corner isn't the main feature? (I know this is probably supposed to match   (eBS2+l) etc., but those icons should probably be renamed as well.) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 04:59, 10 April 2017 (UTC)

The "e" indicated ever since that the (main) feature (the curce) is "earstwhile" so this name is absolutely correct! a×pdeHello!
@Axpde: Doesn't e indicate that the secondary feature is out of use (e.g.   (eKRZ),   (eSTR3u))? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 07:27, 10 April 2017 (UTC)
nope! Have you ever read the original guidelines? The track is the "base" of the icon, the "feature" is named in the ID! a×pdeHello! 07:29, 10 April 2017 (UTC)
P.S.:   (eSTR3u) has originally been named "ÜW" by me because the main feature is the de:Überwerfungsbauwerk, wasn't me who renamed it! a×pdeHello! 07:34, 10 April 2017 (UTC)
@Axpde: It matters more what the current guidelines say – "primary track in use, feature or secondary track out of use" for the "e" prefix – and not what someone wrote on the fledgling Wikipedias of 11 years ago. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 07:40, 10 April 2017 (UTC)
If you don't like the examples above,   (eABZlf) has been named that way since September 2006. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 07:43, 10 April 2017 (UTC)
Seems as if you can't understand your own cite, it doesn't read "secondary feature"! a×pdeHello! 08:21, 10 April 2017 (UTC)
@Axpde: I'm very confused by what you're saying. It literally says "[…] feature or secondary track out of use", and "closed, under construction, or planned (secondary track, station, stop or other feature)" slightly above that. Where are you getting "main feature out of use from"? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 08:25, 10 April 2017 (UTC)
"main" is not the problem, just strike it out if you like. The the curve is the "feature" or "secondary track". Period. a×pdeHello! 08:40, 10 April 2017 (UTC)
The entire point of this section was that the curve doesn't seem like the secondary feature, but whatever. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 08:43, 10 April 2017 (UTC)
@Jc86035: You’re correct. Useddenim (talk) 10:29, 10 April 2017 (UTC)

Note that YLSS had actually renamed them already in 2014, but Axpde reverted the moves in 2015. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:39, 10 April 2017 (UTC)

-L/-R suffixes

@Useddenim, Tuvalkin, and Lost on Belmont: Should singled parallel tracks from one corner to another use -L/-R suffixes   (vSTR3+1-R) or the usual parallel lines syntax   (vCONT2+4-)? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:14, 10 April 2017 (UTC)

@Useddenim: So no change? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:37, 10 April 2017 (UTC)
 Agree with Tuvalkin. Useddenim (talk) 18:46, 10 April 2017 (UTC)

Zigzags

Should the 16 zigzags be standardized so they make sense with the current ABZ naming scheme? The first four are obvious, but the latter four are a bit more difficult because the main track is diagonal. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 08:23, 11 April 2017 (UTC)

Current Proposed
  (ABZ+13) ABZg3+1
  (ABZ+24) ABZg2+4
  (ABZq+13) ABZq3+1
  (ABZq+24) ABZq2+4
  (ABZ2+4gf) ABZ2+g4+f or ABZ(2+4)f+g or ABX2f+g?
  (ABZ3+1gf) ABZ3+g1+f or ABZ(3+1)f+g or ABX3f+g?
  (ABZ2+4lr) ABZ2+r4+l or ABZ(2+4)l+r or ABX2l+r?
  (ABZ3+1lr) ABZ3+l1+r or ABZ(3+1)r+l or ABX3r+l?
repeat for u variants

Narrow junctions

@Useddenim, Tuvalkin, and Lost on Belmont: The first six are mostly to remove the d suffix, which could end up being used for something else. I've also added the wide icons because all of them could be replaced by regular icons with consistent naming. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 07:48, 11 April 2017 (UTC)

Current Proposed
  (uexnABZgd+1) uexABZng+n1
  (uexnABZgd+4) uexABZng+n4
  (unABZgd+4) uABZng+n4
  (uexnABZdg2) uexABZngn2
  (uexnABZdg3) uexABZngn3
  (unABZdg3) uABZngn3
  (ubvÜSTB) replace with uKRWngnl+nl and uKRWngnr+nr
  (uexbvÜSTB) replace with uexKRWngnl+nl and uexKRWngnr+nr
  (uhbvÜSTB) replace with uhKRWngnl+nl and uhKRWngnr+nr
  (uehbvÜSTB) replace with uehKRWngnl+nl and uehKRWngnr+nr
  (uexhbvÜSTB) replace with uexhKRWngnl+nl and uexhKRWngnr+nr
  (uehbnvSHI4gr) replace with uexhnKRW+l and uehKRWngnr
  (uehbnvÜSTl) replace with uxhnKRWgl and uhKRWng+nr
  (uehbnvÜSTxl) replace with uexhnKRWgl and uehKRWng+nr
  (uhbnvSHI4gr) replace with uhnKRW+l and uhKRWngnr
  (uhbvSHI4g+r) replace with uhnKRWl and uhKRWng+nr

Do narrow elevated icons have 200px or 250px formations? These seem to have a mixture (I'd prefer using 200px to prevent alignment problems). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 08:02, 11 April 2017 (UTC)

Just a note. These icons all have one thing in common (aside from all having been created due to me); they're all narrow "splits" instead of regular narrow junctions. Notice that at the "bases" of each icon, the narrow lines join to form one regular width line. Lost on  Belmont 3200N1000W  (talk) 17:59, 12 April 2017 (UTC)

@Lost on Belmont: That's why I used the n suffix instead of the n prefix for most of them, to indicate that the icons connect to normal tracks. The current naming is somewhat inconsistent in any case, with a mixture of prefixes being used. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 18:01, 12 April 2017 (UTC)

Junction stations

Are BHF and ABZ/WYE treated as two separate roots   (BHFxWYE23) or as one root   (BHFABZxgxr+r)? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 03:00, 13 April 2017 (UTC)

 On hold at the moment I can't see a clear naming scheme in the first, on the other hand the second one is so confusing (maybe using ABHF ?)... just imagine the options for up to three tracks (in-duty/off-duty) and up to three dots (non-existent/in-duty/off-duty) ... roughly estimated 5x5x4=100 BSicons! a×pdeHello! 09:51, 13 April 2017 (UTC)

@Axpde: Yeah, I think the assumption is that the x suffix applies to both the station and the curve regardless of the e/x prefix. It's not all that good, but it works for now.   (ABHFgl+l) is different, although it could always be renamed again so the A prefix is removed. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:06, 13 April 2017 (UTC)
Just assign a new prefix: we already have   (KBHF),   (SBHF), and   (TBHF), so why not YBHF? (since ∆BHF would be a little awkward.) Useddenim (talk) 00:14, 14 April 2017 (UTC)
 On hold Looks like a good Idea. --C21H22N2O2lovesBSFor me!From me! 08:24, 14 April 2017 (UTC)
@Useddenim: Would the prefix be applicable to the BHFABZs as well, and would the e/x prefixes and suffixes change from their current use? (Part of a station could be closed with the line open.) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:38, 15 April 2017 (UTC)

KBHFs

Could we rename the horizontal KBHFs   (KBHFl),   (KBHFr) (plus all variants) to KBHFaq,   (KBHFeq)? This is mainly because there are some icons like   (KBHFeq orange) which already use the aq/eq suffixes. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 18:22, 12 April 2017 (UTC)

  •  Strong oppose if someone uploads icons using non-standard suffixes those have to be renamed! And no matter what you decided, "l" is the suffix for track running left and "r" for track running right. And that's exactly what the icons are showing! a×pdeHello! 09:42, 13 April 2017 (UTC)
  • This is one of the only icon groups left which uses l/r this way instead of fq/gq or aq/eq, along with elevated crossings (which happen to cause potential naming conflicts because of the use of the l/r suffixes), some canal icons, TBHFs and TEEs. I don't really mind if your solution is just to rename the icons in the other colour sets, though (and renaming to aq/eq would probably be inconsistent with the TBHFs). Jc86035 (talk) Use {{re|Jc86035}}
    to reply to me     10:26, 13 April 2017 (UTC)
  • Axpde, you are not an admin anymore. That means that you cannot bully others into accepting your demands, you need to come up with actual arguments. And, no — declaring that eq/aq instead of l/r is non-standard, period, is not a good argument. Almost everybody can see that BSicon nomenclature evolved (against your stubborn shortsightedness — now no longer powered by admin tools), and that these cases are better named with the “new” eq/aq (or fq/gq) suffixes while the l/r suffixes gain a more specialized, clearer usage and meaning. -- Tuválkin ✉ ✇ 09:55, 14 April 2017 (UTC)
  •  Support: Long overdue. -- Tuválkin ✉ ✇ 09:55, 14 April 2017 (UTC)
  •  Support: We should understand between three different suffix groups: l, r, +l, +r for curves from one side to an other side of the icon; f, g, fq, gq for travelling directions; and a, e, aq, eq for beginnings or endings of lines. Together with the changes under ABZ/STR icons, who is currently in implementation, we'll create a better understandability of the BSicons. -- C21H22N2O2 (V • T • E) 06:02, 17 April 2017 (UTC)

@Useddenim, Tuvalkin, and C21H22N2O2: Also:   (TBHFl)/r → TBHFaq/eq;   (BHF+TEEl+xr) etc. → TBHFxeq? (do they need the K prefix?) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 08:31, 17 April 2017 (UTC)

****, why does   (BHF+TEEl+xr) have this name? There's no need of the TEE! TBHFxeq is a clear and good name (or, if we don't change r in eq it should renamed to TBHFxl). — Preceding unsigned comment added by C21H22N2O2 (talk • contribs) 09:23, 17 April 2017 (UTC)

Wyes

@Useddenim and Tuvalkin: Should wyes use the simplest name possible (where the x suffix can be applied), given that each has at least three possible names? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 04:51, 18 April 2017 (UTC)

Current Proposed (Jc86035) Proposed (C21H22N2O2)
  (WYE1+fg) WYE1g ABZg1+1
  (WYE2+fg)? WYE2g ABZg2+2
  (WYE1+rf) WYE+1r ?
  (WYE2+rg) WYE2r ?
  (WYE3+fg) WYE3g ABZg3+3
  (WYE4+fg) WYE4g ABZg4+4
Why use we not ABZ? For the 'normal' wyes e. g.   (ABZgl+l) we use this and not WYE. And for the renaming, IMHO the wyes with a straight track should be named like I've noted it in the table. For the others I currently have no idea, but I'll think about it. -- C21H22N2O2 (V • T • E) 08:23, 18 April 2017 (UTC)
@C21H22N2O2: Using ABZ for 1+rf and 2+rg (and the other wyes,   (WYE23),   (WYE+14),   (WYEr+12) and   (WYEl+34)) is problematic because we don't have a good way to indicate more than two junction points; see also § Zigzags. It would work for the others though. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 08:29, 18 April 2017 (UTC)
@Jc86035: But for   (ABZgl+l) (and the others) it works with a straight track and the two curves: g means , l means and +l means . With this logic I believe that we also can name e. g.   (WYE1+rf). We have to choose one "straight" track and to name the two curves to an other point. -- C21H22N2O2 (V • T • E) 13:10, 18 April 2017 (UTC)
@C21H22N2O2: The issue is how do we indicate that, and how do we pick the "main" track? We could use brackets   (ABZ(+r)1+1) or some other punctuation   (ABZ23;g+g) or have no separator   (ABZ3+1r+l) or whatever. Picking the main track could be based upon symmetry and track length, although there are obviously other possibilities. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:52, 18 April 2017 (UTC)
@Jc86035: Which separator? In the "normal" wye   (ABZgl+l) there is no seperator, and IMHO we dont need something like that. For all the wyes with a straigt track my version (IMHO) is the best because it's similar to the "normal" ones. But also in the wyes only with curved tracks we don't need a seperator. The only problem is that we need a consistent sequence. -- C21H22N2O2 (V • T • E) 14:15, 18 April 2017 (UTC)
@C21H22N2O2: I prefer your version for the WYE*+fg icons, but in the others it might help to separate them to avoid confusion (since there are already some other icons, like   (SPLa+r+g), which use two plus signs; and g/q can't be used for them). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:24, 18 April 2017 (UTC)
@Jc86035: OK. Then I'll rename the first and the two last in the table (upload the one with 2nd corner). And I'll upload them with crosswise straight track and tracks to corner. Last question: ABZ (nearer to   (ABZgl+l)) or WYE (because it's a wye)? -- C21H22N2O2 (V • T • E) 15:19, 18 April 2017 (UTC)
@C21H22N2O2: For the ones with g or q as the main track I think ABZ would be better for consistency. (The others should probably stay as they are for now.) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 04:54, 19 April 2017 (UTC)
Ok, then I'll rename/upload them today or tomorrow. -- C21H22N2O2 (V • T • E) 06:21, 19 April 2017 (UTC)

Comment:   (ABZgl+l) etc. are a special form of WYE icons, because they also fit the standard orthographic naming scheme. There was a discussion when the diagonal WYEs were first introduced, and it was agreed that—for symmetical ones such as   (WYE1+fr) etc.—the “main” track was the one on the axis of symmetry. Useddenim (talk) 00:38, 20 April 2017 (UTC)

@Useddenim: WYE is a rather specific root (and some of them could already be renamed to ABZs) and adding a way to specify a 45-degree main track with ABZ would additionally help in renaming the zigzag tracks (in the above section). As for the main tracks, in cases where the junction isn't symmetrical (and the main track isn't STR or STRq) would the main track be the longest track? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 06:27, 20 April 2017 (UTC)

RP4

@Useddenim and Tuvalkin: Isn't   (RP4) (based on its geometry) actually RP22 (like   (RP21))? (See w:en:Template:Pittsburg/Bay Point station, which fakes four-lane carriageways by overlaying RP2 on RP4.) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 16:19, 21 April 2017 (UTC)

  • While it can be whatever we want to see in it, this was meant to be a generic symbol of wide (multiple lane) roads, to be used only to illustrate crossings of unrelated roads with the main subject of a given diagram (that explains i.a. the unusual naming system and the mismatching design): In that spirit, road diagrams were thought to be better expressed using regular line icons. The subsequent expansion and development of this icon family to be used as the main one for road diagram was unexpected and keeps posing unplanned conundrums. -- Tuválkin ✉ ✇ 01:41, 22 April 2017 (UTC)
Fortunately, the flexibility of the BSicon naming system has been able to accommodate all of the new icon designs that have been created. Useddenim (talk) 11:25, 22 April 2017 (UTC)

Dashed narrow black lines

Perhaps we can clean up the GRENZE/GRENZE2/GRZ/exlGRZ mess by moving everything into the tBL family?
Consider:

STR BL
regular      
tunnel      
Straight
suffix BL exBL tBL extBL CPIC
■   (BL)   (exBL)   (GRZ)  (lGRZ)  (WGRZ)   (exlGRZ)   (CPICqq)
v■-   (vGRZ-)
v-■   (v-GRZ)
a   (BLa)   (exBLa)   (lGRZa)   (exlGRZa)   (CPICuu)
e   (BLe)   (exBLe)   (lGRZe)   (exlGRZe)   (CPICdd)
q   (BLq)   (exBLq)   (GRZq)  (WGRZq)   (exlGRZq)   (CPIC)
d■q   (dBLq)   (exdBLq)   (dGRZq)   (dCPIC)
q■-   (GRZq-)
-■q   (-GRZq)
aq   (BLaq)   (exBLaq)   (lGRZaq)   (exlGRZaq)   (CPICrr)
eq   (BLeq)   (exBLeq)   (lGRZeq)   (exlGRZeq)   (CPICll)
K   (GRENZE2+q)   (exlGRZ+q)
Tl   (lGRZTl)   (exlGRZTl)   (CPTl)
Ta   (lGRZTa)   (exlGRZTa)   (CPTa)
Tr   (lGRZTr)   (exlGRZTr)   (CPTr)
Te   (lGRZTe)   (exlGRZTe)   (CPTe)
al   (GRZal)   (exlGRZal)   (CPICal)
ar   (GRZar)   (exlGRZar)   (CPICar)
el   (GRZel)   (exlGRZel)   (CPICel)
er   (GRZer)   (exlGRZer)   (CPICer)
Diagonal
suffix BL exBL tBL extBL
3+1   (BL3+1)   (exBL3+1)   (lGRZ3+1)   (exlGRZ3+1)
K…1   (KBL1)   (exKBL1)   (lKGRZ1)   (exlKGRZ1)
K…3   (KBL3)   (exKBL3)   (lKGRZ3)   (exlKGRZ3)
2+4   (BL2+4)   (exBL2+4)   (lGRZ2+4)   (exlGRZ2+4)
K…4   (KBL4)   (exKBL4)   (lKGRZ4)   (exlKGRZ4)
K…2   (KBL2)   (exKBL2)   (lKGRZ2)   (exlKGRZ2)
X   (BLX)   (exBLX)   (lGRZx)   (exlGRZx)
1m2   (lGRZ1m2)   (exlGRZ1m2)
2m3   (lGRZ2m3)   (exlGRZ2m3)
3m4   (lGRZ3m4)   (exlGRZ3m4)
4m1   (lGRZ4m1)   (exlGRZ4m1)
l+g   (BLl+g)   (exBLl+g)   (GRZl+g)
f+l   (BLf+l)   (exBLf+l)   (GRZf+l)
f+r   (BLf+r)   (exBLf+r)   (GRZf+r)
r+g   (BLr+g)   (exBLr+g)   (GRZr+g)
90° turn
suffix BL exBL tBL extBL CPIC
l / lf   (BLl)   (exBLl)   (GRZlf)   (lGRZlf)   (exlGRZlf)   (CPIClf)
+l / rg   (BL+l)   (exBL+l)   (GRZrg)   (lGRZrg)   (exlGRZrg)   (CPICrg)
+r / lg   (BL+r)   (exBL+r)   (GRZlg)   (lGRZlg)   (exlGRZlg)   (CPIClg)
r / rf   (BLr)   (exBLr)   (GRZrf)   (lGRZrf)   (exlGRZrf)   (CPICrf)
45° turn
suffix BL exBL tBL extBL
+1   (BL+1)   (exBL+1)   (lGRZ+1)   (exlGRZ+1)
2+1   (BL2+1)   (exBL2+1)   (lGRZ2+1)   (exlGRZ2+1)
2   (BL2)   (exBL2)   (lGRZ2)   (exlGRZ2)
3+l   (BL3+l)   (exBL3+l)   (lGRZ3+l)
23   (BL23)   (exBL23)   (lGRZ23)   (exlGRZ23)
2+r   (BL2+r)   (exBL2+r)   (lGRZ2+r)
+4   (BL+4)   (exBL+4)   (lGRZ+4)   (exlGRZ+4)
3+4   (BL3+4)   (exBL3+4)   (lGRZ3+4)   (exlGRZ3+4)
3   (BL3)   (exBL3)   (lGRZ3)   (exlGRZ3)
l+4   (BLl+4)   (exBLl+4)   (lGRZl+4)
14   (BL14)   (exBL14)   (lGRZ14)   (exlGRZ14)
r+1   (BLr+1)   (exBLr+1)   (lGRZr+1)
Corner
suffix BL exBL tBL extBL
c1   (BLc1)   (exBLc1)   (lGRZc1)   (exlGRZc1)
c2   (BLc2)   (exBLc2)   (lGRZc2)   (exlGRZc2)
c3   (BLc3)   (exBLc3)   (lGRZc3)   (exlGRZc3)
c4   (BLc4)   (exBLc4)   (lGRZc4)   (exlGRZc4)

Useddenim (talk) 05:05, 26 January 2017 (UTC) ||

  •  Yes to the suffixes and preffixes: They are not perfect but at least they match what’s used in all other icons and that is a huge help when using and developing this set.
  •  No to renaming the root GRZ into BL, for two kinds of reasons:
  1. BSicons are not strictly denotative images, regardless of aboundant use outside what was originally expected: BSicons have a specific (even if some times fuzzy) semantics, and conflating willy-nilly boundary lines with walkways (in tunnel!) blurrs form and content and is a step backwards in the development of a route description syntax, instead of the mere labelling of colored lines.
  2. While GRZ is clear and clearly established both in its name and semantics, BL is a mess: The root name is one of too many starting with "B" and is abnormal at only two letters, and its meaning when contrasting with CPIC is weak and unclear.
Tl;dn: rename as above but keep GRZ as the root. -- Tuválkin ✉ ✇ 03:16, 30 January 2017 (UTC)

Useddenim, does lGRZ now mean "with mask" or "without mask"? See   (lGRZq),   (lGRZ2) vs   (lGRZ2+4),   (lGRZaq). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 08:09, 22 June 2017 (UTC)

Crap. Now – well later, actually – I'm going to have to go back and fix that, too. Useddenim (talk) 12:25, 22 June 2017 (UTC)

KRZ2+4ho+1+c

@Useddenim: Regarding   (KRZ2+4ho+1+c),

  • I've renamed the icon to have +c at the end instead of at the beginning so it matches   (lHUB+c).
  • I still don't think this is correctly named, as since there's no prefix the track should be in the middle instead of slightly to the left, but that would prevent it from being aligned with any other icons due to the 11⁄4 width. The v prefix doesn't work here, since it's offset by 62.5px from the middle and not 125px. In addition, the diagonal track doesn't meet corner 2 as the name implies it does.
  • This icon could be replaced by separate icons, but this would probably be impossible due to the usual overlay problems in {{Routemap}} which exist in {{BS-map}} as well. If the nowiki solution of superimposing an entire row is added to the module to solve this issue, this also poses some problems since it has to be aligned from the left or right edge of something due to CSS limitations (as far as I'm aware) and I don't know whether that anchor should be the table cell containing all the icons in the row (as in nowiki), or the leftmost icon (as a normal overlay would be).

Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 16:42, 29 June 2017 (UTC)

@Jc86035: I used the +c prefix (as in leer+c) to match other (b/c/d) non-standard-width icons. The +c suffix denotes a corner added to the base icon, eg   (STR+c1). Useddenim (talk) 21:38, 29 June 2017 (UTC)

@Useddenim: I assumed it was a suffix, given that the only icons of 5⁄4 width are the HUB icon, the leer icon, and another experimental icon. Without a digit following it, the suffix can be assumed to mean 5⁄4 width since there are no conflicts.
Is the icon correctly named? I think having one line meet the right side corner and another line not meet the right side corner is not really a good solution for this icon.
@Sameboat: Do you have any opinion on if or how the Norwegian (Bokmål) Wikipedia overlay solution of superimposing an entire row should be implemented in Routemap? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 04:01, 30 June 2017 (UTC)

Triple tracks

@Axpde and Lost on Belmont: (other pings above) Could two v prefixes be used for triple tracks? This would be rather convenient in solving some somewhat problematic uses of the -L and -R suffixes, and would also allow some more complex icons (especially 45° curves) to be created for special situations. See also this discussion at /SPL. (I don't think it's entirely necessary to rename the single track icons like this, but we don't have enough suffixes.) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:25, 18 April 2017 (UTC)

Current Proposed
  (vSTR-LR) vvSTR
  (vSTR-L) vvSTR-
  (STR-L) vvSTR-- (or STR-l)
  (vSTR-R) v-vSTR (or vv-STR?)
  (STR-R) v-v-STR (or STR-r, or vv--STR?)
  (vSTR-Lq) -vSTRq
  (dSTR-LR) dvSTR

See also   (vvRP1), which is unused. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:25, 18 April 2017 (UTC)

Hmmm, "vv" looks irritating, what about "w" ? a×pdeHello! 21:37, 18 April 2017 (UTC)
@Axpde: I think that's already used as the width prefix   (w). Using a single letter would make it more difficult to name horizontal icons. Naming 4- and 5-track icons would be slightly easier but I'm not sure if there's much of a use case for those. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 04:50, 19 April 2017 (UTC)
This looks more like a case of “If it ain’t broke don’t fix it!”, since there doesn’t seem to be a problem with the existing naming. Useddenim (talk) 00:41, 20 April 2017 (UTC)
@Useddenim: I agree it's not currently broken, but it's an odd way to use -L / -R (moved 125px instead of 250px) and it doesn't match other v*-L/-R like   (vSTR3-R). Also   (SPLa)/  (vSTR) so   (vSPLa)/  (vvSTR)? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 04:46, 20 April 2017 (UTC)

@Useddenim and Axpde: Use case:   (bvWSL-BS2lr) and   (uexbvÜSTB) have the parallel lines 500px apart, but   (bvABZg+r-ABZg+l) has the parallel lines 250px apart. (The renamed bWSL icons like   (uexbSHI2l+WSLa) don't have a prefix for WSL, which is incorrect since that doesn't match   (WSLa).) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 03:58, 30 June 2017 (UTC)

The broad versions of WSLa is bvWSL-BS2lr and alike, because along with the width we need the double height:
bvvWSLg+r
upper part
BS2l BS2r
lower part
a×pdeHello! 05:27, 30 June 2017 (UTC)
@Axpde: I'm not sure what you're saying here. To clarify, what I meant was that the first two of the icons I linked to (and similar icons) should be renamed because their usage is inconsistent with other uses of the v prefix (tracks spaced 250px or √500000/3px apart), regardless of how wide the icons are. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 05:33, 30 June 2017 (UTC)
The "bv" prefix should have tracks with doubled size and tracks distance. All those tracks 250 px apart can easily be substituted by two or more smaler icons! a×pdeHello! 05:50, 30 June 2017 (UTC)
@Axpde: I would agree, but all of the double-width icons can be replaced by regular width and half-width icons (disregarding the odd geometry of the set u bWSLs). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 05:53, 30 June 2017 (UTC)
Nope, they can't!
  (bAKBHFl+l),   (bSTRl-BS2ro) or   (bvWSL-BS2+r) can't be build without overlaying! And those icons are 40 of 57 in total! a×pdeHello! 05:59, 30 June 2017 (UTC)
@Axpde: I still don't think the width should make a difference in what v means. It shouldn't be that in icons which aren't square v means something different with vertical lines as opposed to horizontal lines. The lack of overlay in the German Wikipedia is a strawman argument which simply does not matter for the 50 other wikis which all have overlay capability in their BS templates or {{Routemap}}. {{BS-overlap}} exists on 54 Wikipedias plus Commons. Import it or {{Routemap}} to dewiki if the lack of overlay is such a major hindrance. (Pinging Tuvalkin, Lost on Belmont for input.) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 07:57, 30 June 2017 (UTC)
"v" means "double track", not "double track with xxx px gap".
Regular size icons with 500 px width lead to a gap size of 250 px, broad icons with 1000 px lead to a gap size of 500 px! a×pdeHello! 13:17, 30 June 2017 (UTC)
Pinging Useddenim, C21H22N2O2, Newfraferz87 and Circeus for input, since obviously we're not getting anywhere. What does v mean for icons which aren't of 500px width? (Putting the lines 1⁄4 of the icon from the left/right edges doesn't really work for icons with widths indivisible by 500px, since the tracks wouldn't align with those of other icons. Consider a dvSTR. In addition, using that rule doesn't work for diagonal icons like   (vSTR3+1).) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:16, 30 June 2017 (UTC)
  • I my view, v means parallel lines and that means parallel lines with their midlines nominally separated by 250 px (i.e., Axpde is wrong). From that follows that vv could be taken to mean several such lines (with that fixed nominal separation) visible inside an icone (or any width).
  • As for the naming, regular square icons have room for three vertical staggered, vv-style lines, therefore two dashes, for three slots, are needed in less simple cases:   (vSTR-LR) could be vvSTR, simpler, or vvSTR-STR-STR, more analytical, while, say,   (vSTR-L) needs to be vvSTR-STR-, i.m.o.
  • I cannot however support the renaming suggested above:   (-vSTRq) is wrong and should be vvSTR-STR-q: Now, more than ever, we cannot pretend that a horizontal icon magically doesn’t need the v (or vv?) prefix. I hate to be inflexible about this, but many icons created by me as vFOO-BARq were changed against my advice to FOO-BARq, «to match the rest». Well now they all match and they are all wrong. Congratulations.
-- Tuválkin ✉ ✇ 22:26, 30 June 2017 (UTC)
Bravo! Useddenim (talk) 03:44, 1 July 2017 (UTC)
@Tuvalkin and Useddenim: If the q suffix is to refer to all parts of an icon (except for in crossings because they're special), there needs to be bracket or other notation to deal with the few icons where q only rotates part of an icon, such as   (v-BRIDGEq) → v-(BRIDGEq). However, I think the dash notation should be retained for icons which do not have a rotation, such as   (uep-BHF). Using v...q for this icon and several others would not make sense.
Retaining the dash notation as well as adding brackets would moreover allow for more complex syntax, such as   (lvBHFg) → l(vBHF)- (to distinguish from   (lvBHF-)).
I mildly disagree with using the more "analytical" method for the triple tracks as it is somewhat more cumbersome, although it would make it harder to get things wrong where there are more than three parallel tracks. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 05:17, 1 July 2017 (UTC)
  • Brackets is in theory a valid filenaming tool for a set such as this (BSicons), but I don’t really see the need. None of the examples you point out look puzzeling to me. I’d suggest   (lv-MKRZu.svg) (maybe?)(fixed! -- 2017-07-03 17:02:17),   (uepBHFf),   (lvBHFg) (unchanged), and   (lvBHF-) (unchanged). -- Tuválkin ✉ ✇ 16:33, 3 July 2017 (UTC)
  •   (lBHFf) etc. are already extant, as well as an   (HSTf) set for some reason. I think if f etc. are repurposed then another group of suffixes such as -f would be needed for distinguishing them all, as mentioned in § Suffixes. There's a thread in archive 8 where I proposed renaming all of the BRIDGEs to use lMKRZ, but that fell apart since I couldn't figure out what to do with icons like   (BRIDGEf) and   (BRIDGEq-L) (the latter also affected by suffix misuse), and also because the parallel icons like   (BRIDGEvq-) didn't have satisfactory alternative names without apostrophe or bracket separators. Jc86035 (talk) Use {{re|Jc86035}}
    to reply to me     16:49, 3 July 2017 (UTC)
  • There’s a lot of old icons with haphazard names, yes. They should be renamed to match simpler and widely appliable new schemes, not hinder the development of such schemes. A propos, the naming of bridges is a is getting better every time, just not quite right there yet. -- Tuválkin ✉ ✇ 17:02, 3 July 2017 (UTC)
@Tuvalkin and Useddenim: please reply; re-uploading full set of 3 curves soon and will be affected if   (-3STRq),   (3STRq-) etc. are renamed. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:36, 3 July 2017 (UTC)
@Jc86035: I'm not sure I understand why you want to rename   (-3STRq) &   (3STRq-). They seem fine as they are, and also don't have any relationship to double triple parallel (vv?) tracks. Useddenim (talk) 19:19, 3 July 2017 (UTC)
@Useddenim: Since Tuvalkin said, we cannot pretend that a horizontal icon magically doesn’t need the v prefix; i.e. icons like   (-STRq) should be named vSTR-q. I'm not sure how this would affect triple-tracked icons or the existing horizontal icons using the dash syntax (I'd prefer keeping the icons as they are now). So would it be   (--STRq);   (-STRq-STRq);   (vvSTRq), or vv--STRq; vv-STRq-STRq; vvSTRq? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 08:48, 4 July 2017 (UTC)
  • I have nothing to add. You know that I subscribe to the notion that a trailing q marks an anti-cockwise rotation of any icon, period (no exceptions, unlike your ecolubrations above). You go ahead and create whatever you want named however you see fit; go ahead constructing an even more rickety house of cards, now with the addition of vv. -- Tuválkin ✉ ✇ 16:33, 3 July 2017 (UTC)
  • Can we please keep this thread focused on Triple tracks and follow up branching discussion elsewhere? -- Tuválkin ✉ ✇ 16:33, 3 July 2017 (UTC)
    • @Tuvalkin: I don't think it would be suitable since the topics here are intertwined, and I'm basically just waiting for a third or fourth opinion before we can have a consensus on whether q is a normal suffix or it refers to all parts of an icon. There are enough sections on this page already. Jc86035 (talk) Use {{re|Jc86035}}
      to reply to me       16:49, 3 July 2017 (UTC)
      • Then rename the section, if it is not about triple tracks anymore. It’s a bad thing to rename sections, as old hash links are lost, I know — that’s why thread discipline is a good thing. Maybe H3 sub threads clearly labelled as tangents would be the best possible choice here. -- Tuválkin ✉ ✇ 17:02, 3 July 2017 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Talk:BSicon/Renaming/Archive_10&oldid=708095897"