Talk:BSicon/Renaming/Canals

Canal roots

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×p_de^Hello! 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

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)/ (NULf※ fSTR)  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:  (exSTR※ LOCK3u) . (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)

 (fSTRd) et al. renamed GDT – for Gradient(de: Gradient). Fin. Useddenim (talk)

"Docks"

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  (WDOCKSe※ WDOCKSr)  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)

Could not find a better name for this bay/gulf/dock icon

I called it  (WDOCKS!4) because it is different on corner 4 (connecting, not rounded) and matches all other WDOCKS icons (outdated cat name, too). Ideas? -- Tuválkin ✉ ✇ 23:36, 31 July 2020 (UTC)

Currently, we have:

	Icons
0 Corners	(WDOCKS)
1 Corners	(WDOCKS!4)
2 Corners	(WDOCKSa)  (WDOCKSaq)  (WDOCKSe)  (WDOCKSeq)
3 Corners	(WDOCKSa-L)  (WDOCKSa-R)  (WDOCKSe-L)  (WDOCKSe-R)
4 Corners	(WDOCKSm)
Diagonals	(WDOCKS1)  (WDOCKS2)  (WDOCKS3)  (WDOCKS4)

 (WDOCKS!4) could be renamed to  (WDOCKS-4). AlgaeGraphix (talk) 18:32, 1 August 2020 (UTC)

• I like that idea! -- Tuválkin ✉ ✇ 22:06, 2 August 2020 (UTC)

uLJUNC

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:  . -- Tuválkin ✉ 02:20, 16 October 2013 (UTC)

Agree with   (uLJUNCa) →  (uLTEEa) etc., but   should rather be  (LABZgl+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)

 Agree. Useddenim (talk) 21:04, 19 October 2013 (UTC)

Rename your JUNC!

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, JUNC → FWYE, 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)

 Done. Jc86035 (talk) 08:54, 21 February 2018 (UTC)

Locks

@Useddenim and 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)

This page wasn't on my watchlist, so I just stumbled onto it recently, but here's my 2¢ worth:

1 gate, directional	FGATE
1 gate, non-directional	FLOOD
2 gates, directional	LOCK
2 gates, non-directional	SLOCK
2 gates + structure	LOCKS
3 gates, directional	FLIGHT

Current flow: ↓ ICONf; ↑ ICONg; → ICONfq; ← ICONgq.

Useddenim (talk) 03:36, 11 May 2018 (UTC)

Current	Proposed March 2017	Proposed May 2018
(LOCK1d) etc.	lLOCK1f	lFGATEg
(uexFGATEu) etc.	uexLOCK1g	uexFGATEf
(ugLockl) etc.	gLOCK2gq	gLOCKfq
(LOCKSr) etc.	lLOCKSfq	lLOCKSgq
(lvABHf) etc.	vLOCK1f	lvFGATEg
(uLLock3) etc.	uLLOCKg (this one uses grey instead of black for some reason?)
(uLock2+4)	uLOCK1g2+4 (could be 14+2 but clarity)	uLOCK2+4
(uSTAIRd) etc.	uLOCK3f	uFLIGHTg
(uvLock31) etc.	uvLOCKae?	uvLOCKaeg
(uWeirLock)  (uLockWeir)	??????
(uPANAMACANAL-BASINSl)  (uPANAMACANAL-BASINSr)	WBASINlg and WBASINrg?
(uSEALOCKu) etc.	uSEALOCKg or   (uLOCK2g1f)?	uLOCK+GATE
(uVGATE) etc.	uGATE1?	uFLOOD
(uHSTOPLOCK) etc.	uGATE2q?	uSLOCKq
(ueHGATEl) etc.	uGATE1xaq?	uFLOODxaq
(uNLOCKld) etc.	uLOCK1lf?	uFGATEg-xR
(uWEIRa)  (uWEIRe)	unused, delete?
(uxHWEIRf) etc.	uexWEIRrq?*
(uHWEIRf) etc.	ueWEIRrq?
(uxHWEIRg) etc.	uexWEIRlq?
(uHWEIRg) etc.	ueWEIRlq?
(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?
(uSTOPLOCKBRIDGE1)	uGATE2+SBRÜCKE? (redraw)

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

In the waterways world, the light blue colour is used for un-navigable waterways, and so it shows a weir on a river/canal that is not navigable. Bob1960evens (talk) 17:20, 15 December 2023 (UTC)

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

I have added all the HWEIR derivatives to the list, and requested that they be renamed using the convention above. Bob1960evens (talk) 17:46, 15 December 2023 (UTC)

Time for another attempt?

Seeing as there's a flurry of new activity (Category:BSicon/water/navigable), now might perhaps be a good time to think about rationalization?

• Railway (and general) icons (mostly) use three-letter roots; waterways and canal-specific icons could standardize on four-letter ones.
  For example:
  •  (WASSER) → WSSR
  •  (WWECHSEL) → WSEL (which would also differentiate it from  (WECHSEL))  Done Vanisaac 21:49, 31 August 2020 (UTC)
  •  (uWHARF) → uWHRF  Done Vanisaac 21:49, 31 August 2020 (UTC)
  •  (uISLAND) → uILND uISLE^{AlgaeGraphix (talk) 22:44, 20 September 2020 (UTC)}
  • KRZW falls neatly into this naming, as a bonus
  • Roots that already (or nearly) exist:
    • DOCK
    • GATE
    • JOIN
    • JUNC
    • LIFT
    • LOCK
    • MILL
    • POOL
    • RESV
    • TOLL
    • WEIR
  • etc.

Thoughts, Bob1960evens Jc86035 Tuvalkin Vanisaac Vunz? AlgaeGraphix (talk) 22:26, 28 August 2020 (UTC)

• I ♥ it! -- Tuválkin ✉ ✇ 22:32, 28 August 2020 (UTC)

• I would like someone who understands the BSicon naming system to go through those navigable uploads and check my names. I don't have a full grasp on applying the l/r/f/g suffixes, so please feel free to move them, or pop any name changes below and I'll get them moved. Also, I added HAFENDAMM and MÜNDUNG BSicon roots, so there's some others that would need to get reduced to four letters. VanIsaac (en.wiki) 00:41, 29 August 2020 (UTC)

•  (uWeirLock) &  (uLockWeir) → uWRLK & uLKWR. AlgaeGraphix (talk) 23:17, 29 August 2020 (UTC)

The second one should be uxLKWR then. VanIsaac (en.wiki) 23:51, 29 August 2020 (UTC)

@Vanisaac: well, yes. But at this points I'm just looking at roots rather than individual icon mapping. AlgaeGraphix (talk) 03:30, 30 August 2020 (UTC)

I'm seeing both LOCK and WEIR (as well as DAMM) as already being four letter roots though. If you end up with a combined icon, shouldn't we just keep those roots? Maybe they should have a "+" to show that they are a combined icon, so  (uLockWeir) → ueLOCK+WEIR and  (uWeirLock) → uWEIR+LOCK. VanIsaac (en.wiki) 03:54, 30 August 2020 (UTC)

• These icons have never been right. The lock gates point upstream, and the weir has the pointy bits on the downstream side, so the water ought to flow round and round in circles. One half needs to be inverted, but I'd have to look and see where they have been used to work out which bit is facing the wrong way. I agree that the second one should be uxLKWR, but I cannot understand the first one, since the weir is in dark blue, and is therefore navigable. The weir section should also be light blue on this one. Bob1960evens (talk) 12:03, 31 August 2020 (UTC)

I'm not going to try to speak to the creator's choice here, but I can imagine some old English canal having a navigable area near the weir between the locking pools that could be signified by the bare u icon. But I agree that ux is definitely the more necessary icon to have in inventory. VanIsaac (en.wiki) 19:20, 31 August 2020 (UTC)

@AlgaeGraphix: I think it would be best to reuse existing roots with the W prefix where possible; for example,  (WASSER) could probably be changed to WSTR, based on the precedent set by the WKRZ and WABZ roots. Jc86035 (talk) 10:33, 9 September 2020 (UTC)

@Jc86035: Although  (WASSER) is functionally the same as  (STR), the geometry is different. Perhaps you could find a better example? AlgaeGraphix (talk) 11:28, 9 September 2020 (UTC)

@AlgaeGraphix: That's the precedent that has been set, and I don't think it makes sense to deviate from it. I don't think it's logically contradictory, since the icon names are still based on the start and end points of the line in all of the applicable cases.  (WABZgl) combines  (WASSER) [WSTR] and  (WASSERl) [WSTRl] just as  (ABZgl) combines  (STR) and  (STRl); and  (hKRZW) combines  (hSTR) and  (WASSERq) [WSTRq] just as  (hKRZt) combines  (hSTR) and  (tSTRq). Jc86035 (talk) 11:39, 9 September 2020 (UTC)

ISLAND

On a tangent, I’d like to point out that  (ISLAND), although originating from the canal set, exists also as a regular route icon — indeed it can be seen as a shift/split (and see also  (ZTRr) etc.) and is synonym to   (SPLae). See also  (vISLAND),  (bvISLAND), and  (RP2ISL); the lack of an  (WISLAND) is unexpected. -- Tuválkin ✉ ✇ 08:43, 29 August 2020 (UTC)

• I just uploaded  (WISLAND),  (WZTRr),  (WZTRl),  (uWISLAND),  (ueWISLAND),  (uxWISLAND),  (uWZTRr), and  (uWZTRl) for this set. They can be found in Category:BSicon/water and Category:BSicon/water/navigable. We might want to put in a redirect for the "uW" set with a bare "u" prefix as well. VanIsaac (en.wiki) 22:03, 29 August 2020 (UTC)

Just saw there was already a  (uISLAND), and the geometry is noticeably different. I'll download it and make a  (uZTRr) and  (uZTRl) from it. VanIsaac (en.wiki) 22:50, 29 August 2020 (UTC)

• Okay, Vanisaac, but water icons are supposed to be squiggly, not just regular straight-edge lines modified to be 75px thickness and #007CC3 color. -- Tuválkin ✉ ✇ 00:11, 30 August 2020 (UTC)

Hmm. I built those on the basis of splitting the dam and lock channels on e.g.   (uevWLOCKDAMMf). I'll look into the code for the cubic bezier splines to see if I can't make something that looks a bit more squiggly. VanIsaac (en.wiki) 00:18, 30 August 2020 (UTC)

• How does  (WISLAND) look now? VanIsaac (en.wiki) 00:31, 30 August 2020 (UTC)

• I think it looks much better and is now a good match with other water icons at top and bottom. -- Tuválkin ✉ ✇ 01:52, 30 August 2020 (UTC)

Okay, I'll copy that geometry to all the rest of those icons, and I'll even slip them into the LOCKDAMM icons to see if they work. VanIsaac (en.wiki) 01:56, 30 August 2020 (UTC)

Tuvalkin, what is the root ZTR derived from?!? AlgaeGraphix (talk) 23:13, 29 August 2020 (UTC)

• AlgaeGraphix, I think it’s a Zigzag sTRaight. -- Tuválkin ✉ ✇ 00:11, 30 August 2020 (UTC)

• If you want 4-letter roots, why not change ISLAND to ISLE? Bob1960evens (talk) 12:03, 31 August 2020 (UTC)

• I ♥ it! -- Tuválkin ✉ ✇ 19:33, 31 August 2020 (UTC)

Implementation

• So as I was building some DAMM and FALL icons, I noticed I definitely got my "f" and "g" suffixes mixed up on my uWLOCKDAMM creations. I'm going to start renaming those to LOCK+DAMM with the right suffixes, and then move on to WECHSEL → WSEL and WHARF → WHRF moves. VanIsaac (en.wiki) 20:44, 31 August 2020 (UTC)

I have updated BSicon/Catalogue/watercourses to show the new BSicon roots WSEL and WHRF, along with LOCK+DAMM and DAMM+LOCK. VanIsaac (en.wiki) 22:14, 31 August 2020 (UTC)

• It looks to me like there are actually some naming principles emerging and being expressed by User:Jc86035 and User:AlgaeGraphix here, so I'm going to put down a formal articulation of what I think those principles entail.

1. Icons for many natural water courses are functionally identical to BSicons for rail lines, just with the water geometry. These should have the same BSicon basename, with a "+W" suffix. Examples include ABZW, KRZW, and STRW. Navigable waterways can use the "u" coloring prefix, with standard "e" and "x" for a mix of navigable and non-navigable natural waterways.
2. Features that are unique to waterways do not need the "W" suffix to indicate water geometry, and should have a four-letter BSicon basename. Examples include LOCK, DAMM, WHRF, and FALL.
3. Where a watercourse feature is functionally equivalent to BSicon rail features, but represented with different graphical iconography, the watercourse version should have its own four-letter basename. Example WECHSEL vs WSEL.

• The principles for naming watercourse-canal interactions still need to be fleshed out.

Please let me know if that's what you are seeing, and what changes you would make. Also, we currently have a bit of an unwieldy situation with canal-to-waterway transitions and the navigable-to-non-navigable transitions  (uW-WSEL) &  (Wu-WSEL). I feel like there is a better solution out there. VanIsaac (en.wiki) 22:03, 20 September 2020 (UTC)

1. It should actually be W prefix to indicate waterways. E.g.  (WSTRc1), not STRWc1. KRZW is a special case where the W suffix is a modifier, indicating the kind of crossing.
2. & 3. Correct.

You are making the WSEL transition overly complicated:

(WECHSEL)	(WWECHSEL)	(Wu-WSEL) →   (WSEL)
(uWECHSEL)	(uWWECHSEL)	(uW-WSEL) →   (uWSEL)

AlgaeGraphix (talk) 22:38, 20 September 2020 (UTC)

Bridge and stoplock icons

I recently needed a bridge icon with a proposed waterway (the L option) crossing a navigable waterway, for the Fens Waterways Link. There was a  (ueLKRZo), and knowing all the grief that the various combinations of green (unwatered) canals crossing navigable (dark blue) and un-navigable (light blue) caused, decided on  (uLKRZqo) which has the same geometry, but is rotated by 90 degrees. I now notice that this convention has been used for some of the road bridges  (uSKRZ-Ao) and  (uSKRZ-Aoq),  (uSKRZ-Eu) and  (uSKRZ-Euq) which are also rotated by 90 degrees. However, I used qo, and these use uq, so should the qo really be oq?

I also added  (uLSTOPLOCK) and  (uLHSTOPLOCK), as well as simplifying the code for  (uSTOPLOCK) and  (uHSTOPLOCK). I notice in the discussion above, there was a suggestion that these should be uSLOCK and uSLOCKq, uLSLOCK and uLSLOCKq. There are a number of icons which still retain the H prefix which would be better named using the q suffix. How do I go about sorting this out? Do I create the new icons, and then go through all the places where they are used, changing the diagrams? I did this once before for some icons, but it got a bit hairy on the Japanse and Russian wikis. Bob1960evens (talk) 18:01, 12 December 2021 (UTC)

@Bob1960evens: If you put a rename request on those files a Filemover will take care of the rest of the process. Useddenim (talk),

Also, the correct suffix is oq, not qo. 68.133.10.205 17:51, 13 December 2021 (UTC)

I finally got round to putting in a rename request for  (uLKRZoq) to use the oq suffix. If that works out ok, I'll sort out the LHSTOPLOCK. Bob1960evens (talk) 19:23, 16 September 2023 (UTC)

Since uLKRZoq worked ok, I have put in rename requests for  (uLHSTOPLOCK) and  (uHSTOPLOCK). Bob1960evens (talk) 15:39, 18 September 2023 (UTC)

 Done. Useddenim (talk) 00:40, 19 September 2023 (UTC)

Locks & gates, redux

Keeping in mind that direction is with respect to the current flow: ↓ ICONf; ↑ ICONg; → ICONfq; ← ICONgq.

Current Proposed  (uVGATE) uGATE  (uFGATEu) uGATEf  (uFGATEd) uGATEg  (uHGATE) uGATEq  (uFGATEl) uGATEfq  (uFGATEr) uGATEgq		Current Proposed  (uSTOPLOCK) uLOCK  (uLock5) uLOCKf  (uLock3) uLOCKg  (uSTOPLOCKq) uLOCKq  (uLockl) uLOCKfq  (uLockr) uLOCKgq  (uLock2+4) uLOCK2+4		Current Proposed  (uSTAIRu) uLCK3f  (uSTAIRd) uLCK3g  (uSEALOCKu) uLCK3fg   (uSEALOCKd) uLCK3gf  (uSTAIRl) uLCK3fq  (uSTAIRr) uLCK3gq
Current Proposed  (uLOCKSu) uvLCKSf  (uLOCKSd) uvLCKSg  (uLOCKSl) uvLCKSfq  (uLOCKSr) uvLCKSgq		Current Proposed  (uvLock5) uvLOCKf  (uvLock51) uvLOCKfae  (uvLock5e) uvLOCKfa  (uvLock5a) uvLOCKfe  (uvLock3) uvLOCKg  (uvLock31) uvLOCKgae  (uvLock3e) uvLOCKga  (uvLock3a) uvLOCKge		Current Proposed  (uvSTAIRg) uvLCK3f  (uvSTAIRf) uvLCK3g

Useddenim (talk) 02:31, 27 September 2023 (UTC)

I like it, but maybe avoid numbers in root names like "LCK3" so that they cannot be mistaken for a direction?, as in "STR3", f.i., with "3" standing for SW. -- Tuválkin ✉ ✇ 17:24, 27 September 2023 (UTC)

Would 3LCK be better than LCK3? We already have 3STR for 3-column turns and 2SHI# for 2-row shifts. (I'm trying to indicate that there's 3 elements.) Useddenim (talk) 19:04, 27 September 2023 (UTC)

I like that option better. -- Tuválkin ✉ ✇ 02:10, 16 December 2023 (UTC)

I agree that the names in the first column of all these tables are bad and should be changed (long long time ago!) but in the first table there should be a name difference for gates that look like ">" versus those that looke like "|", regardless of orientation. Unless the geometry of these itself is going to be changed, of course.

(And am I the first to notice that  (uVGATE) looks a lot like  (SEC1)…?)

-- Tuválkin ✉ ✇ 02:27, 16 December 2023 (UTC)

Never mind, I get it now. (Needs more coffee!) -- Tuválkin ✉ ✇ 02:28, 16 December 2023 (UTC)

• I like most of this, and even love some of it. While I agree that the LCK3 has problems with possible directional confusion, I'm actually more concerned that it suggests an incorrect semantic interpretation not found with the STAIR root. A STAIR is a set of locks no matter the number, while LCK3 implies it is only three gates / two lock stair. I think that's a bad change in terms of guiding RDT creators towards good design. Another issue is the use of the "v" prefix with LCKS is inconsistent with other uses of the "v" prefix, which would normally indicate two parallel waterways. I'm concerned by the new ambiguity as well as foreclosing on possible adaptations of the proposed LCKS root for parallel waterways. I would support the GATE and LOCK icons as proposed using "f", "g", "fq", and "gq" suffixes, with the null suffix indicating a non-directional gate (which is the thing I love). For the rest, I'd suggest retaining STAIR and LOCKS (LOCK Structure), and using FLOCK (Flood LOCK) as replacement for SEALOCK, and taking its directional suffix from the waterway (two gates) direction so that it would match an adjacent lock or weir BSicon on a straight waterway. So:

Current Proposed  (uSTAIRu) uSTAIRf  (uSTAIRd) uSTAIRg  (uSTAIRl) uSTAIRfq  (uSTAIRr) uSTAIRgq

Current Proposed  (uLOCKSu) uLOCKSf  (uLOCKSd) uLOCKSg  (uLOCKSl) uLOCKSfq  (uLOCKSr) uLOCKSgq

Current Proposed  (uvSTAIRg) uvSTAIRf  (uvSTAIRf) uvSTAIRg  (uSEALOCKu) uFLOCKf   (uSEALOCKd) uFLOCKg

That's my best thoughts on the matter, at least. VanIsaac (en.wiki) 08:12, 16 December 2023 (UTC)

So here is everyone's comments unified, and all the roots shortened to unique 4-letter names or mnemonics:

Current	Proposed
(uFGATEu)	uGATEf
(uLock5)	uLOCKf
(uLOCKSu)	uLCKSf
(uSTAIRu)	uSTARf
(uSEALOCKu)	uFLCKf

Useddenim (talk) 14:25, 22 December 2023 (UTC)

Perfect! -- Tuválkin ✉ ✇ 01:20, 23 December 2023 (UTC)