From Wikimedia Commons, the free media repository
Jump to: navigation, search

Canal roots[edit]

moved from Talk:BSicon/Colors#Icon review

While we're at it, anyone else thinks we should take advantage of this to clean up various naming issues with the canal icons, notably with regard to the JUNC and WSL roots? It looks bad when there is   (uWSLgl) and   (uWSLl)...

Circeus (talk) 16:33, 10 April 2013 (UTC)

  (uWSLgl) means straight track with turning loop to the left side.
  (uWSLl) means (end) turning loop track running left.
No problem ... a×pdeHello! 18:40, 10 April 2013 (UTC)
Axpde, if   (uWSLl) "means (end) turning loop track running left", what do   (uWSL+l) and   (uWSLl+l) mean?   (uWSLel) successfully employs two suffixes... BTW, I guess we can get rid of WWP/WWPL/WSPL roots. YLSS (talk) 15:56, 11 April 2013 (UTC)

Axpde, can you explain to me how -l means "loop to left" in one icon and "rail to left" in the other? Also why does the loop mysteriously reverses direction between the icons without that direction being (AFAICT) inferable from the icon name? Circeus (talk) 06:39, 11 April 2013 (UTC)

-r and -l suffixes have always been problematic. Many of the waterways icons use -l to mean feature on the left, and -r to mean feature on the right, whereas the railway icons use them to mean feature on the left if you are standing on your head (and hence on the right if you are right way up). Bob1960evens (talk) 08:39, 11 April 2013 (UTC)
For the JUNC root,   (uxJUNCa),   (uxJUNCe),   (uxJUNCld) and   (uxJUNCrd) should all be uex- variants. I am not sure what the -d means, so perhaps they should be   (uexJUNCl) and   (uexJUNCr), or better still,   (uexJUNCr) and   (uexJUNCl).
-d is a left-over from the obsolete naming scheme, and stands/stood for double/doppel. It has been replaced with -l+l and -r+r, as appropriate. Useddenim (talk) 00:12, 17 April 2013 (UTC)
  (uexJUNCld) and   (uexJUNCrd) should be   (ueJUNCl) and   (ueJUNCr), or better still,   (ueJUNCr) and   (ueJUNCl).
  (uexJUNC) should be   (uxJUNC).
  (uexJUNCa) and   (uexJUNCe) should probably be x- variants, but could be e- variants. There are also several uygJUNC and uzgJUNC icons, which might be more consistently named.
For the umgABZ icons, with mixed blue/green branches, I would propose using the same scheme as is eventually agreed for the KRZ icons, so will hold off making a firm suggestion. The road bridges are also in a muddle, with   (uAKRZRu2),   (uHAROADu) and   (uAKRZqu) using -R, H- and -q to indicate that they are rotated, with the canal going across. Then there are   (uAKRZusw) and   (uAKRZuba) which use -sw for swing and -ba for bascule. There are   (uAROAD),   (uAROADq), which use u-, although there is no canal, and   (uAKRZq), where there is no canal and no bridge.   (uKRZuy) and   (uKRZun) use -y and -n as colour suffixes on the end.   (uBROADo) was part of a scheme to rename road bridges, using M-Road, A-Road, B-Road, which was never completed. Most of the Lock icons use Lock as the root, instead of LOCK, and I do not know why the -u and -d suffixes for direction have been replaced by -3 and -5. Bob1960evens (talk) 15:27, 16 April 2013 (UTC)
It's my understanding that -u and -d were discarded from the lock naming because of the confusion between up- and downstream vs "up" and "down" the page. And if you really want to be confused, take a look at en:Wikipedia:Route diagram template/Catalog of pictograms/other roads. Useddenim (talk) 00:12, 17 April 2013 (UTC)
Not to mention a few icons, I believe, that still float around that use -d for "double"... Circeus (talk) 05:38, 17 April 2013 (UTC)
Since canal diagrams generally use -l and -r to mean left and right, as they are designed to be read like conventional maps, rather than using the concept of the directions applying to moving along the route from the top downwards, then -u would mean that the gates point up the page and -d would mean that the gates point down the page. Upstream is always the direction in which the gates point, and is the rule already applied to the FGATE root (eg   (uFGATEu)), which is actually used on many diagrams instead of the Lock icons, as it leaves the diagram less cluttered. The LOCKS icons (eg   (uLOCKSu)) and STAIR icons (eg   (uSTAIRd)) also use -u and -d in this way. Bob1960evens (talk) 12:41, 18 April 2013 (UTC)

Ascents & locks[edit]

moved from Talk:BSicon/Obsolete and deletions#Ascents

These:   (fSTRd),   (fSTRdd),   (fSTRu),   (fSTRuu),   (fSTRdu),   (fSTRud) (plus   (lSTRd),   (lSTRdd) &   (lSTRuu) Transferred from en.wp with temporary names. 21:01, 26 May 2013 (UTC)). The only article which indeed uses (one of) them is en:Template:Rochdale Way East, although the catalogues duly list them all. On the other hand, they are quite an eyesore. Maybe we should get rid of them? Replacing with   (lv-NULf)/BSicon .svgBSicon fSTR.svgBSicon NULf.svg (NULffSTR)  etc. If anybody votes for keeping them, please provide some thoughts on their renaming and possibly redesigning.   (INCgg), from INCline, or   (ABHgg), from ABHang? However, I do not favour keeping them. YLSS (talk) 00:31, 25 May 2013 (UTC)

It can be argued these are keepers, as they are diferent from   (lNULf)-style arrowheads, on two grounds — visibility (they are bigger etc.) and, mainly, semantics: This is about slope, not direction. It would be possible to have both on the same diagram, even, be it a railroad or a footpath (where a segment may for some reason be one-way only, maybe in a gymkhana) or whatever. I fully agree that these should be redrawn — matching the geometry of   (ugLock5). As for renaming, ABH does catch my fancy, but any unambiguous root for “thick arrows” would be very welcome, especially to make order in the mess that currently goes on in Category:Icons for canal descriptions/locks, gates and weirs, with FGATE / LOCK / Lock /STAIR inconsistency. -- Tuválkin 03:11, 25 May 2013 (UTC)
I incidentally found out that Useddenim has already employed canal locks for an ascent at least in this diagram; however, as an underlay: BSicon .svgBSicon LOCK3u.svgBSicon exSTR.svg (exSTRLOCK3u) . (Also, as a historical note, the idea for these indeed came from canal locks; the whole mess we have to clean up nowadays results from a desire to have independent "FPicons".)   (ugLock5) etc. indeed show a white patch at the crossing of lines. I'm not really sure what for; if it was a weir, like   (uWEIRa), than it would be a realistic picture and would represent the fact that there is no chance to navigate there. But for a gate / lock? I suppose we can re-upload the greens with a similar design but black showing above the line? The name: we already have a series of   (LOCK1u),   (LOCK2u),   (LOCK3u), although these should be prepended with an "l". (The "u" and "d" suffixes are quite suitable: the water level rises in a LOCKu, and the path goes up the hill in STRu. I'm just stupid. Always forget that the locks open against the current. So we should also dump "u" & "d" and use - "f" and "g" ? But cf. Bob1960evens's comments above. ) YLSS (talk) 20:02, 25 May 2013 (UTC)
I think the black and white coloring was chosen for contrast, so that it is visible on any color of track, and IMO rightly so. -- Tuválkin 12:20, 26 May 2013 (UTC)

The more I think of this, the more it looks like a great candidate for streamlining of both naming and semantics, not to mention geometry. If there is a need to separate what is an indication of steep grade on one hand or some kind of infrastructure to deal with it (steps in a footpath, locks/stairs in a canal, rack or cable segment in a railroad etc) then maybe there should be a duplicated set of icons, with another rootID, where black is replaced with  formation color  — that makes sense, as we normally use black for iconic elements such as   (exTRAJEKT) and formation color for stylized representations of said formations, such as in   (BRÜCKE2q). These changes, of naming and/or of coloring, should be announced in a nice way and with some advance to the footpath and canal people. -- Tuválkin 12:20, 26 May 2013 (UTC)

I would go for merging these two sets. The current STRdd's are disproportionally large and look awkward in templates. Are the footpath people still active? (BTW, I guess this discussion should be moved somewhere.) YLSS (talk) 21:05, 26 May 2013 (UTC)
To clarify,   (uFGATEu),   (uLOCKSu),   (uSTAIRu),   (uLock5) show a floodgate, a series of individual locks, a staircase of locks where the bottom gate of one forms the top gate of the next, and a single lock. All of them have the gates pointing up the page, and therefore the flow is down the page.   (uxWEIRg) shows a weir where again the flow is down the page. It has an x prefix because it is not navigable (except sometimes in a canoe). Many diagrams use FGATE icons rather then Lock icons to make them easier to read.   (uWEIRr) shows a navigable channel with a side weir on the right bank (where possible, canal icons use r to mean right and l to mean left, rather than the other way round). As maps developed, we needed an icon to represent an inline weir, similar to   (uxWEIRg), on a waterway which was horizontal, so came up with   (uxWEIRfr) where [fr] stood for f(low) r(ight).   (uxWEIRrg) was developed as a way to show a lock with a bypass weir on a single row, rather than needing 3 rows.   (uLockWeir) was an attempt to create a single icon to represent the same thing. The weir leg ought to be in [x] colour, and the fact that the ends of the gates are cut off because they are outside the box is an indication that too much is being squeezed into the available space. Also the direction of the weir is inconsistent with that of the lock, and what would an icon for flow in the other direction be called? They do however use gates which are all black, rather than having a white centre. The [fg] suffixes do not seem to me to be at all obvious, and [ud] seem much more so. I can see that the fr in uxWEIRfr was not a good choice. Probably the inline weir ought to be uxWEIRr, and we need a new root for a side weir (uSWEIRr maybe ?). Bob1960evens (talk) 16:49, 2 June 2013 (UTC)

So, I just created   (lvABHg) and   (lvABHf). Lets do this. -- Tuválkin 12:54, 27 January 2014 (UTC)


Some time ago Deonyi expanded the family of "WDOCKS" with several icons that I wanted to introduce myself but didn't have courage enough. However, we should better settle on naming:

  1.   (WDOCKS-1),   (WDOCKS-23) etc. ->   (WDOCKSc1),   (WDOCKSc23) etc. ?
  2.   (WDOCKS-Re). A good one, I had to use BSicon .svgBSicon WDOCKSeq.svgBSicon WDOCKSe.svg (WDOCKSeWDOCKSr)  before. My intention was to rename   (WDOCKSr) to   (WDOCKS-R) on the model of   (ulvBHF-R), and likewise   (WDOCKSe) to   (WDOCKS-Lq) following   (ulvBHF-Lq). Deonyi apparently had something like that in mind as well, but mixing "-R" and "e" isn't very good. Any thoughts?
  3. I'm quite happy with the DOCKS root, but if anybody has a strong desire to propose anything else, now is the best time to do that. YLSS (talk) 16:48, 15 October 2013 (UTC)

-- YLSS (talk) 16:48, 15 October 2013 (UTC)

  1. Yes, better match the rest.
  2. Nothing wrong with -Re, as in   (KBHF-Re), right?
  3. Go ahead — icon names often lose their etym, nothing wrong with that. Or else   (WDOCKSm) should be renamed   (SEA)!… (But, seriously, it should be renamed   (WDOCKS-M), per #2 above.)
-- Tuválkin 02:18, 1 November 2013 (UTC)


moved from Talk:BSicon/Renaming#uLJUNC

Just spotted these:

  •   (uLJUNCa)  (uLTEEa)
  •   (uLJUNCe)  (uLTEEe)
  •   (uLJUNCld)  (uLTEEl)
  •   (uLJUNCrd)  (uLTEEr)

They should really be uLTEE. Compare

  •   (ugJUNCa) – with curves
  •   (fJCTa) – 90° corners

Useddenim (talk) 00:57, 16 October 2013 (UTC)

And maybe real LJUNCs should be created — something looking like this: BSicon .svgBSicon LABZgl.svgBSicon LSTR+l.svg . -- Tuválkin 02:20, 16 October 2013 (UTC)
Agree with   (uLJUNCa)  (uLTEEa) etc., but BSicon .svgBSicon LABZgl.svgBSicon LSTR+l.svg  should rather be   (LABZl+l). YLSS (talk) 10:15, 16 October 2013 (UTC)
Well put, but I expect lücke versions of   (ugJUNCa) and   (ABZq+lr) (or of   (gABZq+lr), to match the color) to look exactly the same. -- Tuválkin 01:58, 1 November 2013 (UTC)
I would rather suggest TEE instead of JCT; see Talk:BSicon/Renaming#BL. YLSS (talk) 15:32, 19 October 2013 (UTC)
Symbol keep vote.svg Agree. Useddenim (talk) 21:04, 19 October 2013 (UTC)

Rename your JUNC![edit]

Even with JCT renamed to TEE, the remaining JUNC is still a name I don’t like, for two reasons:

  1. It may still be confused with TEE.
  2. This is a kind of wye, yet JCT comes from junction, which we call ABZ.

A new name for these “filled wyes” could be HORN, from a German word that loosely means "trumpet", which in turn is used for road interchanges that look like this icon. -- Tuválkin 01:58, 1 November 2013 (UTC)

New idea: Let’s introduce a new root modifier (uppercase “prefix”), signing a filled line network — I think "F"- is free. Therefore, JUNCFWYE, that is, a filled WYE (and yes, I think that wyes currently named ABZ should be renamed). Plus, with "F"- in use, maybe the WWP family could be relabelled as a double FWSL, and   (uvUST) could become   (uvFÜST) — a filled   (uvÜST). Opinions? -- Tuválkin 04:37, 1 November 2013 (UTC)

(Forgot to reply back then.) I also thought about a root modifier, although I considered adding it after the root – but maybe not. However, I certainly don't like renaming the ABZs to WYEs. That said, uFABZgl+l may be a bit too long for   (uJUNCld). On the other hand, there are also such complicated things as   (uxJUNCld-uSTRlf) &   (uxzgJUNCa). So I still can't invent a satisfactory pattern. Useddenim has uploaded   (JCTl cerulean); but that doesn't solve the problem... YLSS (talk) 11:29, 26 September 2014 (UTC)
@Tuvalkin: I would agree with using the F prefix, especially since the d suffix has been deprecated for years now, and it also works with the various crossing icons (e.g.   (uygJUNCld)ugmFKRZrml+rml?). I think JCT could still be used for the simpler icons, because it tends to create very long names. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
10:53, 5 March 2017 (UTC)


@Useddenim, Tuvalkin: Whatever happened to this category? At least five different roots are used for the same LOCK1d shape. All the suffixes are wrong as well… Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
11:43, 5 March 2017 (UTC)

Current Proposed
  (LOCK1d) etc. lLOCK1f
  (uexFGATEu) etc. uexLOCK1g
  (ugLockl) etc. gLOCK2gq
  (LOCKSr) etc. lLOCKSfq
  (lvABHf) etc. vLOCK1f
  (uLLock3) etc. uLLOCKg (this one uses grey instead of black for some reason?)
  (uLock2+4) uLOCK1g2+4 (could be 14+2 but clarity)
  (uSTAIRd) etc. uLOCK3f
  (uvLock31) etc. uvLOCKae?
  (uSEALOCKu) etc. uSEALOCKg or   (uLOCK2g1f)?
  (uVGATE) etc. uGATE1?
  (uHSTOPLOCK) etc. uGATE2q?
  (ueHGATEl) etc. uGATE1xaq?
  (uNLOCKld) etc. uLOCK1lf?
unused, delete?
  (uxHWEIRf) etc. uexWEIRrq?*
  (uxJOINl) etc. uexJOINgq?
Bonus round
  (uxSTRbm) etc. uxBLDG-M?
  (uSTRb) etc. uBLDG-LR?
  (BUILDINGl) etc. lBLDG-R?
  (uxMILL) etc. uxMILL?
  (uWMILL L) etc. uMILL-R
  (uxSLUICEbr) etc. uxSLUICE+BLDG-L (or uxSLUICE-L)?
  (ugDRYl) etc. gDRYgq?
  (ugDOCKS) etc. gDOCKS
  (uxSTRwmr) etc. uxWINDMILL-L?
  (ugddHSTRg) etc. gDOCK-Lq
  (uddSTRr) etc. uDOCK-L
  (ugWHARF) etc. gWHARF
  (PUMPHOUSEl) etc. lPUMP-R?
  (uLIFTfu) etc. uTHSToe?

* Is it possible for a weir to be out of use?

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