Talk:BSicon/Renaming/Roads

And see also:

• User:Circeus/BSicon renaming/Generic: Generic roads
• User:Circeus/BSicon renaming/Red: Autobahns
• User:Circeus/BSicon renaming/Blue: Other motorways (Blue, red, yellow, and white sets)

Default road icons

Moved from Category talk:BSicon/road–rail/crossing

This idea was meanwhile made true. See Category talk:Icons for motorway descriptions/generic/crossing rail

Could we have a set of “default” road icons to be used to illustrated railway diagrams without attempting to partly echo the roaddiagrams themselves? I yearn for a simple, subdued, homogenous set of road icons showing only its width (maybe single, dual and ≥4 lanes?) and surface (paved/dirt). That would allow diagrams to be created when the other info about the crossed roads is not available or is irrelevant. Tuvalkin (talk) 03:15, 14 May 2010 (UTC)

Take a look here. Tuvalkin (talk) 13:52, 14 May 2010 (UTC)

In de-WP we usually don't use any road symbol within BSmaps, maybe that's why I don't like all those colorful icons. I like your idea, it sounds nice, but I fear most projects will insist on having "their color" ... ;-) axp_de^Hello! 12:36, 15 May 2010 (UTC)

I like the de-WP approach, in principle, especially as opposed to reflect road-only info (such as classification about tolling systems, etc.). However often a diagram “needs” to show that a given road crosses the railway here and there, or not, e.g., . Meaningful rail information, I think.

And when we need a generic road icon to use, we have only a plethora of country-specific (and visually emphasised) icons, on which one cannot even chose some from to achive a kind of system, in terms of road width. Cp.   (MWSTRq) (pink), with   (MOTORWAY+BRIDGE) (light blue), with  (AKRZ-UKo) (dark blue), with  (AKRZu) (red+yellow) with  (BROADo) (yellow) and  (KRZuy) (yellow, but uncoherent name). I suppose other might want to make use of a set of generic, neutral looking road icons, lacking any specific semantics.

I’m not happy with the “neutral” icons I created, though. I’ll work more on that. (Done. -- Tuválkin ✉ 02:26, 30 March 2012 (UTC))

Tuvalkin (talk) 20:26, 16 May 2010 (UTC)

Road crossings

Moved from Talk:BSicon/Renaming/Archive 1

moved from en:Wikipedia talk:Route diagram template/Catalog of pictograms/straight tracks

Anyone want to have a go at sorting out this naming mess? Useddenim (talk) 22:35, 7 July 2011 (UTC)

Analysis and coherent renaming proposals here: User:Circeus/BSicon renaming/Non-rail crossings. --Tuvalkin (talk) 22:15, 5 October 2011 (UTC)

(AKRZ-AUKo) (uAKRZ-AUKo) (AKRZ-AUKu) (eAKRZ-AUKu) (tAKRZ-AUKu) (uAKRZ-AUKu) (AKRZ-AUKua) (AKRZ-AUKue) (AKRZ-AUKum)
(AKRZ-UKo) (exAKRZ-UKo) File:BSicon AKRZ-hUKu.svg (AKRZ-hUKu) (AKRZ-UKu) (exAKRZ-UKu) (AKRZ-UKua) (AKRZ-UKue)
(AKRZo) File:BSicon bubAKRZo.svg (bubAKRZo) (exAKRZo) (uAKRZo) (xAKRZo) (hAKRZoa1) (AKRZu) (exAKRZu) (hAKRZu) (uAKRZu) File:BSicon ugAKRZu.svg (ugAKRZu) (uxAKRZu) (xAKRZu)
File:BSicon uAKRZRu2.svg (uAKRZRu2) File:BSicon uxAKRZRu2.svg (uxAKRZRu2) (uAKRZu2) File:BSicon ugAKRZu2.svg (ugAKRZu2) (uxAKRZu2) File:BSicon MOTORWAY+BRIDGE.svg (MOTORWAY+BRIDGE)

(AROADo) (uAROADo) (uAROADu) File:BSicon ugAROADu.svg (ugAROADu) (uHAROADu) (uxAROADu) (uxHAROADu)

File:BSicon BRÜCKEq legende.svg (BRÜCKEq legende) File:BSicon BRÜCKEql legende.svg (BRÜCKEql legende) File:BSicon BRÜCKEqm legende.svg (BRÜCKEqm legende) File:BSicon BRÜCKEqr legende.svg (BRÜCKEqr legende)

(BUE-AUK) (eBUE-AUK)

(KRZun) (KRZuy)

(MWRAILo) (MWRAILu) (hBHFa-MWSTR) (hBHFe-MWSTR)

File:BSicon exhRD1.svg (exhRD1) File:BSicon hRD1.svg (hRD1) File:BSicon exhRD1a.svg (exhRD1a) File:BSicon hRD1a.svg (hRD1a) File:BSicon exhRD1e.svg (exhRD1e) File:BSicon hRD1e.svg (hRD1e) File:BSicon RD1o.svg (RD1o) (RD1u)
(RP1o) (RP1u)

File:BSicon ehRP2.svg (ehRP2) (hRP2) File:BSicon uhRP2.svg (uhRP2) File:BSicon ehRP2a.svg (ehRP2a) (hRP2a) File:BSicon ehRP2e.svg (ehRP2e) (hRP2e) (SKRZ-G2o) File:BSicon exRP2o.svg (exRP2o) File:BSicon vRP2o.svg (vRP2o) File:BSicon xRP2oe.svg (xRP2oe) File:BSicon RP2ow.svg (RP2ow)
(hRP2oRD1) (RP2oRD1e) (hRP2oRP2) (hRP2oW) (RP2oWa) (RP2oWe) File:BSicon hRP2qa.svg (hRP2qa) File:BSicon hRP2qao.svg (hRP2qao) File:BSicon hRP2qe.svg (hRP2qe) (RP2u) File:BSicon evRP2u.svg (evRP2u) File:BSicon evxRP2u.svg (evxRP2u) File:BSicon exRP2u.svg (exRP2u) File:BSicon uRP2u.svg (uRP2u) File:BSicon vRP2u.svg (vRP2u) File:BSicon xvRP2u.svg (xvRP2u) File:BSicon RP2uh.svg (RP2uh) (RP2uhRP2) (RP2uhRP4)
File:BSicon hRP2oq.svg (hRP2oq)

(hRP4) File:BSicon uhRP4.svg (uhRP4) (hRP4a) File:BSicon uhRP4a.svg (uhRP4a) (hRP4e) (SKRZ-G4o)^{(renamed -- Tuválkin ✉ 00:37, 14 May 2012 (UTC))} File:BSicon evRP4o.svg (evRP4o) File:BSicon vRP4o.svg (vRP4o)
File:BSicon exhRP4q.svg (exhRP4q) (hRP4q)
(RP4u) File:BSicon exRP4u.svg (exRP4u) File:BSicon hRP4u.svg (hRP4u) File:BSicon uRP4u.svg (uRP4u) File:BSicon uhRP4u.svg (uhRP4u) File:BSicon vRP4u.svg (vRP4u) File:BSicon xvRP4u.svg (xvRP4u) File:BSicon RP4uh.svg (RP4uh) File:BSicon uRP4uh.svg (uRP4uh) (vSKRZ-G4uh)^{renamed -- Tuválkin ✉ 12:54, 31 July 2012 (UTC)}

reply here. --Tuvalkin (talk) 06:12, 6 September 2011 (UTC)

(WASSER-hUKu) (WASSER-UKu) (WASSER-UKua) (WASSER-UKue)
(GRENZE+WASSER-hUKu) File:BSicon GRENZE+WASSER-UKu.svg (GRENZE+WASSER-UKu) (GRENZE+WASSER-UKua) (GRENZE+WASSER-UKue)

Catalog and “roadmap”

moved to Category talk:BSicon/road–rail/generic road/crossing/catalog

Discussion

Moved from Category talk:BSicon/road–rail/generic road/crossing

Elevated

In the previous version of this overall (re)naming effort, I had made the mistake (see here) of assuming that suffix "h" would not need an "o"/"u" suffix, but of course this is incorrect, as the main track on the icon may go either over or under an elevated road:

• If over,
  • either on a bridge   (SKRZ-G2oh) or
  • elevated itself   (hSKRZ-G2oh),
• if under,
  • either on the surface   (SKRZ-G2uh) or
  • again elevated itself   (hSKRZ-G2uh).

Therefore, suffix "h" always needs to be either "uh" or "oh". -- Tuválkin ✉ 09:23, 13 November 2011 (UTC)

(Re)naming problems

Ideas about the following, please:

•   (hRP2qa) →   (SKRZ-G2quha) →   (SKRZ-G2uhqa)
•   (hRP2qe) →   (SKRZ-G2quhe) →   (SKRZ-G2uhqe)
•   (RP2ow) →   (SKRZ-G2-Lo)
  • Rather  (SKRZ-G2o-L) and  (SKRZ-G2o-R). -- Tuválkin ✉ 00:32, 21 June 2012 (UTC)

Roads across rail forks

I would place things like   (evSTReRP2o) under my "overlay" naming scheme: evSTRe+RP2o (I haven't written it down, but basically: you use a dash to combine what would be two narrow icons, as is done, but a + for icons that overlay two other icons and are not otherwise accommodated, mostly intended for some v- and BHF icons, but works well here). They work fine as is, but I don't like to "merge" roots where it is not a formally "new" base shape (as in the KRZSTR case). Circeus (talk) 17:29, 5 October 2011 (UTC)

For sure you mean evSTRe+SKRZ-G2o, right? --Tuvalkin (talk) 21:18, 5 October 2011 (UTC)

Well, I meant with the scheme you have here. In mine I'd go for a shortcut of evSTRe+G2o. Circeus (talk) 00:03, 6 October 2011 (UTC)

There’s only two schemes: Mine and yours — so I’m taking the forks away from the table above and put them in a new one to reflect your naming proposal, but please clarify one last point: Why evSTRe+G2o and not evSTRe+SKRZ-G2o? Isn’t evSTRe+G2o ambiguous in that it lacks a explicit statement that this is a crossing? For all one knows, evSTRe+G2o could be a superimposition or a line-up of   (evSTRe) and (G2o)… Please advise! --Tuvalkin (talk) 00:55, 11 October 2011 (UTC)

You make a good point. The truly correct name would be evSTRe+G2qo (SKRZ has no business in a + icon, since + already means that you are overlapping them!). My first reaction was that a crossing should be presumed, but you are right that there is NOTHING to prevent a series of mixed icons with a G2 in the middle of a  (vSTR), which would then have naming issues. Maybe we can reverse the normal system for those cases, with the + (which indicates an overlapping of icons) presuming a crossing in the case of rail, and -g used (as elsewhere) to indicate a vertical parallel line? Circeus (talk) 01:56, 11 October 2011 (UTC)

 Done above --Tuvalkin (talk) 04:42, 11 October 2011 (UTC)

Elevated roads under track?

I have been wondering if it is necessary to preemptively allow the naming scheme for elevated roads under the rail line — for which it would be necessary to disambiguate the suffixed "h", replacing it with either "uh" or "oh". --Tuvalkin (talk) 21:18, 5 October 2011 (UTC)

You mean unelevated vertical rail over elevated road? I say it's safe to keep the base as SKRZ-G2h ("h" being assumed to be on top unless both are elevated) and only make that special case into SKRZ-G2oh. Circeus (talk) 00:00, 6 October 2011 (UTC)

I mean both elevated — necessarily one above the other (hm, is there need for elevated flat/level crosses?). So far I only come across with cases where the rail track is above the road (with a single exception that could be done with a regular bridge  (uhSKRZ-G4u)), but for sure both cases are equally often. --Tuvalkin (talk) 03:16, 6 October 2011 (UTC)

(I suspect that “unelevated” is a line running on a trench   (CUT).) --Tuvalkin (talk) 03:16, 6 October 2011 (UTC)

No, I understood the base line (i.e.  (STR)) over an horizontal elevated highway, so i was confused. I think in your scheme that would simply be   (hSKRZ-G2uh)^{(fixed from "G2hu" -- Tuválkin ✉ 03:11, 28 June 2012 (UTC))} as per  (hKRZhu), with -h suffixed regularly to indicate that the crossing feature is also elevated. I'm not where the issue is at all, really (I think I need to make sure I formalize rules for suffix ordering *sigh*). Circeus (talk) 03:27, 6 October 2011 (UTC)

 Done! (or at least pushed further on the right way). -- Tuválkin ✉ 12:35, 13 November 2011 (UTC)

Mixed set

moved from User_talk:Tuvalkin#RP.23_requests

Hey, wondering if you could entertain a few requests for your RP# icons? Namely mixed equivalents of   (vRP2o),   (vRP2u),   (vRP4o) and   (vRP4u) with blue on the left. (Not sure if those are best named as m- form or compounds... I'm not a big fan of compounds just because the line colors differ.) Circeus (talk) 15:34, 28 September 2011 (UTC)

Done (assuming you mean the left of the train driver):

•   (mvRP2o)
•   (mvRP2u)
•   (mvRP4o)
•   (mvRP4u)

I’m not that hot about the names, either, but at least this is consistent with  (mvSTRgl) and several such others, and can be changed in a batch whenever better naming conventions arise. (Meanwhile there’s   (buSBRÜCKE) and a few other thus named…) --Tuvalkin (talk) 19:55, 28 September 2011 (UTC)

Nevermind, I too have just discovered that altering BSicon is pretty easy. Circeus (talk) 18:56, 28 September 2011 (UTC)

Bummer. --Tuvalkin (talk) 19:55, 28 September 2011 (UTC)

But yes, it is easy, and even fun! More so if the SVG code is clean and clever. --Tuvalkin (talk) 20:17, 28 September 2011 (UTC)

I'm sure your icons (which unfortunately had reversed colors to what I needed) will find use soon. Circeus (talk) 20:03, 28 September 2011 (UTC)

Yes, for sure. Sorry about the left/right mixup. Tell me the names of the ones you created?

•   (umvRP2o) ←   (vuRP2o-RP2o)
•   (umvRP2u) ←   (vuRP2u-RP2u)
•   (umvRP4o) ←   (vuRP4o-RP4o)
•   (umvRP4u) ←   (vuRP4u-RP4u)

Not here above. --Tuvalkin (talk) 20:17, 28 September 2011 (UTC)

I used the dashed names:   (vuRP2u-RP2u),   (vuRP2o-RP2o),   (vuRP4u-RP4u) (the dashes on this one are not good, they were taken from   (vRP4u)),   (vuRP4o-RP4o), since I'm not quite ready to start messing up icon names in new ones. Circeus (talk) 20:30, 28 September 2011 (UTC)

Okay, great. I hope the names will be homogenized soon enough.

• It would have been sweet if you had maked your new images as derivatives: Public domain doesn’t mean anonymity, and following the lineage of a given icon is interesting and often useful.
• I also added categories to your images: Lots of goodies now atCategory:Icons for railway descriptions/set mixed/parallel railways/crossing road [now Category: BSicon/road–rail/set mixed/generic road/parallel lines/elevated/crossing].

--Tuvalkin (talk) 00:32, 29 September 2011 (UTC)

Unpaved bridges?

Icons  (SKRZ-GDu) and  (uSKRZ-GDu) come from being combinatory at creating these, but they make NO sense. If there is a bridge for a path, it is paved by its very nature — the bridge platform is artificial, and that counts as pavement. The only border cases are, I think, only when a dirt track goes through a bridge, see case 1, or when a path goes over a really short tunnel (or over a natural arch), see case 2. Therefore, I wont create any more RD1u nor RD1h icons, and will reduce the rail×dirt area of the table above to one single column ("o"). -- Tuválkin ✉ 16:50, 15 November 2011 (UTC)

Sorry to barge in here years later, but growing up in a forested area, with lots of old logging roads around, the idea of an unpaved bridge makes perfect sense to me. Specifically, I think of old timber bridges, and Bailey bridge-style crossings, where the deck is fitted grates or metal plates, instead of any kind of pavement. The grate decks especially tend to get clogged up with gravel and eventually just become a gravel surface bridge. Vanisaac (talk) 09:59, 13 August 2013 (UTC)

That’s a good point. -- Tuválkin ✉ ✇ 14:03, 18 March 2017 (UTC)

Natural arches

(Added a better rendition of “natural arches” but Commons doesn’t do multiple overlays — really gotta keep all these templates in synch! I repeated it at the right side, pathlessly: it is just this overlay  (lDSTR※ tSTRq) ) -- Tuválkin ✉ 15:19, 20 November 2011 (UTC)

Was: "{{BS4||tSTRq|O2=RD1|O22=lDSTR|ABZrxl|extSTRq|O4=lDSTR|PX=60px}} ") -- Tuválkin ✉ 17:13, 4 May 2012 (UTC)

Here → a new attempt at a natural arch with railway going through it and a foot path above — which is better? (Only one overlay on each icon, too.) -- Tuválkin ✉ 17:13, 4 May 2012 (UTC)

Notes

• * - as of 2011.09.06; auto-generated name — see any unschematic name in remarks
• ᵗ - as per Tuvalkin’s proposal

Icons for track crossing generic road

Moved from Talk:BSicon/Renaming/Archive 1

detailed renaming proposal here: Category talk:Icons for motorway descriptions/generic/crossing rail

See also en:Wikipedia:Route diagram template/Catalog of pictograms/generic roads. Useddenim (talk) 00:56, 12 December 2011 (UTC)

Concerning the generic road icons RP2, RP4, etc., wich were (are being) created mostly by me, there’s a basic naming problem I plan to adress soon. It will be necessary to separate clearly, by changing the root names, between purely road-only icons (although also use in rail diagrams), and those featuring crossing of road and track. One of these two families will have to be bulk renamed, perhaps RPn → QPn (next letter in the alphabet, and unused), probably the crossing set, as it is more used and thus renaming bots could be prevented from causing  (CONTr)-like havoc.

The new naming paradigm will be thus: Based on any (concievable) regular track icon fooROOTbar, its crossing with a road of n lanes will be ilustrated by an icon named fooQPnxbar (or QD instead of QP for unpaved roads), with 'x being either "o" (road on bridge above track*), "u" (track on bridge above road*), or "h" (road elevated above track). Comments welcome!

(The remaining messy names of road-only icons I’ll address later.)

--Tuvalkin (talk) 06:12, 6 September 2011 (UTC)

On a second take, probably it is the road-only icons that should be renamed RPn → QPn, as so far in my assessment most rail/road crossing icons are already properly named as outlined above (minus the R→Q change). --Tuvalkin (talk) 06:31, 6 September 2011 (UTC)

no. Definitely the rail icons ought to be   (KRZ-RPX) to follow the standard KRZ-SUFFIX pattern (at least that's what I intend to have in my incoming renaming proposal). Circeus (talk) 16:07, 6 September 2011 (UTC)

Is there a standard for road crossings? Is seems to be scarcely used, glancing the list above. Anyway, an icon name with a "-" usually spells out assymetric parallel railways, I cannot see how is it wise to apply it here: It seems to be   (-ELEV) all over again. But, if   (KRZ-RPX) is the way to go, it is for me the same renaming trouble as   (QPn) would be — all I wanted was to go by your proposal about ROOT names no exceeding 4 characters. --Tuvalkin (talk) 22:19, 6 September 2011 (UTC)

Check here for Circeus’ new and improved renaming proposal. I’m gonna reflect it at Category_talk:Icons_for_motorway_descriptions/generic/crossing_rail#Renaming ASAP. --Tuvalkin (talk) 19:17, 4 October 2011 (UTC)

Bridge PoV

I wrote above about the final suffix that it could be either

• "o" (road on bridge above track),
• "u" (track on bridge above road), or
• "h" (road elevated above track).

This use of o/u doesn’t agree with the common practice, and I'm swapping it. It makes sence in the way that if a h suffix refers to the road being high (as the elevated track gets preffixed for it), then the over/under suffixes should also follow this — but is is not intuitive when taking in account the track as such, which is more important. --Tuvalkin (talk) 01:27, 7 September 2011 (UTC)

I think the problem is that BSicons are designed from the viewpoint of a vertical railtrack and everything else that is tacked on top or forced into the system must be inserted "around" the existing icons (e.g. the g- prefix of waterways), and anything with rail must be named as a rail icon, not a footpath/waterway/road icon. If you start writing -u/o relative to the horizontal road you're unnecessarily throwing everything out of whack.

As to the issue of separating crossing icons vs. road-only icon (I hadn't figured it earlier), I still think the KRZ-RD (which melds better with existing crossing stuff) is the way to, because these are railway icons before being road icons, as annoying as it may feel. Circeus (talk) 03:53, 7 September 2011 (UTC)

Missing and wrong designs

Moved from Talk:BSicon/Renaming/Archive 2

moved from User talk:Useddenim I note that   (BUE2) is a very strange icon since its road design is unused anywhere else. Its prime user is cs.wp (with a few isolated uses on en:, hu: and pl:), which also makes generous use of the  (RP2) series, which clearly correspond to the design here. Do you think the icon should be redone to match an actually used crossing road? Circeus (talk) 05:10, 3 September 2011 (UTC)

More in line with the GRENZE example above, the icons  (uxAKRZu),   (uAKRZu2),   (uxAKRZu2),   (utAKRZu2),  (uAKRZRu2),   (uxAKRZRu2) are originally waterway icons for british roads, an in that regards, have no business being different from (respectively) the   (uAROADu) and  (AKRZ-UKu) sets of icons (especially given that their name cause issues with the German AKRZ icons!). Redesigns are in order for the blue icons (I'm working, as you noticed, on a full-scale naming scheme proposal, so I won't suggest a move as of yet). Circeus (talk) 05:32, 3 September 2011 (UTC)

How about moving all talks to Talk:BSicon? User talk pages are not the best place for strategic talks! Btw. "uGRENZE" is a leftover of the move to "ueGRENZE", but there are still dozens of links to be fixed ... a×p_de^Hello! 12:13, 3 September 2011 (UTC)

 Done Useddenim (talk) 19:35, 3 September 2011 (UTC)

Thanks my friend, I have planned to do this for weeks but no time! a×p_de^Hello! 22:51, 3 September 2011 (UTC)

And now you get to clean out your talk pages! Useddenim (talk) 23:22, 3 September 2011 (UTC)

h or no h?

Moved from Talk:BSicon/Renaming/Archive 3

Compare:
  (RP2oWa) vs  (hRP2oWaq) and
  (RP2oWe) vs  (hRP2oWeq). Useddenim (talk)14:14, 20 September 2012 (UTC)

(And compare either with  (hRP2oW).) -- Tuválkin ✉ 15:28, 21 September 2012 (UTC)

Good question. While I confess that I didnt introduce that naming incongruence on purpose, both approaches can be argued for and have analogous cases in track icons, such as  (exhACCa) vs.  (BRÜCKEa).

I would favour always using "h", even in situations that it is a pleaonasm ("o" already indicates a bridge and "a"/"e" that it extends), unless there’s a good reason not to.

-- Tuválkin ✉ 15:28, 21 September 2012 (UTC)

Well, I'm of the opinion that the simpler approach would have been to make  (BRÜCKEa) into a h- name instead  (hSTRa). Indeed now that RPx is no longer the base root used for rail-road crossing the -oW suffix is mostly superfluous: if we substitute RPx for STR, these icons are (on the pattern of  (hWSTR)):

•   (RP2oWa) →   (hWRP2a) ( (WBRÜCKEa) →  (hWSTRa) and so on)
•   (RP2oWe) →   (hWRP2e)
•  (hRP2oWaq) →   (hWRP2aq)
•  (hRP2oWeq) →   (hWRP2eq)
•  (hRP2oW) →   (hWRP2)

Circeus (talk) 22:04, 22 September 2012 (UTC)

Renaming process

Moved from Talk:BSicon/Renaming/Archive 3

I started finally to rename the road/rail crossings from RPn to SKRZ-Gn. So far two of the busiest,  (SKRZ-G2o) and  (SKRZ-G4o) are replaced in the diagrams in use, in several wikipedias (leaving a few catch-all pages, as intended). However I see that they both are still linked from many other commons pages, due to the derivatives' links — unlike the use in diagrams, these are called by full name and as such could be relinked by bots. Yet they are listed (along many other BS icons) at User:CommonsDelinker/commands/byHand. This means that all BSicon use should be relinked by hand when renaming, when for actual occurrences of the full filename (as opposed to template calls)? That seems to be needlessly demanding of us humans. -- Tuválkin ✉ 00:56, 14 May 2012 (UTC)

I believe that all BSicon renaming requests are tagged "by hand" by default, specifically because bots can't handle the short-form links in the templates. Would it be possible for someone to create a bot that can tell the difference between a full-name link and a template link? Useddenim (talk) 12:44, 14 May 2012 (UTC)

Well, I believe that usual file-renaming bots don’t even notice that the BS templates are calling those SVGs at all, so we should just use them to delink/relink wherever BS icons are used in the usual way images are in wp, and mannually fix what is not catched by the bots. -- Tuválkin ✉ 08:21, 15 May 2012 (UTC)

I removed that request to treat all BSicon delinking «by hand», so that uses in file pages need not to be done manually. But most usage is in diagrams, called by templates by partial filename, and thus invisible to the delinker bot, so of course we should always check global usage and here-links (and fix them manually) before requesting a deletion. -- Tuválkin ✉ 13:59, 2 January 2013 (UTC)

Renaming

Moved from Category talk:BSicon/road–rail/crossing

If no one objects, I am going to rename the red/yellow and blue highways into Tuvalkin (talk · contribs)'s "R" set:

RD1	RP1	RP2	RP4	RPA	RPM
				= Road Paved Autobahn/ Autoroute/ Autostrada	= Road Paved Motorway

Useddenim (talk) 00:19, 24 October 2012 (UTC)

I’m very touched. *.*

Seriously, all standardization is good — but maybe before you go ahead and rename, maybe the RPA family should be checked for what’s exRPA and what not? Because I’m not sure that the difference between, say,   (MWSTRq) and  (MROADq) is intentional… -- Tuválkin ✉ 12:59, 24 October 2012 (UTC)

Since there's only eight unique (12 total) red icons, I'd just convert them all to pink.
See User:Circeus/BSicon renaming/Red and User:Circeus/BSicon renaming/Blue for the full catalogue. Useddenim (talk) 17:06, 24 October 2012 (UTC)

Oops—I forgot about all of the AKRZ icons. I think they tilt the count in favour of red instead of pink. Useddenim (talk) 03:32, 25 October 2012 (UTC)

Question: I was under the impression that the plan was to ultimately use the G-roots (GU, G1-G4) for the RD and RP1-4 names? Tuvalkin was already using these for the new SKRZ icons (which are the expanded form for AKRZ:  (AKRZu) ->  (SKRZ-G1u)). I never got as far as to figure out a good naming scheme for the more complex icons, but I don't think it's be too hard (a great many can be dealt with by expanding the -Gx suffix to all railway roots:  (RP2xRP2) -> KRZ-G2;  (RP4wns) -> ABZ-G4l+fg).

There are in fact several more different road crossing icons in use that belong in this series: User:Circeus/BSicon_renaming/Non-rail_crossings. This is why I came up with the SKRZ-xxx scheme.

Circeus (talk) 22:20, 25 October 2012 (UTC)

So, then:

-GU	-G1	-G2	-G4	-GA	-GM	-GN	-UA	-UB
				= Generic Autobahn/ Autoroute/ Autostrada	= Generic Motorway	= Generic uNspecified	= UK A road	= UK B road

Useddenim (talk) 23:28, 25 October 2012 (UTC)

I’m all for consistency and standardization in naming, but the set is meant to be self-sufficient in describing roads. Therefore the blue and the pink sets should keep names that do not bundle them at the same level as those 4 “generic” profiles. Pls read the intro of Category:Icons for motorway descriptions/generic — it is meant to show only how a road more-or-less looks like (number of lines and type of paving), not its classification and tolling regime. Even if the pink and the blue sets cannot be readily pinned to a given country roadmap tradition, use an "X" or any other letter, and leave the "G" for those four.

As for renaming things like  (RP2xRP2) to KRZ-G2, I’m not frontally against, but the relative merits of that should be discussed in Category talk:Icons for motorway descriptions/generic. (I.e., whenever there's a rail stretch in one of these road icons, rail nomenclature prevails, when not, lets go easy on the renamings.)

-- Tuválkin ✉ 02:31, 26 October 2012 (UTC)

I just wanted something simple and consistent... Useddenim (talk) 03:37, 26 October 2012 (UTC)

Wih non-generic road, I was using a letter followed by the country code for the primary users of that icon:

Proposal 1
-GG	-ADE	-MUK	-AUK	-BUK	-FNO
= Generic, Green	= AutoXXXX/ A-Road, German	= Motorway, UK	= AutoXXXX/ A-Road, UK	= B road, UK	= Fylkesvei, Norway
Proposal 2
-GG	-1DE	-1UK	-2UK	-3UK	-3NO
= Generic, Green	= lvl 1 roads, Germany	= lvl 1 roads, UK	= lvl 2 roads, UK	= lvl 3, UK	= lvl 3, Norway

I'm not clear what the Green icons were supposed to represent, but they are currently used in various ways on several projects. The odd -n icon is overwhelmingly used by the scandinavian projects. This schemes gives a ready, relatively easy way to set up eventual other systems (i.e. -AUS and -MUS would easily fit US roads and interstates respectively). If one wanted to make it even MORE general, you could define Highways as lvl 1 in a descending hierarchy that each country adapts by substituting or adding a lower level to. The only problem with that is that it leads to conflict in what the number means for generic and national icons. Circeus (talk) 16:30, 26 October 2012 (UTC)

Similar looks

Moved from Talk:BSicon/Renaming/Archive 6

moved from en:Wikipedia talk:Route diagram template

looks like

-DePiep (talk) 00:43, 4 June 2013 (UTC)

Well yes it does, sir! (Of course, it would help if you told us which two icons you are comparing.) Useddenim (talk) 11:57, 4 June 2013 (UTC)

I would rather say we have four pairs of identical icons presently in Category:Icons for motorway descriptions/Simple. I have no idea whether "AROAD" is a proper name, but "AKRZ" certainly is not - I'm unable to see any crossings in those icons! YLSS (talk) 13:53, 4 June 2013 (UTC)

They are subtly different in appearance, but very different in construction.  (AKRZlg) is drawn as two ‎<circle>s having a common centre and radius - although it relies on the edges of the drawing area to crop the circles to quarter-circles, this does mean that the final shape extends exactly to the edges.

By contrast,  (AROADlg) uses a pair of ‎<path>s, and within those, an elliptical arc curve command. Unfortunately, the values supplied a240,240 90 0,1 250,250 mean that the quarter-circles have a radius that is too small, are not centered on a corner, and stop short of the edges of the drawing area. If you view it at 2000px, you'll see a thin wedge at each end.

I would keep  (AKRZlg) and redirect File:BSicon AROADlg.svg to it. --Redrose64 (talk; at English Wikipedia) 11:19, 6 June 2013 (UTC)

 Agree. This should also apply to  (AKRZrg)/ (AROADrg),  (AKRZrf)/ (AROADrf) and  (AKRZlf)/ (AROADlf). Useddenim (talk) 12:29, 6 June 2013 (UTC)

It would be better to delete the "AROAD" family then, and move the "AKRZ" family to their former places (or to some other name). YLSS (talk) 13:30, 6 June 2013 (UTC)

I saw that uexABZu had been replaced by uxABZu, and have fixed all the UK templates, plus one on CY:Wicipedia. I am not sure what to do about some of the US ones, which I assume have also changed as a result of this mod. Bob1960evens (talk) 17:07, 17 June 2013 (UTC)

moved from User talk:Useddenim:
Hi, I note that BSicon_uexABZu has become BSicon_uxABZu, and I have fixed most of the UK canal templates, so that the roads are the same colour whether they cross navigable water or unnavigable water. However, en:Template:Neath and Tennant Canal map uses Wasser icons, and  (MWWBRÜCKE1q1) and  (MWBRIDGE) now show the roads in x- colour, rather than the normal colour. I have no idea what the name of the proper icons should be, nor can I find where they are listed. Regards. Bob1960evens (talk) 17:44, 17 June 2013 (UTC)

I guess my actions deserve some explanation... I have no idea how this came to pass, what is the difference, and what solutions have been proposed, but the fact is that there are two families of "highway" icons: the more common "bright" one (like  (MROADq) - does *  (MROAD) even exist?) and the more populated "dull" one (like   (MWSTR)). Railroad crossings, however, existed only for the "bright" ones, plus the oddly named   (MWRAILo) &   (MWRAILu), and I needed the dull ones over "u" lines. Seeing that 1) there were already several icons in existence that used "x" rather than "ex" for road crossings (e.g.   (xBROADo) &   (uxSKRZ-MUKu)); and 2) some wikis (pl.wp for certain, and some others) have employed the "dull" family to represent crossings of planned/constructed roads, I decided to extend this pattern. That is, as can be seen here, zero prefix stands for a "bright" road & normal railway/canal:  (uAKRZu); "x" is for "bright" road and non-existent railway:  (uxAKRZu); "e" for "dull" road and normal railway:  (ueAKRZu); and "ex" for "dull" road and non-existent railway:  (uexAKRZu). Maybe not the best solution, but at least explicable, especially with regards to the lack of any other coherent naming scheme.  (uexAKRZu) was the only one in the "u" set that necessitated heavy renaming/updating; and being quite lazy (and unwilling to indulge in excessive editing), I decided to update only those templates that showed both "bright" and "dull" roads. If the fact that in the remaining templates the roads suddenly darkened seems detrimental to you, well, by bad, please accept my apologies, I did not consider this to be a potential problem... WRT to  (MWWBRÜCKE1q1) and  (MWBRIDGE), I did not change anything; but there is also  (MWWBRÜCKE1q). YLSS (talk) 20:51, 17 June 2013 (UTC)

AFAIK, all of the oddball non-standard road icons are displayed at en:WP:Route diagram template/Catalog of pictograms/other roads. Useddenim (talk) 23:36, 17 June 2013 (UTC)

(Most puzzlingly. Could you integrate it somehow? YLSS (talk) 09:28, 18 June 2013 (UTC))

Not ready for prime time; certainly not up to the standard and format of the other catalog pages. Wanna have a go at it? Useddenim (talk) 03:51, 19 June 2013 (UTC)

Concerning the root ID rename of these, please note that the generic road crosses were renamed to "SKRZ" as per Circeus’ proposal, in the assumption that all other road crosses would too. -- Tuválkin ✉ 18:13, 17 June 2013 (UTC)

See also Talk:BSicon/Icon geometry and SVG code neatness#Red roads concerning line colours and width. Useddenim (talk) 01:22, 18 June 2013 (UTC)

Road crossings

Moved from Talk:BSicon/Renaming/Archive 7

moved from User:Circeus/BSicon renaming/Non-rail crossings

I must admit, such names as SKRZ-ADEu scare me quite a bit, mainly due to their length. Moreover, as pointed out above, these icons are used in different Wikipedias, regardless of their original background: not only have the  (KRZuy) &   (KRZun) been widely used in no.wp, but also   (uAKRZ-AUKu) appears in zh:Template:海珠区有轨电车RDT. In addition, when I read SKRZ-AUKo, I firstly think about Australia, not the United Kingdom ;) So I say, let's go more WYSIWYGgy:

•   (uAROADu) →  (uSKRZ-Ru) ("red")
•   (uAKRZu2) →  (uSKRZ-Bu) ("blue", with  (AKRZ-UKu) to be recoloured)
•   (uAKRZ-AUKu) →  (uSKRZ-Gu) ("green", unless there is a risk to confuse with various "Gn"/"GD" for "generic")
•  (uKRZuy) →  (uSKRZ-Yu) ("yellow")
•  (uKRZun) →  (uSKRZ-Eu) (at least with the current design, it's "empty", not "white" – at let's leave it like that, can be used in overlaying)
•  (uAKRZu) →  (uSKRZ-Au) (could be something like "orange", but probably better to retain "A").
•  (ueAKRZu) → uSKRZ-DuuSKRZ-Mu ("darkened"/"dull": although I have previously dabbled myself with the idea that these roads are an "ex" version of A-roads, it would simplify things if we just select a single letter and postulate that roads can't be "ex'ed", just like rivers. Alternative: "-M", from the MWROAD. Nope, this way we would get RD which is too close to  (RD1), so indeed better to retain "-M" from "motorway". ^{09:28, 16 December 2014 (UTC)})

I'll start with ugKRZun →  (gSKRZ-Eu) & ugKRZuy →  (gSKRZ-Yu) (they are to be renamed in any case). Stop me, if anyone protests. YLSS (talk) 11:27, 29 May 2014 (UTC)

---

In case somebody doesn't watch the concerned pages, I have left a note at User:Circeus/BSicon renaming/Non-rail crossings#Suffixes a couple of days ago. ^{Moved it here for clarity. 14:07, 22 December 2014 (UTC)} Any corrections are more than welcome. However, I have already implemented that scheme while migrating the "ug" → "g" icons. At least Category:Icons for railway descriptions/set g/crossing road now looks pretty uniform. YLSS (talk) 09:49, 1 June 2014 (UTC)

I'm fine with your idea. It's more straightforward than the mess I originally proposed. Circeus (talk) 04:02, 5 June 2014 (UTC)

---

UPD. Some new or renamed icons with can cast more light on the new (old) naming scheme:

•  (RM)  (RMxRP2)
•  (RAq)  (RAe)  (RAw)  (tvSKRZ-A)   (exSKRZ-Aha)  (vSKRZ-Ah)  (hRAoWeq)
•  (RYl)
•  (RBoWq+ZOLL)  (DRBq)

-- YLSS (talk) 14:07, 22 December 2014 (UTC)

Crossing over roads

Moved from ‎Talk:BSicon/Renaming/Archive 8

With regards to crossing over roads (see enWP gallery), is there an agreed nomenclature for closed road variants? Compare  (exSKRZ-Ao),  (exAKRZo) and  (evSKRZ-Ao). Also, are the icons supposed to belong in this category, this one, or both?   ~ Newfitz ^Yo! 07:23, 28 June 2016 (UTC)

1. The standard nomenclature is that the e prefix indicates the secondary feature (the crossed road) is out of use, while the x prefix indicates the primary feature (the railway) is out of use.
2. Yes, both Category:Icons for motorway descriptions/RA/crossing rail and Category:Icons for railway descriptions/crossing road. (Despite some opinions to the contrary, over-categorization is better than under-.)
3. With respect to parallel lines, the left and right lines are primary and secondary, so the possibilities become:

	Both lines in use	Left line out of use	Right line out of use	Both lines out of use
Road in use	(vSKRZ-Au)	(evSKRZ-Au)	(xvSKRZ-Au)	(exvSKRZ-Au)
Road out of use	(vSKRZ-Axu)	(vSKRZ-Axu)	(vSKRZ-Axu)	(vSKRZ-Axu)

Useddenim (talk) 00:15, 29 June 2016 (UTC)

Actually, scratch that. I've just found that the off-color roads () uses  (SKRZ-M) instead of  (SKRZ-A). Though the backlog still seems extremely terrible and I have no naming schemes for all of them at the moment.   ~ Newfitz ^Yo! 07:14, 30 June 2016 (UTC)

Coloured road–rail crossings

Moved from Talk:BSicon/Renaming/Archive 9

Are   (SKRZ-G4u cerulean+) and   (SKRZ-G4uq cerulean+) valid icon names? Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me 07:12, 27 November 2016 (UTC)

I would say they are, as the trailing hanging + indicates that the secondary “line” (in the case the road) is in its default color (which it is, thank the stars, and lets keep it that way!).

Likewise, a leading hanging + indicates that the primary “line” is in its default color. This was agreed upon back when we claned up all those “other” colors. Recently created icons such as   (vBHF sky-dBHF yellow) should be named instead   (vBHF-dBHF yellow+sky), etc.

-- Tuválkin ✉ ✇ 09:28, 27 November 2016 (UTC)

@Tuvalkin: Should   (vBHF sky-dBHF yellow) have the same geometry as  (vBHF-exBHF) (and then be named mvBHF yellow+sky)? (Incidentally, should icons like  (exvBHF-uBHF) be renamed exmvBHF or similarly?) Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me 10:34, 27 November 2016 (UTC)

I’d say that the only time the half-moon geometry is appropriate would be when an existing station is being expanded in some way; eg  (vBHF-uexINT)  which could indicate a new transit line being built adjacent to an existing rail line.

I believe the consensus was that the m prefix is only used when both features were identical except for colour. (I also thought that all existing were moved to the long-form names, with redirects.) I agree, however, with + renaming.

Finally, you might not be hearing from Tuvalkin until 11:59, 4 December 2016 (UTC). Useddenim (talk) 13:06, 27 November 2016 (UTC)

@Useddenim: So  (mvBHF black+orange) and  (exvuBHF-BHF) → uexmvBHF (like  (uexmlvBHF)) but mvBHF-exBHF +green? Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me 13:30, 27 November 2016 (UTC)

A cautious “Yes”, but I think it’s necessary to reexamine the discussion to check whether the m prefix only applies to plain/u/f/g combinations, or all colours. Useddenim (talk) 13:44, 27 November 2016 (UTC)

@Useddenim and Tuvalkin:  (SKRZ-G4u red) or   (SKRZ-G4u cerulean+)? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:34, 30 January 2017 (UTC)

No + necessary, as there is only one colour on this icon. Useddenim (talk) 10:54, 30 January 2017 (UTC)

Renamed both set cerulean icons. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:23, 30 January 2017 (UTC)

Road crossing

Moved from Talk:BSicon/Renaming/Archive 9

What should  (fAKRZ-Lo) and  (fxAKRZua) be renamed as? Normally we would use -L but we can't do that with road crossings… fSKRZ-Ao-G? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:01, 5 March 2017 (UTC)

More station–road crossings

Moved from Talk:BSicon/Renaming/Archive 9

  (hBHFCCee+SKRZ-Ao-L ochre),   (hBHFCCee+SKRZ-Ao ochre),  (hBHFa+AKRZo ochre),  (hBHFe+SKRZ-Ao ochre)? At the very least these should be hBHFCCe and SKRZ-Mo. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 15:54, 5 March 2017 (UTC)

Road crossing with station

Moved from Talk:BSicon/Renaming/Archive 11

As with  (hBHFa+AKRZo ochre) (currently incorrectly named due to the AKRZ), I think  (uhBHFaeq+vRP1) needs a rename, partly since it should be possible to name it with one root, and also because the current name's order implies the road is above the station. Would uhSTBHF-G1vaeq or uSTBHF-G1voq (STBHF derived from SKRZ/TBHF) work for the latter? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 16:30, 1 August 2017 (UTC)

RP2 divided curves

Moved from Talk:BSicon/Renaming/Archive 11

Can the following files can be renamed, consistent with railway and other road curves? Would this be the correct convention?

•  (vRP2rg) to  (vRP2+l), like  (STRrg) to  (STR+l)
•  (vRP2lg) to  (vRP2+r), etc.
•  (vRP2rf) to  (vRP2r)
•  (vRP2lf) to  (vRP2l)
•  (v-RP2rg) to   (v-RP2+l)
•  (v-RP2lg) to   (v-RP2+r)
•  (v-RP2rf) to   (v-RP2r)
•  (v-RP2lf) to   (v-RP2l)
•  (vRP2rg-) to   (vRP2+l-)
•  (vRP2lg-) to   (vRP2+r-)
•  (vRP2rf-) to   (vRP2r-)
•  (vRP2lf-) to   (vRP2l-)

epicgenius (talk) 03:00, 18 February 2018 (UTC)

@Epicgenius: Yes, except  (v-RP2rg) etc. should be v-RP2+lf like  (v-STR+lf). (Most of the other road curves, incidentally, are consistent, except for those which weren't moved because of icons like  (RP2r), which should have been renamed but no one's bothered to yet. Probably RP2d or something, per this discussion.) Jc86035 (talk) 07:59, 18 February 2018 (UTC)

@Jc86035: I'm confused. So should  (v-RP2rg) go to  (v-RP2+lf), or   (v-RP2+l)? Like this:

•  (v-RP2rg) to  (v-RP2+lf)
•  (v-RP2lg) to  (v-RP2+rg)
•  (v-RP2rf) stays the same
•  (v-RP2lf) to  (v-RP2lg)
•  (vRP2rg-) to  (vRP2+rf-)
•  (vRP2lg-) to  (vRP2+lg-)
•  (vRP2rf-) stays the same
•  (vRP2lf-) to  (vRP2lg-)

Then an admin will need to move two of these, because the file names are already occupied. epicgenius (talk) 14:52, 18 February 2018 (UTC)

@Epicgenius: Probably, yes. JJMC89 bot replaces redirect usage so after a day or two it should be possible to delete the two redirects. I'll move the four other files. Jc86035 (talk) 15:00, 18 February 2018 (UTC)

Roads

Moved from Talk:BSicon/Renaming/Archive 12

@Useddenim, Tuvalkin, and Epicgenius: Module:BSicon has informed me, by throwing an error on the 55 files I uploaded with a title containing RR, that I've accidentally created a naming conflict issue by allowing the modifier suffixes to be combined:  (RR) is a valid root, as are  (RG) and  (TRR). Should we do anything about this? There are only about 90 TRR, RG and RR icons combined, so one option would be to rename all of those icons. Jc86035 (talk) 18:54, 11 July 2018 (UTC)

• The road icons are the ones that should be renamed, in my opinion. -- Tuválkin ✉ ✇ 21:19, 11 July 2018 (UTC)

@Jc86035: Aside from the fact that this is a case of “You broke it; you fix it”, I’m still trying to figure out what the -~LL and -~RR suffixes are supposed to mean. I think you need to expand the explanatory table to help us all with the compound suffixes that you’re now introducing. But I agree with Tuvalkin that the red and green roads can be renamed; but what would you propose for the Traverser/Transfer table icons? Useddenim (talk) 23:22, 11 July 2018 (UTC)

@Jc86035: Out of curiosity, what do these conflict with? epicgenius (talk) 00:47, 12 July 2018 (UTC)

@Epicgenius and Useddenim:  (hv-STR+1~RR), among others. I did this because the +L/+R suffixes were made redundant by extending the tilde suffixes to ~RR/~LL respectively (same for F/G), and it would be more confusing to have some of the transform suffixes go the wrong way.  (hdSTRr+1-) –  (hdSTRr+1-~F) –  (hdSTRr+1-~FF). It would already have happened earlier because I renamed the KBF icons to  (uBHF+r@GG) (metro big station on curve from right with station moved back twice) and so on. Jc86035 (talk) 04:55, 12 July 2018 (UTC)

I reused the + suffixes for the old-style formations that are perfectly against the icon edge (leer+hl →  (lhSTR+L)). Jc86035 (talk) 05:14, 12 July 2018 (UTC)

TRR could become TRV. RG and RR could use some other arbitrary letter, although A, B, D, E, M, P and Y are taken, and we probably shouldn't use something which is already an affix (A, C, D, F, G, K, L, M, R, S, T, W, X). Alternately, we could change all the roads to use three-character roots to avoid syntactical problems which were bound to come up at some point. Jc86035 (talk) 05:27, 12 July 2018 (UTC)

Suggestion:

Existing	(RD1)	(RP1)	(RP2)	(RP4)
Proposed	(RPH)* (RA)	(exRPH)* (RM)	(RPB) (RB)	(RPR) (RR)
	(RPG) (RG)	(RPWq) (REq)	(RPYq) (RYq)

* H = Highway – Useddenim (talk) 12:20, 12 July 2018 (UTC)

• I could go with Useddenim's suggestion, since it still uses the root "RP". epicgenius (talk) 12:31, 12 July 2018 (UTC)

@Useddenim: I was actually thinking about renaming RP[1-4] before this, since it's not a logical sequence (RP4 should logically have three dashed lines). [Like this: (RP2※ RP4) ?^{Useddenim (talk) 16:52, 12 July 2018 (UTC)}] Perhaps

• RD → RPD
• RP1 → RPS ("unclassified" / "single")
• RP2 → RPP ("paved" / "painted")
• RP4 → RPV ("divided")

and then (3), (3,2) could be optionally used for indicating lane numbers for P and V respectively, and (2,1-1,2) could be used to indicate transitions like  (RP2112). (There's a possibility that someone might want more than nine lanes, although if there's no road in the world which is that wide then I'd be fine with not having the punctuation. However, if we don't want to have some other sort of standard delimiter, the brackets might still be useful to avoid the usual naming conflicts.) Jc86035 (talk) 13:06, 12 July 2018 (UTC)

@Jc86035: I dislike the idea of using parentheses ( ) in icon names because it is two characters whereas all other delimiters are one and also that it’s easy to omit the closing ). Instead, I would suggest a semicolon ;– because we can’t use colons in file names – and commas to separate lane numbers. Then your examples above would become RPP;3, RPV;3,2, etc. Useddenim (talk) 16:52, 12 July 2018 (UTC)

@Useddenim: Another delimiter (` in sections above) would be needed to disambiguate all of the curves. Jc86035 (talk) 16:54, 12 July 2018 (UTC)

@Jc86035: Wouldn't ROOTgeometry;lanes be sufficient? Useddenim (talk) 23:17, 12 July 2018 (UTC)

@Useddenim: I think it would work, although I would want it to be consistent with naming for other icons like  (vÜSTr3+1) and the road crossings where the primary track geometry is indicated at the end of the name. Jc86035 (talk) 04:50, 13 July 2018 (UTC)

Worry about that when (if) it happens. Useddenim (talk) 11:36, 13 July 2018 (UTC)

@Useddenim: But it already exists, doesn't it? Just because  (hSKRZ-G13+1) and  (vÜSTr3+1) are conveniently named doesn't mean we shouldn't sort out the rest of it in a logical way. (It's also somewhat likely that if we figure it out and create a massive table full of nonexistent files that someone is eventually going to try and fill all the cells.) Jc86035 (talk) 04:07, 14 July 2018 (UTC)

Four curved road transitions should be renamed

Moved from Talk:BSicon/Renaming/Archive 12

Hello, I noticed that names of these four icons should be switched around

vRP2yRP4+r		should be named	RP4yvRP2+r	because "RP4 transitions into (='y') vRP2 coming from right continuing south (='+r')
RP4yvRP2+r		should be named	vRP2yRP4+r	because "vRP2 transitions into (='y') RP4 coming from right continuing south (='+r')
vRP2yRP4+l		should be named	RP4yvRP2+l	because "RP4 transitions into (='y') vRP2 coming from left continuing south (='+l')
RP4yvRP2+l		should be named	vRP2yRP4+l	because "vRP2 transitions into (='y') RP4 coming from left continuing south (='+l')

This naming change would harmonize the icon names with the ones coming from north and turning right/left:

RP4yvRP2r		because "RP4 transitions into (='y') vRP2 turning right (='r')
vRP2yRP4r		because "vRP2 transitions into (='y') RP4 turning right (='r')
RP4yvRP2l		because "RP4 transitions into (='y') vRP2 turning left (='l')
vRP2yRP4l		because "vRP2 transitions into (='y') RP4 turning left (='l')

I cannot request moving of the files, because the names are already occupied they (need to be mutually exchanged).--Qeqwq (talk) 11:25, 4 December 2020 (UTC)

Renaming for Roads Needed

Moved from Talk:BSicon/Renaming

The naming for the road half icons are inconsistent to and in conflict with the railway ones. They use ROOT{n/e/s/w} convention but the railway ones use ROOT{e/aq/a/eq} convention. In particular, the east half road icon (e) is in conflict with the end half railway icon (e). The road icons need to be renamed. Xeror (talk) 22:43, 14 January 2022 (UTC)

@Xeror: Instead of just saying "something should be done", I suggest that you create a full proposal that can then be discussed. (Some good examples are at Talk:BSicon/Renaming/Archive 12.) Useddenim (talk) 04:13, 22 March 2022 (UTC)

@Xeror: Those names were originally created as test case for a diferent way to name BSicons: Later many new files followed the specifics of the generic roads design (grey pavement with white markings, or brown surface) but were filenamed with the usual naming conventions of the more usual single-color track lines. To bridge this gap, some redirects exist, and much more could be created. (Concerning naming conflicts, please use {{BS-q}} to indicate specific cases.) -- Tuválkin ✉ ✇ 15:23, 25 March 2022 (UTC)

​​Here're several examples of naming conflicts:

•  (hRP1e),  (hRP2e),  (hRP4e)
•  (RP2e-),   (vRP2e-)
•  (-RP2e),   (v-RP2e)
•  (RD1r),  (RP1r),  (RP2r),  (RP4r),  (vRP2r)

For the ROOT{n/e/s/w} problems, I propose three possible solutions:

• changing the railway icons to this convention, e.g.  (hSTRe) →   (hSTRn) (advantage: can represent all 8 directions with single rule (e, ne, n, nw, w, sw, s, se);
• changing the road icons to the railway convention, e.g.  (RP2e) →   (RP2aq) (advantage: least effort; disadvantage: separate system for corner and vertical/horizontal directions);
• changing all icons to number 1-8, with 1=East, 2=Northeast, 3=North, ... (counter-clockwise), and changing road icons from RP{D/1/2/4} to RP{A/B/C/D} to prevent conflicts, e.g.  (RP2e) →   (RPB1),  (RP2l) →   (RPB13),  (RP2s+1) →   (RPB27) (advantage: all 8 directions are represented in numbers and curves can be represented with 2 numbers; disadvantage: most effort)

For the roundabout problems, I propose to rename all roundabout to oROOT or ROOTo, e.g.  (RP1r) →  (RP1o). Same can be done for crossing to be renamed to +ROOT or ROOT+, e.g.  (RP1xRP1) →   (RP1+).

The most complicated ones are the different combinations of road crossings. My proposal would be using the third naming scheme above, e.g.  (RP4xRP2) →   (RP+B37D15). This allows intersection with all 8 directions with different road types.

Other suggestions are welcomed. Xeror (talk) 08:35, 28 March 2022 (UTC)

Roundabouts

For the roundabout problems, I propose to rename all roundabout to oROOT or ROOTo, e.g.  (RP1r) →  (RP1o).

@Xeror: I think ROOTo would work nicely. And the "bridge over 'nothing'" can be resolved as  (RP1o) →   (hRP1ae), similar to (some) rail icons. Useddenim (talk) 02:58, 29 March 2022 (UTC)

Update: All roundabouts have been renamed to Rx#O… (i.e.  (RP1r) →  (RP1O) etc). Useddenim (talk) 14:58, 26 December 2022 (UTC)

-M and -R are a source of conflict in combination with certain road types

Moved from Talk:BSicon

The codes -M and -R are documented in BSicon/Catalogue#Suffix modifiers as

• connects secondary object to middle (often resulting in a secondary element connecting to both, left and right) and to right (only) respectively (e. g.  (HST-M),  (HST-R))
• in combination with road-rail icons -M and -R are in use to denote classed road types
  cp.  (fBHF-A),  (fBHF-M),  (fBHF-R),  (SKRZ-Mo),  (SKRZ-Ro)

Adding an 'S' char to solve this issues does not work here. The problem is intrinsic to not knowing (without seeing the rendered icon) what -M refers to since polymorphous use has been introduced. For some icon name ROOTs -M could resolve to either an icon with class M road or (as documented in suffix modifiers) an icon with a secondary object stretching from middle, connecting the secondary on both icon sides.

A long term solution may be to stop using -M as a classed road denotifier, acknowledging that M class roads are ex variants of A class roads. However this may conflict with the denotation of 'e', 'x' and 'ex' prefix in conjunction with parallel lines (e.g. when parallel lines cross a classed road M, then 'e', 'x' and 'ex' prefixes are consumed to denote states of the parallel lines; the road cannot be percepted as a secondary line in this case and needs a separate naming mechanism to code an active/inactive state).

Another possibility to resolve it may be to prohibit or discourage usage of -M, -R, -L, -G and -F codes in icon names to denote road types (they have been reserved earlier in time as suffix modifiers). As a consequence existing set M and R icons need to be renamed/moved to other filenames using a different letter as road type. --93.201.170.146 20:15, 5 March 2022 (UTC)

@93.201.170.146: You have asked and answered your own question; nonetheless, you have raised some notable points.

With respect to road crossings, SKRZ is a special case combining rail and road; the capitalized suffixes as used there are not applied elsewhere. Nonetheless, there already exists a solution within the existing naming scheme. cf. (exSKRZ-Ao) (which should actually be xSKRZ-Ao) and SKRZ-xAo (currently at  (SKRZ-Mo)) are analagous to  (xABZg+lr) and  (ABZg+lxr). However, I do agree that M roads should be renamed as exA ones. Useddenim (talk) 23:14, 5 March 2022 (UTC)

@Useddenim: Thanks for your input. Skimming through the archives there are lots and lots of 'special cases', that have been generalized later on or are still on a todo type of list. As you've put it, I guess that simply adds to it. The problem I see with large amounts of icons is lag - if there are no joint efforts to switch icons from one scheme to another (after being certain that the new scheme indeed has benefits), than this lag will cause toggling back and forth, because people uninformed about a direction of move will simply deduct what's "right" from the input they get and then often decide simply for the scheme they determine to be most prominent (i.e. mass based). --93.201.167.64 22:08, 13 March 2022 (UTC)

Back on topic: Lets imagine type M indeed being moved to xA style naming, type R roads still remain. Another thing is the inconsistency encountered at a certain level of abstraction. For example, we're now at KRZW root for crossing unnavigable water running across from left to right side, and WKRZ for crossing unnav. water running from top to bottom sides of an icon. Why in the world is this totally handled different for roads - i.e. SKRZ singular instead of teaming with KRZS? --93.201.167.64 22:15, 13 March 2022 (UTC)

@Tuvalkin: ? Although, off the top of my head I would say that it's related to the fact that the primary direction goes ↓, from top to bottom of the page, and that water is water, whereas roads—especially the generic set—have numerous feature variations. Useddenim (talk) 22:27, 13 March 2022 (UTC)

The very root problem, imho, is that different types of rail are stylized using colours and most notable without a dedicated root modifier (i.e. no modifier == rail icon), while road sets are not differentiated by colour sets, but a dedicated root modifier S + a one or two letter code to differentiate among the different types of road, A, R, B, G, Y, and so on. There are no letter codes for heavy and light rail, and so on - this is all left to choosing a colour out from the available sets - the word in this language to get a rail intersection is as simple as KRZ ochre+orange, but, for various implications there is nothing like e.g. KRZ G1+G2 or KRZ ochre+G2, KRZ default+RA - because all the road–rail icons have been name-coded with the perception in mind that a road line is soo much different than a rail line (and subsequently that we need the obscure naming patterns inherent to the whole project that we perceive today). Changing this, if at all wanted, is imho immediatly related to the inability to pool names on symbol/icon/diagram/svg file objects (wrt mediawiki). --93.201.167.64 23:03, 13 March 2022 (UTC)

At the top of Category:BSicon/road/generic road it very clearly says what the set is and is not. If you have a problem with the naming and taxonomy of those icons, take it up with Tuvalkin, who spent a lot of time setting it up. As far as the coloured road sets go, they were inherited, so to speak, and the attempt was made to integrate them into the system as simply and with as little disruption as possible. Could more be done? Always; but I think you're barging into "If it ain't broke don't fix it" territory. Useddenim (talk) 03:25, 14 March 2022 (UTC)

Oh, its horribly broken, so much so that you cannot imagine the woods and their richness after once they have been redded and converted to mono-farmland (as to stick with painting verbal pictures..). --93.201.167.64 10:48, 14 March 2022 (UTC)

And that is precisely the reason your contributions are being reverted: pretentious gibberish and claptrap instead of plain clear speech. Useddenim (talk) 13:07, 14 March 2022 (UTC)

As if that were any different with the other participants.. As a rule of thumb: I've always started the discussions unpretentiously, precisely focused on specific project topics, but the sport is and has been, repeatedly, to spot each and every chance to change tracks. Your arrow points to a reaction, preceded by the common-place phrase in your last scentence - barging into 'if it aint't broke don't fix it' territory. Can you expect me to stay on topic, if you give such precendent? We came from some vague consent that introduction of road M type was not optimal? The direction of these discussions is a mutual thing, they are never driven by a single participant as you invalidly try to generalize it. --84.135.116.33 14:21, 14 March 2022 (UTC)

I understand your dissatisfaction in response to vague speech, but please accept that I'm human and I'm not among Goebbels, Hitler or Stalin if that is the type of non-gibberish you're after. With the history and size of the renaming archives, I suppose no-one in this subproject can claim to be perfect. --84.135.116.33 14:21, 14 March 2022 (UTC)

Refocusing on the arguments about SKRZ and the difference in handling cp. to KRZW. Do you sincerely think that the current scheme is optimal? In particular the need to use q to rotate road-rail SKRZ icons, while for rail icons the method used simply exchanges/colours the primary line. "clear speech": cp. ufKRZ / fuKRZ or KRZ denim+orange / KRZ orange+denim vs. SKRZ-G1 / SKRZ-G1q. The examples may look simple, but these are seeds for the naming of more complex icons. To put it clearly: Ignoring, arguably small, inconsistency with the simple cases, results in lots of corner cases and specialities when naming the more complex icons. This is the gibberish to focus on, as to not stall easy/explainable extendibility to the sets in the foreseeable future.

See Talk:BSicon/Renaming#Crossings. Useddenim (talk) 12:40, 15 March 2022 (UTC)

IMHO it is a logical step, mid-term, to treat road and rail lines similarly when synthesizing icon names. The difference observable now is grown historically - it's okay at an incubator or intermediate stage, but long term it is easy to project that it limits flexibility when creating new icons. Currently, as a route diagram developer there is a significant difference in writing diagrams composed of street and rail icons: There are lots of cases, where you cannot simply exchange the line code, from rail to road or vice-versa, and expect that a corresponding icon is rendered. You need to know one scheme for the naming of road, one for rail, that is. --84.135.116.33 14:21, 14 March 2022 (UTC)

If you have a coherent idea for a simplified and/or unified naming scheme, please present it to the project. In the meantime, although you have stated an unwillingness to review past discussions, I would suggest reading User:Circeus/BSicon renaming. Useddenim (talk) 12:40, 15 March 2022 (UTC)

If anyone remembers MS officials claiming to not know what a majority of lines in the OS's source code does and that, "to be on the safe side" the decision was to better not delete or change them - imho that's the point BSicon project has reached somehow. We cannot move along with an easier more extendable system for naming those piclets without generating incompatibility or say, even unintentionally, disturbing what's there. Name decision/upload sometimes feels like being stuck/imprisoned in a cathedral that has been hot-patched together as the past has seen fit (sorry for the awkward picture). When it comes to the seemingly simple aspect of naming a drawing the project is not only constrained by the rules it has given itself, but by the nature of the system that hosts it and inevitably the grown project past. Concerning (some) key aspects it does not acknowledge polymorphism and diversity among the "creators"/designers working with it (the most obvious, long-standing example is enforcing the use of Ü on people using keyboard layouts not exposing such keys - BRÜCKE, ÜST and so on - this were a non issue, to both native german and english participants if real, multiple title management (cp. filesystem hard links) was a mediawiki reality). Just my rants, under the impression of the overwhelmingly huge efforts spent on re- and re-renaming those icons. Imho, the driver of this is not a lack of discipline, but a limit in system design. I might be wrong, judge yourself. --93.201.167.64 23:47, 13 March 2022 (UTC)

Sort of off topic, but to explain my absence from these threads so far: I will not engage in collaboration discussions with IPs. If you have anything to say, create an account, or log in. -- Tuválkin ✉ ✇ 05:35, 14 March 2022 (UTC)

Off-topic, agreed. See your talk page for an answer. --93.201.167.64 10:48, 14 March 2022 (UTC)

You appear to be (at least somewhat) knowledgeable about the ways of Wikipedia, so I shouldn't have to explain that working as a logged-in editor lets others know that they are dealing with the same individual who is willing to stand behind their words, rather than hiding behind an anonymous number. Useddenim (talk) 13:07, 14 March 2022 (UTC)

You can absolutely trust me claiming that your username is no more to me than what is that number to you. Yes, you can invite me to run and read up on after all the contributions you've ever made to wikipedia projects, but this is wholely impractical. You're not the only individual I'm dealing with and lifetime is limited for both of us, hence no invitation to read up on my glory.. The interest to solve particular problems on particular this fraction on Commons will have to do. To drive the subject matter, no-one needs to be married. --84.135.116.33 14:38, 14 March 2022 (UTC)

OT: If you've contributed to various projects long enough, you know that enthusiasm of contribution variies over time and that people do not always stand behind their words - which also is human and the reasons are probably more often apt than not. It is not practical to pin contributors on something they've texted if they either revised themselves, have gained new knowledge or changed physis, for example. Most often its probably not just to assume unwillingness in a discussion partner, but it is the easiest reflex. Text interpretation / language barriers are also a good source of various discussions gone wrong. Vocabulary, words associated differently can add unintentional heat, even if you try to be ever so careful to stick to the topic. Natural language is not perfect. There are talk page banners in many wiki-versions trying to call for calm discussions and pledge to assume good faith (note the vagueness), but if the "right" participants meet at the "right" time they virtually stay unread.

What can you do? Some people leave the wikiverse with a flag-marker/remembrance of it being lost-ground, some get (very) careful. There are tera- if not petabytes of text, incomprehensible within individual life-spans. Circuit-breakers can simply be out of reach and things get philosophical or lean towards the tower-of-babel phenomenon. Commons is what contributors make of it and its impossible to get a grasp on all of the expectations behind it, driving it. Some trade curiosity for tolerance, the motivations are manifold. Below all there is not only physics and natural science, the machines that run it, but some hope that the sum of all contributions has a worth higher to society than its humble parts. This is indifferent from how infantile or sophisticated contributions may be. If this is a too naive view considering the negative implications youtube/facebook and other social media have brought about, remember that this is only one view offered. Commons is a melting pot, where you read, what you write - your choice. --84.135.126.102 16:09, 14 March 2022 (UTC)

Motorway interchanges

I think I've figured out a rational naming scheme for the motorway interchange icons:

Icon	crossing	loop	diagonal	Type	New name?
		in corner …
(MWEXag)	over	—	1		RMIo1
(MWEXeg)	over	—	2		RMIo2
(MWEXef)	over	—	3		RMIo3
(MWEXaf)	over	—	4		RMIo4
(MWEXo)	over	—	1,2,3,4	diamond	RMIdo
(MWEXu)	under	—	1,2,3,4	diamond	RMIdu
(MWEXrgo)	over	1	1,3,4	folded diamond	RMIfo1
(MWEXrgu)	under	1	1,3,4	folded diamond	RMIfu1
(MWEXrfo)	over	2	2,3,4	folded diamond	RMIfo2
(MWEXrfu)	under	2	2,3,4	folded diamond	RMIfu2
(MWEXlgo)	over	3	1,2,3	folded diamond	RMIfo3
(MWEXlgu)	under	3	1,2,3	folded diamond	RMIfu3
(MWEXlfo)	over	4	1,2,4	folded diamond	RMIfo4
(MWEXlfu)	under	4	1,2,4	folded diamond	RMIfu4
(MWEXlfrfo)	over	2,4	2,4	A2	RMIao
(MWEXlfrfu)	under	2,4	2,4	A2	RMIau
(MWEXlgrgo)	over	1,3	1,3	B2	RMIbo
(MWEXlgrgu)	under	1,3	1,3	B2	RMIbu
(MWEXlfrgo)	over	1,4	1,4	AB2	RMIaboa
(MWEXlfrgu)	under	1,4	1,4	AB2	RMIabua
(MWEXlgrfo)	over	2,3	2,3	AB2	RMIaboe
(MWEXlgrfu)	under	2,3	2,3	AB2	RMIabue
(MWEXrfu all)	under	2	1,2,3,4
(MWABZlo)	over	3,4	1,2	half-clover	RMIhoaq
(MWABZlu)	under	3,4	1,2	half-clover	RMIhuaq
(MWABZro)	over	1,2	3,4	half-clover	RMIhoeq
(MWABZru)	under	1,2	3,4	half-clover	RMIhueq
(MWCLOo)	over	1,2,3,4	1,2,3,4	cloverleaf	RMIco
(MWCLOu)	under	1,2,3,4	1,2,3,4	cloverleaf	RMIcu
(MWABZ3glo)	under	1×2	2,3	trumpet	RMItu1a
(MWABZrgo)	over	1×2	3,4	trumpet	RMIto1eq
(MWABZrgu)	under	1×2	3,4	trumpet	RMItu1eq
(MWABZ3flo)	under	2×2	1,4	trumpet	RMItu2e
(MWABZrfo)	over	2×2	3,4	trumpet	RMIto2eq
(RMIto3e)	over	3×2	1,4	trumpet	RMIto3e
(MWABZ3fro)	under	3×2	1,4	trumpet	RMItu3e
(MWABZlgu)	under	4×2	1,2	trumpet	RMItu4aq
(MWABZ3gro)	under	4×2	2,3	trumpet	RMItu4a
(MWABZlrou)	—	—	(1,2,3,4)	roundabout	RMIOa

The names parse as:

Root		Interchange type	Crossing	Quadrant	Direction
RM - Road (Motorway)	I - Interchange	a - A2 ab - AB2 b - B2 c - cloverleaf d - diamond f - folded diamond h - half-clover O - roundabout t - trumpet	o - over u - under	1 - ◳ 2 - ◲ 3 - ◱ 4 - ◰	a0 aq e0 eq

This seems to cover all but one of the existing icons. Useddenim (talk) 15:09, 1 August 2022 (UTC)

Abolishing SKRZ syntax

If the ; connector gets implemented, I think we should take the opportunity to fit the SKRZ icons like  (SKRZ-G4o) into that naming scheme, because I don't think the current situation really makes the most sense. In particular, the use of G instead of P seems to be based on an aborted idea from over 12 years ago (if I'm reading this section correctly), and the unique use of the - character apparently has already caused someone to raise concerns.

Edge cases:  (xvSPLe+GDqo) would probably become xvSPLe;GDq;o or GDq+xvSPLeo,  (SKRZ-G4o(Ll)) would probably become RP4q;u~g(g) or KRZ;RP4q;o(Ll),  (RAKRZ-Au) would become RA;RAq;o or RAKRZu, and  (vSKRZ-G4hl) would become hRP4aq;v. Jc86035 (talk) 19:49, 28 February 2024 (UTC)

I like it! Useddenim (talk) 20:55, 28 February 2024 (UTC)