Talk:BSicon/Icon geometry and SVG code neatness/Formations/Archive 1

Archive 1

Bridge/elev stroke width

While all icons with elevated structures (and “long” bridges) seem to be standartized at 60px width, I noticed some bridges are 40, other 45, others (also) 60. (This for bridges made of 3 stokes, not  (BRÜCKE2).) Someday hamonization would ne a nice thing to do, although not urgent. -- Tuválkin ✉ 17:48, 6 November 2011 (UTC)

Basically what happens is that some are regularized for harmony with the elevated icons, other aren't. Circeus (talk) 18:05, 6 November 2011 (UTC)

Position of elevated sides

hSTRrg | lhSTRq | hSTRlg hSTR | … | hNUL hSTRlf | hSTRq | hSTRrf -- Tuválkin ✉ 00:53, 26 November 2011 (UTC) -- Tuválkin ✉ 01:00, 27 November 2011 (UTC) (done!)

So I needed a vertical version of  (hNULq) and I created a derivative and uploaded it:  (hNUL). When I tried to use it to match other elevated icons, I find out that its greenish grey strokes that stands for that type of structure are in  (hNULq) only 50 (nominal) px wide, not 60, and placed at 150 and 350, not at 120 and 380. (One more case of #Bridge/elev_stroke_width.) What now?! -- Tuválkin ✉ 00:53, 26 November 2011 (UTC)

That would be because our bridges icons are a bit of a mess. The hNUL icons (as well as the ELEV portal icons, as it is), were designed to match icons like   (exvRP2u) and   (RD1o) (vs.   (exvRP2uh) and   (hRD1oa)), but all partial bridge icons (except for the ELEV ones) have since been fixed. The only use of the hNULq icon that remains appears to be en:Template:Rochester Subway route diagram (where it works poorly under a   (uWSLr+r)). Changing it won't do any harm. Circeus (talk) 18:10, 26 November 2011 (UTC)

 Done (and  (INCIDO) removed from the example above, replaced with a suitable iconic display!) -- Tuválkin ✉ 00:38, 27 November 2011 (UTC)

 Done also the mentioned use in en:Template:Rochester Subway route diagram, by means of newly created   (uhWSLr+r). -- Tuválkin ✉ 00:59, 27 November 2011 (UTC)

Elevated loops

File:BSicon uhWSLr+r.svg

I just made this   (uhWSLr+r) — please take a look at its geometry. The idea is to create an elevated end-of-line, akin to  (hENDEe) and  (uhKBHFa), but constrained by lack of wiggle room in the confines of a loop icon   (uWSLr+r). I made it curving/parallel on the sides of the outwards track but squarish along the dead-end side, so that the unability to make it parallel to the loop itself (it would bleed outside the icon boundaries) doesnt become too apparent. Suggestions for improvement, before the whole set of 16 variations is created? -- Tuválkin ✉ 01:37, 27 November 2011 (UTC)

You know you don't HAVE to make full set for such edge cases until they actually are needed, right? Circeus (talk) 03:34, 27 November 2011 (UTC)

Sure, but if anyone has a criticism of, or a better suggestion for, this design, it is better to say so now. -- Tuválkin ✉ 10:31, 27 November 2011 (UTC)

Not so much a criticism as a wondering: why is the side square instead of round? Circeus (talk) 14:52, 27 November 2011 (UTC)

If it were round, the necessary lack of parallelness to the track (forced by lack of room) would become visible and look sloppy. --Tuválkin ✉ 18:34, 27 November 2011 (UTC)

Oh right... Circeus (talk) 20:10, 27 November 2011 (UTC)

(And then there’s the assymetrical loops, such as  (uWSLr) — those cannot be dealt with inside a single icon cell.)… -- Tuválkin ✉ 01:37, 27 November 2011 (UTC)

different elevated marker

moved from Talk:BSicon#different_elevated_marker

 (hSTRl+4) has small grey lines,  (hÜWol) has slightly thicker grey lines! Maybe there are more discrepancies ...? a×p_de^Hello! 17:19, 30 March 2012 (UTC)

Seems that the correct/agreed practice is 60px wide and centered at 120 and 380 px — or 130px off the midline. Or also marker from 90 to 150px, then gap to 200, then track to 300, then gap again to 350, then marker again to 410px. Hmmm… I guess that makes the 290px value in  (hSTRl+4) too small, should be 320 (=410−90). -- Tuválkin ✉ 00:16, 31 March 2012 (UTC)

(Most puzzlingly, this thread was archived, but no change was made. Now  Done. YLSS (talk) 18:04, 4 October 2013 (UTC))

Under void bridges

uxKRZuw uexWBRÜCKE

This  (uxKRZuw) (and its cohort) is a great addition (albeit needing renaming), but the exact design needs fixing, IMHO.

• The bridge geometry should match  (BRÜCKEq) and
• there should be no gap between the bridge and the line that goes under it, as per established convention.

Opinions? -- Tuválkin ✉ 06:01, 9 July 2012 (UTC)

Geometry fixed. Useddenim (talk) 20:20, 20 August 2012 (UTC)

Elevated to tunnel

File:BSicon exhTUNNELa.svg Original

Revised

Alternative

Moved from User talk:Useddenim

Hi! Thanks for the contribution, expansion and elaboration of Manila Train Templates, but may I ask if we could follow the diagram already existing especially with File:BSicon hTUNNELe yellow.svg and File:BSicon hTUNNELa yellow.svg. It has come to my attention that the ones that you used for this diagram is different from the basic and existing File:BSicon hTUNNELe.svg and File:BSicon hTUNNELa.svg, so in line with this may I ask you to please use the standard icons or if you want, I could give you the files with the standardized icons as I cant overwrite the file. Mabuhay! PhilippineRevolution (talk) 11:02, 28 December 2013 (UTC)

It should be evident what my preference is. Anyone else? Useddenim (talk) 13:02, 28 December 2013 (UTC)

I have no contest on whatever will prevail, but for uniformity's sake, let us agree on what should the design be and implement it across all colors/variants.PhilippineRevolution (talk) 13:25, 28 December 2013 (UTC)

I prefer Useddenim's revised geometry. If there is a need to emphasise that the elevated structure ends shortly before the tunnel starts, one can use  (exTUNNELa※ lhSTReg) . YLSS (talk) 13:40, 28 December 2013 (UTC)

For me I prefer any of the first two, as it seems to me that the third one is a little bit out when used in the template.PhilippineRevolution (talk) 13:45, 28 December 2013 (UTC)

I agree with Useddenim that the tunnel portal / raised track junction in   (exhTUNNELa red) is better than in   (exhTUNNELa), and I agree with YLSS that  (exTUNNELa※ lhSTReg) , is a good alternative solution, if necessary to stress any discontinuity between the two “formations”. -- Tuválkin ✉ 14:35, 28 December 2013 (UTC)

Click to expand

Is there a tool that will upload revisions for multiple files all at the same time, instead of doing it one by one? Useddenim (talk) 00:44, 29 December 2013 (UTC) Even Special:UploadWizard does not allow uploading file with existing file name, so no. -- Sameboat - 同舟 (talk) 01:52, 29 December 2013 (UTC) But I think that the uploading user or user with priviledges can replace the existing icons  (hTUNNELe), (uhTUNNELe),   (hTUNNELa),  (uhTUNNELa), etc with those icons by Useddenim.PhilippineRevolution (talk) 03:23, 29 December 2013 (UTC) No, this isn't about uploader of higher usergroup. The problem is that the uploadwizard lacks the functionality to overwrite existing file. So the only efficient solution is to massacre the existing files and re-upload them with uploadwizard. But even so there is another problem that uploadwizard mandatorily requires the uploader to choose a license between CC-by-sa 3, CC-by 3 and CC 0, there is no pure "public domain" option. Although CC 0 is essentially public domain, I think we need consensus before using CC 0 for icons of this project. -- Sameboat - 同舟 (talk) 04:00, 29 December 2013 (UTC) Well regarding the consensus, my vote will be a yes as long as if its the only solution to the problem and yes as I think CC0 license or the same license User:Useddenim would suffice as long as it is attributed as "public domain". PhilippineRevolution (talk) 04:11, 29 December 2013 (UTC) How come 'there is no pure "public domain" option' in UploadWizard? If you select that it's not your own work (and use {{Own}}), it allows to enter any text as license, incl. {{PD-shape}}! 2 PhilippineRevolution: there is not much of a problem, actually... Or rather, there is one, but just one among a multitude. Glance through the rest of this page, for example. That is to say, if you re-upload by yourself all hTUNNELs with the revised design, we will only be grateful! YLSS (talk) 10:31, 29 December 2013 (UTC) You should actually try uploadwizard to understand its limitation. Simply put, it divides the whole uploading process into different steps and choosing a license of 3 kinds of CC is an individual step after choosing file(s) from your computer and is mandatory, otherwise it won't allow you to proceed to the next step: entering file description. -- Sameboat - 同舟 (talk) 13:15, 29 December 2013 (UTC) (ec) Erm... And how do you think I do upload BSicons? At step two (at least for me), you may choose "This file is not my own work." -> "Another reason not mentioned above" and enter {{Own}}, {{u|Sameboat}} and {{PD-shape}}. Give it a try ;) YLSS (talk) 17:12, 29 December 2013 (UTC) orz OK. So then the remaining question is if any admin among us is willing to do a mass deletion? As far as I concern, user:Axpde, user:mattbuck, user:Ronhjones and user:Redrose64 possess such right. -- Sameboat - 同舟 (talk) 23:16, 29 December 2013 (UTC) To YLSS: I would want to update things myself but all i can see when i try to do so is that "you cannot overwrite this file". I dont know what seems to be the problem and i am willing to give you files for update similar to Useddenim's design if what it needs is some kind of admin priviledge. PhilippineRevolution (talk) 17:08, 29 December 2013 (UTC) No, you certainly don't need admin rights for that. How did you try overwriting it – by pressing "Upload a new version of this file"? If so, I guess you are still regarded by the server as a new user (apparently it lasts for 4 days, see Commons:Autoconfirmed users). YLSS (talk) 17:18, 29 December 2013 (UTC) The best way to replace the design of existing icons is to upload new version of each, one by one. That not only keeps the description, licensing, and history of each icon but also leaves its use intact, making the changeover much simpler than mass uploading, which doesn’t have magical overwriting abilities. -- Tuválkin ✉ 17:44, 29 December 2013 (UTC) Redacted to clarify. -- Tuválkin ✉ 18:26, 29 December 2013 (UTC) I guess that's what Useddenim desires to find (as do I): a mass uploading that would "keep the description, licensing, and history of each icon but also leave its use intact". But AFAIK no such thing has been created as yet. YLSS (talk) 18:09, 29 December 2013 (UTC) Yes, so the best thing to do is to do what we ever did with other such design changes. -- Tuválkin ✉ 18:26, 29 December 2013 (UTC) Uploadwizard allows you to 1 click-copy the same description text from the first file to other files in a batch upload. -- Sameboat - 同舟 (talk) 01:48, 30 December 2013 (UTC) That’s for uploading new files. The fastest way I’ve found to update (albeit still manually) is to cut ’n’ paste the url https://commons.wikimedia.org/w/index.php?title=Special:Upload&wpDestFile=BSicon_ICON.svg&wpForReUpload=1 one by one… Useddenim (talk) 19:13, 31 December 2013 (UTC) (Digression) Just tried Upload Wizard for SHI4g series and it already gave me an OMFG moment: when I checked "copy information to all uploads below...", I was unaware that "copy title (with automatic numbering)" is enabled by default. The result was subsequent files were renamed as xxSHI5gxx, xxSHI6gxx, xxSHI7gxx, etc. -- Sameboat - 同舟 (talk) 05:38, 2 January 2014 (UTC) Upload Wizard is not geared to be used by grownups or people who know what they are doing, you didn’t know that? I hope you remember it when there’s a new WMF election and you vote to oust the morons who dreamed that crap up, along with Visual Editor, MobileUploads and other anti-wiki and antiencyclopedic gadgets, toss all that trash out to Wikia. -- Tuválkin ✉ 09:31, 2 January 2014 (UTC) I'm late to the party, because of Christmas/New Year commitments. Some responses: Although I'm an admin on English Wikipedia, I'm not an admin on Commons, or any other project (unless adminhood is set globally now? I'm sure it isn't, I don't see any "delete" or "protect" tabs at the top of this page). I've never found it necessary for a file to be deleted before a new version is uploaded, because I use the "Upload a new version of this file" link found on every file description page just below the table in the "File history" section. It's quite a simple interface: you choose a file to upload from your computer, fill in the "File changes:" box, and click Upload file. You can leave everything else alone, and the description, licensing, categories etc. are copied verbatim from the old version. For entirely new files, I don't use the Upload Wizard - I did try it a few times, but never managed a successful upload, so went back to the old way. If you're interested, it's at Commons:Upload; and you can alter the link in the sidebar to give you that instead of the upload wizard by going to Special:Preferences#mw-prefsection-gadgets and unchecking "UploadWizard: d Upload Wizard. Especially useful for new users. [documentation / talk] ". --Redrose64 (talk; at English Wikipedia) 00:04, 7 January 2014 (UTC) I actually found that Upload Wizard is quite handy of batch uploading new files (as you can see in my upload log), but I've given up on the idea of overwriting with it because we need to preserve those older versions. The problems I have with it apart from that default "copy title" option are the lack of preference of default customized license and the uploaded files are not automatically added to your watchlist. -- Sameboat - 同舟 (talk) 02:07, 7 January 2014 (UTC) They are if you select "Add pages I create and files I upload to my watchlist" in your Preferences, even with UploadWizard. YLSS (talk) 08:20, 7 January 2014 (UTC) (It’s under the Watchlist tab.) Useddenim (talk) 17:12, 7 January 2014 (UTC)

Elevated interruption

 (uexhLSTR) or   (uexhLSTR!)? (IMHO, the formation sidebars should also be dotted.) Useddenim (talk) 19:26, 29 May 2014 (UTC)

Neither. The Luecke icons are for where the detail is omitted: viaducts are detail that should be omitted along with stations. Use  (uexLSTR) instead. --Redrose64 (talk; at English Wikipedia) 13:14, 31 May 2014 (UTC)

Why so categorically? IMHO, it just looks crooked to have a  (uexLSTR) between two  (uexhSTR), with the sidelines terminating abruptly. If it is know that the whole of the route in the contracted section is elevated, why not to make it more good-looking?

@Useddenim: Yes, I agree with you. However, I have seen some diagrams at zh.wp with  (lhSTRq) overlaid on top of  (uexhCONTgq) — apparently because an editor preferred the arrow to be between solid sidebars... But since we are in possession of an army of formation icons, I think it would be OK to overwrite  (uexhLSTR) with your design. YLSS (talk) 15:39, 31 May 2014 (UTC)

Elevated stations

Like this?

Or like this?

Should elevated stations be surrounded with buldging “formations”, or not? -- Tuválkin ✉ 00:10, 30 July 2012 (UTC)

Comme ça? Useddenim (talk) 20:43, 2 August 2012 (UTC)

At 20×20 I prefer with bulges. Useddenim (talk) 20:51, 2 August 2012 (UTC)

And  (HST) for good measure. Useddenim (talk) 20:59, 2 August 2012 (UTC)

I like this! -- Tuválkin ✉ 12:42, 28 March 2013 (UTC)

 Agree -- Tuválkin ✉ 03:09, 3 August 2012 (UTC)

Anyone else have an opinion? Useddenim (talk) 18:45, 3 August 2012 (UTC)

---

Now, bulging formations can be simply added to existing icons, more or less swiftly, or a case can be made for making a distinction — like in  (mKRZ) vs.  (mCRS). (As also in the cases of   (exSTR+r-ABZg+r) vs.   (uSTR+r-ABZg+r) and  (uehABZlf) vs.  (uxhABZlf), where competing different depictions are still to be sorted out.) -- Tuválkin ✉ 23:23, 3 August 2012 (UTC)

Tight or loose?

←  (lhKHSTa) ←  (uhBHF!) ←  (uhBHF!) ←  (uehINTACC) ←  (uehINTACC) ←  (uehDST) ←  (uxhDST) ←  (uhHST!) ←  (lhKHSTe)

uhINTACC uhBHF! uehINTACC uehDST uxhDST

In Useddenim's latest  (uehINTACC), sidings are tighter than in earlier icons. YLSS (talk) 18:07, 11 July 2014 (UTC)

Personally I prefer the icons without bulges except in cases where the track or object itself would extend outside of the formation (loops, for instance). I seem to be outnumbered on this point, so given that if we are going with bulges, the space between the object and formation lines should try to be as close to that on straight pieces. As a side note, I thought the bulging formation icons were only partially implemented and ultimately didn't take hold and so created the uhINTACC icon with straight formation lines. Lost on Belmont (talk) 03:10, 12 July 2014 (UTC)

I’m still trying to find an æsthetically pleasing compromise… Useddenim (talk) 03:42, 12 July 2014 (UTC)

I think the most evident drawback on the bulges is the sinusoid that appears when there are several  (uhBHF!) in a row. Compare the full and contracted variants of the same RDT at ru:Бутовская линия & ru:Лесопарковая (станция метро). That's why, even though I prefer the bulges, I kept uploading icons without them, and only satisfied myself with overlays. I can say only one thing for certain: I dislike the right angles in  (uhKBHFe) &  (uhKHSTe), and between   &  , I prefer the latter. Overall, I would favour introducing bulges into all icons, but I won't press with that. YLSS (talk) 09:12, 12 July 2014 (UTC)

Lost on Belmont has recently started re-uploading elevated icons to use 50px-thick sidings, and in those with stations he used straight formations. So, we'd better decide what we are going for now, so as not to do any double work. Tuvalkin, Axpde, Circeus? I may note two more points: 1) In  (uhBHF) with updated sidings the circle of the station completely hides the formations near the middle. 2) While  (uehINTACC※ WASSERq)  looks quite OK, File:BSicon uAROADq.svg (uehINTACC※ uAROADq)  isn't so good, and in case of  (uhBHF!) some dedicated icons or masks would be required. YLSS (talk) 15:49, 16 November 2014 (UTC) P.S. Some more experimenting:  (uehDST) &  (uxhDST). YLSS (talk) 17:30, 16 November 2014 (UTC)

I've been re-uploading all the (u) icons with straight, vertical formations with the new thicknesses (avoiding the curved ones for the present) while forgetting that this was still an open discussion. I'll avoid the station icons for now. I'd also noticed that the new dimensions cause the station circles of BHF size completely hide the formation lines in the middle. My opinion on the matter hasn't changed and I still find the sinusoid ugly. I think Useddenim's compromise has some merits (the curve isn't as pronounced) but the drawback here is that the "white space" is visibly reduced in width and looks rather inelegant. Lost on Belmont (talk) 16:36, 16 November 2014 (UTC)

After lookoing at all the variations that have been created, I think I like  (uxhDST) the best, which has the smallest transition curve, and then stays closest to the symbol. With respect to terminals,  (lhKHSTe) is far superior to  (lhKHSTa). Useddenim (talk) 19:02, 16 November 2014 (UTC)

Hmmm, my first question was: Why do they change the 60px elevated lines to 50px at all? Now we run into problems. I prefer the straight lines, and I created tons of elevated icons with straight lines. But  (uhBHF) looks worse than before, with the 60px elevated lines the station "ball" didn't reach the outer edge of the elevated lines. My vote: straight lines, 60px a×p_de^Hello! 19:41, 16 November 2014 (UTC)

Axpde, see "Elevated structure elements," below. YLSS gave a host of solid reasons to switch to 50px. I agree with you that the icons should use straight lines and at first I was skeptical of the switch to 50px, but after reading those arguments, I'm wholly in favor. Lost on Belmont (talk) 20:11, 16 November 2014 (UTC)

Useddenim has uploaded some ruby-coloured icons using the tighter curves from  (uxhDST), the result can be seen here. Near the bottom there's a perfect comparison ground for  (uexhBHF) vs.  (exhBHF ruby). The feeling of sinusoid as it was with the previous design is pretty much gone. But yes, the uex line looks clearer. ....... P.S. @Tuvalkin: don't keep silent. YLSS (talk) 17:06, 4 January 2015 (UTC)

Thx for the heads up, but I have nothing major to add here right now. I agree with the general direction of the matter; lets do this, people! . -- Tuválkin ✉ 03:29, 17 January 2015 (UTC)

I’ve redrawn en:Template:Rapid Rail network with all the elevated stations using YLSS’ “tight” formation geometry of  (uxhDST). I think it’s the “reasonable compromise” between not obscuring the symbol and not bulging too much that we’ve been looking for. Useddenim (talk) 01:44, 15 January 2015 (UTC)

Witnessing "live" how you proceeded with  (hBHF2+4 saffron),  (hBHF2 green),  (exhBHFl ruby) made me finally fall in love with them ;) So now my vote is certainly for them. But this brings another question, see below. YLSS (talk) 23:35, 15 January 2015 (UTC)

While I still prefer the straight lines, my objections to curves are greatly reduced with this version. The main problem at this point is YLSS's Portal Problem. Lost on  Belmont ^3200N_1000W  (talk) 00:38, 16 January 2015 (UTC)

You saw how slowly “live” went: the math was a real pain (and in the process I had to consult some of my decades-old drafting textbooks), but I wanted to use precise circular arcs so that these icons could be easily translated, rather than resorting to Beziers that simply looked “right”. Useddenim (talk) 01:03, 16 January 2015 (UTC)

What about terminals? I agree with Useddenim that  (lhKHSTe) is far superior to  (lhKHSTa) but are everyone's thoughts on KBHFs? I think, for consistency, that BHFs should also contain "white" space around the station. Lost on  Belmont ^3200N_1000W  (talk) 17:39, 17 January 2015 (UTC)

I agree. The gaps between line and formation should be present as much as possible. -- Tuválkin ✉ 03:21, 18 January 2015 (UTC)

I'm not sure I get what you two mean...

@Lost on belmont: Consistency between what? IMO consistency between variations of BHF is more important than between BHFs & HSTs. And current  (hKBHFa ruby) is consistent with  (hBHF ruby), isn't it?

@Tuvalkin: These words of yours seems to contradict what you wrote above (03:29, 17 January 2015)... Which kind of gaps and where?

My thoughts are like this. There are two options: either we leave  (uhHST) as it is, which would be consistent with the current design of e.g.  (uhDST) in the sense that the formations are bulged out only as much as necessary, that is not at all in this case; but this would mean either tolerating the ahem, ahem, condom-like shape of   (especially as seen in the diagram above), or tolerating some inconsistency. Option two: we use the geometry of either  (uhHST!) or  (uhHST!!), which would be consistent with  (uhDST) in the sense that it does bulge around the stations, and create something similar for  (uhKHSTa). Overlaying would still be relatively easy as anything below can be hidden with  (MASKm) just as much as needed (the maximum width between the formations in both  (uhHST!) &  (uhHST!!) is 250px.)

-- YLSS (talk) 22:02, 18 January 2015 (UTC)

The consistency I was referring to was between the geometry/iconography of terminals. The reason we switched to these narrower bulges is because the previous versions were ugly. We're dealing with a visual medium and it is our responsibility to design and maintain a set of icons that 1) communicate the point effectively and 2) are pleasing to the eye. You've already pointed out a drawback of   (unless, you know, you're into that kind of thing...) but you made a very valid comparison. It's ugly, and that's reason enough not implement that design. And we already have an alternative in place   that is visually pleasing.

Then, if we do go with that design, my point is that the BHF terminals should also use a similar shape. It is this consistency that I refer to. Personally, I find the white space around the end of the station helps convey that the finality of a terminal: there's nothing after that. (We already have some formations that butt up against stations (portals, for instance). The white space provides a break that otherwise doesn't exist. Lost on  Belmont ^3200N_1000W  (talk) 02:26, 19 January 2015 (UTC)

I agree with Lost on belmont; the white space around the “blob” provides the needed definition of termination. Useddenim (talk) 04:46, 19 January 2015 (UTC)

So you want some abstract RDT to look like the one to the left? Doesn't it look at least strange? Maybe the one to the right would be better? Notice that the formation in  (uhKDSTa!) protrudes further than in  (uhKACCe!) &  (lhKBHFa) in order to compensate for lesser whitespace.

Let's then call it settled with  . But neither of you has commented on  (uhHST) vs.  (lhHST※ uHST)  vs.  (uhHST!) vs.  (uhHST!!). YLSS (talk) 21:27, 21 January 2015 (UTC)

One thing at a time! We're still on terminals. And yes, the one on the left is preferable. The ones on the right look misshapen and while it is intentional, it doesn't look as if the curves have been done that way intentionally. And while the terminal on the left isn't the same as  (uhACC), it speaks the same iconographic language in that it has curved formations, but also stands apart in the fact that it is different, which it should. The white space all around it instantly and easily demonstrates the "differentness" of the terminal, lending to its finality. It will also then match the iconography of our HST terminals upon which we've just agreed.

But since you've brought it up again, I say straight lines for HSTs since they don't overlap the formations. There isn't a need to bulge. Lost on  Belmont ^3200N_1000W  (talk) 18:25, 25 January 2015 (UTC)

Hm, I do find such difference of geometry strange, but we have kinda democracy here, so if you all agree an that, I certainly don't mind. YLSS (talk) 20:09, 25 January 2015 (UTC)

Any one else want to weigh in on HSTs? @Useddenim: , @Tuvalkin: , @Axpde: , @Circeus: ? Lost on  Belmont ^3200N_1000W  (talk) 02:07, 30 January 2015 (UTC)

Somehow nobody else seems to care...

Well, I would then suggest yet another option, because I still do find the mix-up of  (uhKBHFa) vs.  (uhBHF) ugly. I recalled how does the only elevated line of Moscow Metro end — like this, not far away from the terminal station — and tried out  (uhKINTACCa). It can be seen live at zh:Template:芝加哥地铁红线RDT. In my opinion, it looks more authentic than the current version of  (uhKBHFa) (although I could happily live with  (hKBHFa ruby) ). YLSS (talk) 15:45, 11 February 2015 (UTC)

I find both  (uhKINTACCa) and  (hKBHFa ruby) ugly. Also  (uhKINTACCa) looks a little too similar to   (hBHFCCa red). As it stands, though, it looks like you (and possibly Axpde) are the only dissenter to the current design. Lost on  Belmont ^3200N_1000W  (talk) 22:21, 11 February 2015 (UTC)

I would rather say that everybody else keeps silent... But I would like it very much if at least Useddenim comments on the latest variations. YLSS (talk) 22:50, 11 February 2015 (UTC)

OK, then; my 2¢ worth:  (uhKINTACCa) is ambiguous. If there's overrun tracks, then use  (uhENDEa); if the line ends in the station, then use  (uhKBHFa)  or whatever, as Lost on Belmont suggests. But you're right about the icons that are tight to the sides but loose at the end (e.g.  (uhKDSTa!) are indeed ugly. (P.S. I'm currently cruising the Yellow & China Seas, so my internet access is somewhat spotty.) Useddenim (talk) 03:47, 12 February 2015 (UTC)

Interchanges

Another interesting question is the geometry of sidings for interchange stations like  (BHF-R). Lost on belmont has recently updated  (uhINT-R) with formations identical to those in  (uhINT). But possibly the left (as seen) siding should be different? Either completely straight, or curving to the side more or less like in  (lhJCTgq), or at an angle as in  (lhTEEgq)? (CPICs, on the other hand, can live perfectly with regular formations.) YLSS (talk) 22:53, 28 April 2015 (UTC)

ubhINT-INT_α ubhINT-INT_β ubhINT-INT_γ uhINT * CPIC

For your consideration… Useddenim (talk) 03:33, 30 April 2015 (UTC)

Yes. INTs et al. should definitely have formations that "follow" the station out to the side. Looking at these I find myself leaning (for once) toward the straight lines of β. I also agree with YLSS on the CIPC point and have reuploaded those already. Lost on  Belmont ^3200N_1000W  (talk) 12:20, 30 April 2015 (UTC)

Okay. I take that back after viewing this template which I have absolutely no familiarity with. Also going α. Lost on  Belmont ^3200N_1000W  (talk) 02:15, 1 May 2015 (UTC)

And I was going to point out Clark/Lake on en:Template:The Loop 1997-present! Useddenim (talk) 03:16, 1 May 2015 (UTC)

• α Alpha. The interchange is not necessarily between two lines in the same station, it might be between two stations that are physically close. We do not indicate the nature of the connection - it might be a footbridge, walkway at ground level, subway (in the UK sense), escalators or lift. Having the grey lines turn sideways implies that the method of interchange is also elevated above ground level. --Redrose64 (talk; at English Wikipedia) 14:35, 30 April 2015 (UTC)

In those cases those are separate stations with a connection to a nearby station. If they're connected by a walkway, we already have a class of icons to depict that.  (BL) Lost on  Belmont ^3200N_1000W  (talk) 21:53, 30 April 2015 (UTC)

• α Alpha. I’m with Redrose64 on this one. After all, there’s diagrams with for multi-level interchanges. If both (all) lines are elevated, then one can safely assume that the interchange link is also elevated, without it being necessary to actually indicate it so. (After all, these are route diagrams.) But no complaints/objections to the CPICs, though. Useddenim (talk) 22:10, 30 April 2015 (UTC)

Portal design

Axpde's (?) Tuválkin's Useddenim's  YLSS's File:BSicon dTUNNELa.svg full-width half-widths

The quite uncommon family of icons with a portal on an ÜW-curve could boast no less than three portal designs. I decided that I'm no worse than others, and uploaded my own version ;). I based it on  (tvSTRa-), but I can't say now where I took that design from... Possibly it was a rounded version of  (tvSTRag-). So... can anybody provide reasons why one of them is better than the others? Or is it up to voting? YLSS (talk) 10:25, 22 January 2014 (UTC)

Axpde's design came from the  (KRZu) and  (ÜWul) icons; mine was a quick ’n’ dirty clipped path done in a hurry (in newer uploads I use an arc similar to YLSS’). But since you’ve asked, I think I prefer the small arc, as in YLSS’ and the half-width examples. Useddenim (talk) 12:50, 22 January 2014 (UTC)

BSicon tunnel portals are archetypically arcs like this: "surface)tunnel(surface", while bridge railings are angled, like this: "track〕under〔track". Anything other than that should be corrected, unless there is a good reason to keep it as an atypical variant. In the examples shown there is some variance concerning the width and radius of the arc and the angle of its cutting. Perhaps this could be discussed here. -- Tuválkin ✉ 01:44, 17 February 2014 (UTC)

Thickness

Useddenim's  (tSTR+1a), my  (tSTR2a) &  (utvSTR+1a) and Tuválkin's   (utSTR14lr) all have 50px-thick portals. In view of #Elevated structure elements below, do we agree to set this as the standard and redraw  (tSTRa) etc.? Moreover, this would provide for a uniform look in   (hTUNNELa) & co. YLSS (talk) 18:26, 11 July 2014 (UTC)

Length

dTUNNELa dTUNNELa dTUNNELa ×2 tvSTRa- + tv-STRa

A. In   (dTUNNELa) the portal scrapes the sides of the icon. (Yes, it should be redrawn as a curved one, but still.) In  (tvSTRag-) &  (tvSTRa-), portals are a bit smaller and thus provide for some space between parallel portals. Which one is better? YLSS (talk) 19:23, 11 July 2014 (UTC)

B.  (tSTRa) &  (tSTR2+4a) have really long portals, while  (tSTR2a) has a small one, like half-widths. Which option is better:

1. Leave as it is
2.  (tSTR2a) should have a portal of the same length as  (tSTR2+4a), much longer than in  (tvSTR-)
3.  (tSTRa) and all the rest should have small portals, so that =  

-- YLSS (talk) 19:23, 11 July 2014 (UTC)

C. Unless option B3 is selected,  (tSTRa) (which currently runs from 75px to 425px, plus the angles) can be redrawn in such a way that it matches either the elevated sidings so that it doesn't show up in  (tSTRa※ lhSTR)  (which possibly will be centered at 125px & 375px), or the "ears" of  (hSTRe) (which may change even more).

As a test, in  (tdSTRaeq) and  (uCPICCCre) I have used 50px-thick portals that run from 110px to 390px, and should thus be perfectly compatible with the modern elevated sidings. How do they look in comparison to the older designs? YLSS (talk) 09:47, 8 August 2014 (UTC)

I was just thinking about this the other day. If were going to redraw the elevated formation lines for greater flexibility, then we should also make the portal arch match the elevated-to-tunnel icons. Lost on Belmont (talk) 12:15, 8 August 2014 (UTC)

uextSTR14lr

separated from Talk:BSicon/Icon geometry and SVG code neatness#uextSTR14lr

uextSTR14lr utSTR14lr

|} And   (uextSTR14lr) should probably be redrawn to use the standard geometry of   (uÜWu4) and   (uÜWu1). Useddenim (talk) 20:08, 9 April 2013 (UTC)

 Done Useddenim (talk) 01:20, 13 April 2013 (UTC)

Hm, it is a tunnel, should be like (this), not like ❲this❳. I’ll give it a go. -- Tuválkin ✉ 04:40, 13 April 2013 (UTC)

Yes, it's do-able, but all other corner u/o's are rectilinear, rounded only being used for orthogonal lines. Useddenim (talk) 12:37, 13 April 2013 (UTC)

Okay, I changed the tips of the tunnel track at the corners and made the portals round in   (utSTR14lr), and it is now reflected in the diagram at the right (clear cache!). Opinions? -- Tuválkin ✉ 14:48, 11 July 2014 (UTC)

Elevated structure elements

old & new at 100px ...and at 20px

I have uploaded some new icons with a slightly revised geometry:

<path d="M 125,0 V 500 M 375,0 V 500" stroke="#80a080" stroke-width="50" />

instead of

<path d="M 120,0 V 500 M 380,0 V 500" stroke="#80a080" stroke-width="60" />.

This preserves the positioning of the inner edge of the structure with respect to the line and station elements, but moves the centreline of the structure elements to the 1/4 and 3/4 points of the icon, which will allow for better integration with elevated parallel lines. And with a difference of 0.4 pixels when displayed at 20 × 20, the two sizes should be able to peacefully coexist during the transition. Useddenim (talk) 12:14, 11 July 2014 (UTC)

Ah. I was wondering about this. I noticed this with  (uhKHSTe) when I used it in a template I'm working on. I saw that the lines didn't quite line up properly (and summarily "fixed it"). At the time I thought it was a slight oversight on your part, but I see now that it was otherwise. Do you plan on going back and changing the code in all of the other elevated icons so they line up properly? That would be a herculean feat! Lost on Belmont (talk) 12:38, 11 July 2014 (UTC)

Of course. It's just one more task on the endless list of "fixing" Wikipedia. Useddenim (talk) 14:37, 11 July 2014 (UTC)

It's now almost a year later in the discussion and I too, like Belmont before me noticed an inconsistency in the bridge 'railing' match between  (hSTRag) +  (hSTR) +  (hSTRef) while constructing a route diagram.

Having previously read the latest BSicon geometry standards I checked the  (hSTR) code and found it to conform to the current standards while the remaining icons appeared not to (some had a 40px railing width). Thinking however that one icon's discrepancy in a multitude of otherwise symetrical icons (though not conforming to the current standard), must be an anomaly, I reverted  (hSTR) to it's earlier 60px railing width. Belmont has since set me straight and pointed me to the discussion here (they also reverted my change to  (hSTR)).

I would certainly like to offer my assistance in updating the bridge icons to conform to the 50px railing width if getting this task done is a low priority on your 'to-do' list. The task while seemingly overwhelming with the multitude of icons to update wouldn't be huge considering it's a minor parameter change in the xml code of the icon files (download the svg file, edit the width parameter in an xml editor (I use Notepad++), save and upload). The only concern I have is are we applying the 50px railing width standard universally? As I noted above, some empty bridge icons used for multi-layered icon construction (like  (BRIDGE3+1o)) have a 40px railing width.

Cheers! MelioraCogito (talk) 23:40, 17 May 2015 (UTC)

Actually, a fair number of the elevated icons have already been converted. So far I seem to be the only one converting the older icons to the new standards which I have been gradually doing. Still, the more the merrier! So far I've been focusing on the "elevated" icons. Just be aware that the changes to the icons require repositioning of the formation lines as simply narrowing them will actually increase the negative space between the rail line and the elevated marks. Lost on  Belmont ^3200N_1000W  (talk) 00:26, 20 May 2015 (UTC)

@MelioraCogito: : The icons with 40px wide structures (the  (BRIDGE) family,the  (KRZo) icons, d icons, v icons with internal crossings, etc.) were deliberately drawn with narrower formations for clarity because of space limitations. These should be left as-is (so some of your conversions need to be reverted). Useddenim (talk) 20:07, 20 May 2015 (UTC)

@Useddenim: Yes, adjusting the location of the elevated forms along with the downsizing is being done concurrently with the updates. Lost on Belmont and I have been updating those icons which have yet to be done (we've covered a bit of ground over the last couple days). As for the medium length bridge elevated forms, IMHO they seem to be fine with the updated standards as set (50px on the ¼ & ¾ grid). The short bridge (culverts) are a different matter entirely, thus I've left them alone.

As I've gone through the icons, I've also been updating those icons still formatted to iso-8859-1 to UTF-8 format. Cheers! MelioraCogito (talk) 21:25, 20 May 2015 (UTC)

(d) +  (hSTR)  (STR-R※ hSTR)  +  (STR golden※ STR-L)   (hSTR) +  (d)  (leer+hl) +  (leer+h※ vSTR-ENDEa)  +  (vhLGD-Ra)  (leer+hl) +  (vSTR) +  (leer+hr)  (leer+h※ d)  +  (vSTR-ENDEe※ d)  +  (leer+h)  (nSTR※ d)  +  (uvSTR-ENDEa※ d)  +  (nSTR)  (nSTR※ c)  +  (uSTR※ c)  +  (nSTR) +  (d)  (hKHSTe) +  (d)

Yesss, I wanted to raise the same question. There would be quite a lot to overwrite, but not more than in case of lines in tunnel (and those are nearly finished). So, general benefits of switching from 60px-wide sidings centered at 120px/380px to 50px-wide sidings centered at 125px/375px:

• general symmetry of icons;
• sharp edges at 20px;
• a bit more space to squeeze something in to the left or right;
• closer to 40px-wide formations currently in use for smaller bridges, especially in half-width icons where 60px would be overmuch;
• algorithmically solvable way to deal with elevated parallel lines. Currently,  (leer+hl) &  (leer+hr) are commonly used in the neighbouring cells; but when juxtaposed with  (hSTR), they do not match. Similarly with  (leer+h), which currently doesn't align with anything except  (vhLGD-MRa) & co. A more neat option would be two use three icons instead of two, similar to +   + . This is more cumbersome with classic BS-templates, but in Lua it's pretty much the same: d!~leer+h\d!~uvSTR\leer+h vs. leer+hl\uvSTR\leer+hr (and you don't have to worry about the indices of On= or BSn).
• elevated sidings can even be regarded as thin lines of #80A080 set, like  (nSTR), which are expected to be 50px wide. For example,  (lhSTR) can be aliased as nvSTR laurel or something, and  (leer+h) as nSTR laurel.

-- YLSS (talk) 17:23, 11 July 2014 (UTC)

Bravo! I couldn’t have said it better myself. Useddenim (talk) 23:28, 11 July 2014 (UTC)

Diagonal + curve

separated from Talk:BSicon/Renaming#Diagonal + curve

Also, there's the matter of geometry. Why M 157.5,520 520,157.5 for the straight lines? M 411.6,-88.4 L -88.4,411.6 is better, 88.4 ≈ 125 / √2. WRT curves, I used L 482.3,194.5 C 400,276.8 375,400 375,500 (don't really insist that it's bezier or circular), with the intention that it approaches the side at 45° in precisely the same way as a straight line does. YLSS (talk) 21:32, 15 July 2014 (UTC)

Why? Well, I started out with the ol’ stroke=320/220/100 overlay, rotated it 45°, and then started plugging in numbers ’til I found something that works. It appears that M 157.5,520 520,157.5 and M 411.6,-88.4 L -88.4,411.6 are collinear (±1 pixel), so it doesn’t really matter which number set is used. I switched to circular curves because I thought you insisted on it when you redrew the curve-to-corner CONTs ( (CONT1+f) etc.) Besides, it makes calculating the formation lines much, much easier. Useddenim (talk) 00:06, 17 July 2014 (UTC)

Yes, in general circular arcs are better than bezier curves, and since  (CONT1+f) is not really compatible with  (STR+1) (there is a need for a tighter curve), I went ahead and used a circular arc. However, in  (uhABZ1+3f) we have a bezier (I tried using an arc for full-width ÜW-curves, and didn't like the result), so the sidings can follow that. But that doesn't really matter. I only pointted out that it's better to calculate the curve (of either type) in such a way that it terminates not beyond the border of the icon, but either at it or a bit before it (17.7 ≈ 25 / √2) and continue it as a straight line. YLSS (talk) 10:09, 17 July 2014 (UTC)

Position of "transition"

Midway

• When I drew  (hSTRe), I settled on the following: the "straight" part descends from top to 225px, and the "ears" run from 225px to 275px (plus the angles). Check the result to the right.
  
• In  (tSTRa), the left and right points of the portal are located at y=196px, and the middle point is thus at around y=235px (that is, at the center the portal runs from y=205px to y=265px).

If we decide to redraw these, possibly they can be matched somehow. Or, possibly, it would be better for the portal to be wholly above y=250px, with the portal of  (tSTRe) wholly below y=250px? YLSS (talk) 20:00, 11 July 2014 (UTC)

Cf. also the pairings  (tSTRag※ lhSTReg)  &  (PORTALg※ hSTRag) . YLSS (talk) 20:13, 11 July 2014 (UTC)

Portal location for tunnel entrance at icon edge

following the discussion at Talk:BSicon/Renaming#BHFCC & BHF+TUNNEL

Please compare these two →: Which is better, and why? -- Tuválkin ✉ 14:20, 24 February 2013 (UTC)

YLSS found another such case: added on top.→ -- Tuválkin ✉ 16:31, 24 February 2013 (UTC)

IMHO, the tunnel portal should be up tight against the station circle so that the line-type shows more clearly. (I.e. BHF OK, uBHF not OK.) Useddenim (talk) 17:59, 24 February 2013 (UTC)

When I drew  (uBHF) like that, the idea was to make it match the design of any station overlaid with  (PORTALf),  (PORTALg), or   (PORTALS). Conversely, that’s what   (BHF+TUNNEL) does (with  (TUNNEL legende)), and  (tBHFCC) does not. See added example above with  (exACC). -- Tuválkin ✉ 05:18, 26 February 2013 (UTC)

An overlay is (generally) employed when two images need to be superimposed when an icon for the combined design doesn‘t exist, and may not be optimal. So a new icon doesn‘t have to exactly match the overlaid pair. (For example, compare  (uTUNNELa※ ulBHF)  and  (utBHFa).) Useddenim (talk) 12:00, 26 February 2013 (UTC)

The matching I seek is when we use in the same or neighbouring diagrams, in a contrastative fashion, both a combined complex single icon and a several overlaid icons purporting to show the same semantics (for differing track colors or station types) and which therefore would be misleading if they look too different.

To be simpler and clearer: Portal masking the visible end of a track segmnent, be it at icon edge (as  (PORTALf) does) or at the station-track boundary (as  (TUNNEL legende) does), gives overlaying the power of neatly emulating this kind of BHFCC/a/e icons — therefore ready-made icons should show the same geometry. (Although even some “other color” icon sets include BHFCC icons…)

Visibility of little bits of is not important, as they are hardly distinguishable at typical display sizes and the concavity of the portal is enough to show where tunnels start and end.

That’s why I favour that

• tBHFCC/a/e icons should have their portals in the same position as those in  (TUNNEL legende) (“hugging” the station)
• BHFCC/a/e icons should have their portals in the same position as those in  (PORTALg) and/or  (PORTALf) (“plugging” the icon edge).

-- Tuválkin ✉ 14:00, 26 February 2013 (UTC)

(Meanwhile   (BHF+TUNNEL) was replaced by  (tBHFCC), which is drawn like  (utBHFCC). However the disabled and yellow icons, made by overlaying, still make the point I meant at first. -- Tuválkin ✉ 16:19, 14 March 2013 (UTC))

hBHFCCa red exhBHFCCa red hBHFCCe red exhBHFCCe red

hBHFCCa red exhBHFCCa red hBHFCCe red exhBHFCCe red

I've experimented a bit to see how these things pair up with curved sidings. In case of ground-to-tunnel transition, I prefer the "hugging-the-station" portals, as in  (uextBHFaf). However, in case of elevated-to-tunnel transition, the curves leave us with two options: either to use the "plugging-the-edge" portals –   (hBHFCCe red), or to "embed" the portal into the sidings –   (exhBHFCCe red). My impression is like this: at full size,   (exhBHFCCe red) looks a bit puzzling; however and more importantly, at 20px that feeling disappears, while   (hBHFCCe red) on the contrary looks crooked. YLSS (talk) 00:02, 16 January 2015 (UTC)

Once more: how do you guys feel about “splitting the difference” with   (exhBHFCCa red)? Useddenim (talk) 01:31, 16 January 2015 (UTC)

This is exactly what I was thinking. Lost on  Belmont ^3200N_1000W  (talk) 01:41, 16 January 2015 (UTC)

  (hBHFCCa red) then, for consistency. (Last night I thought it would be impossible to calculate this curve... And now I found out that I don't need to, visual approximation in this case is quite enough even at 500px.) YLSS (talk) 13:12, 16 January 2015 (UTC)

Unification?

I've been brooding on these questions for some time, but I've always been postponing a massive discussion. However, the recent uploads and comments show that we all think pretty much the same, so the time has finally come to settle this down. YLSS (talk) 15:55, 11 July 2014 (UTC)

Bridge gap in tower stations

I just noticed that the bidge gap of  (THSTu) is more clear and nice looking than of  (exTHSTu) — and such others also).

Gallery

These should all be redrawn to match, right? (I note that the  (THSTo) series, both colors and all states, was already fully fixed.) -- Tuválkin ✉ 23:52, 20 January 2015 (UTC)

They should be 50px-thick in any case. Possibly centered at 100px/400px vertically. Or maybe not. Are you in the mood for experimenting? ;) YLSS (talk) 15:50, 21 January 2015 (UTC)

I knew you’d say that. Definitely everything to make these standard, matching all other bridges: That’s 50px thick, for sure now, and matching the placement of elevated formations. I'll try to work on it. -- Tuválkin ✉ 20:15, 23 January 2015 (UTC)

matching the placement of elevated formations: I'm not sure of that... I haven't touched the question of precise geometry of bridges/crossings, because solving that is pretty insurmountable. After all, there's  (vKRZo-STRr) vs.  (vKRZu-STRr),  (BRÜCKE) vs.  (BRÜCKE1) vs.  (BRÜCKE2),  (BRIDGEq) vs.  (vBRIDGEq-) vs.  (dBRIDGEq),  (SKRZ-Au) vs.  (vSKRZ-Au) vs.   (vSKRZ-Ahe) and so on and so on... So I'm totally at loss what to suggest here. YLSS (talk) 10:49, 24 January 2015 (UTC)

Elevated start/end

Legend

uhvSTRla uhvSTRra uhvSTRla uhSTRag uhvSTRra uhvSTRle uhvSTRre uhvSTRle uhSTRef uhvSTRef File:BSicon uhvSTRla.svg hvSTRa-STR red uhvSTRla ※ v-STR hvSTRa-STR red hvSTRe-_red ※ v-STR

(The icons on the left and right of the first two rows should be renamed, but that can be done later.) For parallel lines, should the bridge end things go off by 70px horizontally and 50px vertically (current standard for single lines), or should they be 40px horizontally (like  (hvSTRe- red) was before I changed it to the 70px horizontal ones)? If they remain 70px horizontal and 50px vertical then the bridge endings could overlap with a second parallel line.

The   (uhvSTRla) series, older than the set red parallel icons, is definitely off (75px both axes), and should be changed to use a different offset.

Pinging Fukuokakyushu2012, Imperator3733, BjørnN, Useddenim, Lost on Belmont, Tuválkin and YLSS. Jc86035 (talk • contributions • uploads) 08:53, 26 September 2015 (UTC)

Well, don’t ask me, I missed this train (pun!) long ago, and not sure I agree with much of these changes, at all. But I’d say that things like   (hvSTRa-STR_red) look way stumpy at 20×20 px and that there’s nothing wrong with the kind of overlay shown in things like File:BSicon uhvSTRla.svg (uhvSTRla※ v-STR) : After all when we have “close” paralel tracks of which one is starting or ending its elevation, it’s bound to be messy — both in diagrams and in the real life. -- Tuválkin ✉ ✇ 09:33, 26 September 2015 (UTC)

@Tuválkin: I deliberately changed   (hvSTRa-STR red) to be 49px down and 35px across so as to keep the same angle but prevent overlapping; I forgot to mention this in my earlier post. So all of them should be changed to standard 70px across and 50px vertically? Jc86035 (talk • contributions • uploads) 12:38, 26 September 2015 (UTC)

It’s no big deal, either way. I’m good with whichever outcome, provided it is consistent across the whole set. -- Tuválkin ✉ ✇ 23:14, 26 September 2015 (UTC)

I would still prefer the un-overlapped bridge-formation, but a 70-50 is what is standard. I do not really care too much about the outcome of this particular discussion as I don't find any of the solutions "stumpy" or too problematic if overlapping, as long as a consensus that does not result in too much painstaking correction of the entire set of hSTR icons is reached.

Tuvalkin: As for being "bound to be messy — both in diagrams and in the real life", here is some messy real-life Japanese engineering for you. Please note what is past the end of the station platform. Fukuokakyushu2012 (talk) 15:02, 26 September 2015 (UTC)

That’s a neat photo, but not really what I mean: Parallel tracks’ profiles assume back-to-back loading gauges (plus a fixed safety gap width); the formation would need to be paper thin for this to work. In, reality the beggining of an elevation has its track more distant from the rest than any two regular tracks. -- Tuválkin ✉ ✇ 23:14, 26 September 2015 (UTC)

I understand now what you are saying about the beginning of a track gradient, but RDTs are in and of themselves diagrams, so do the parallel lines series of BSicons actually have to be that strict? (I am still fine with the outcome of this, whatever it may be, but am just curious as your explanation of Parallel tracks differs from what I thought to be the generally accepted usage of the icons.) Fukuokakyushu2012 (talk) 17:18, 27 September 2015 (UTC)

Why not just standardize @ 50px × 50px, which would make orientation irrelevant? (Or maybe a slightly lower value, to remove any overlap at the same time.) AlgaeGraphix (talk) 21:34, 26 September 2015 (UTC)

That would be a welcome simplification. -- Tuválkin ✉ ✇ 23:14, 26 September 2015 (UTC)

@AlgaeGraphix and Tuvalkin: I think either 60px × 60px or just the current one would be better; 50px × 50px would probably be considered "stumpy". Keeping the current 70px × 50px isn't really a huge problem, since in the small number of cases where there is a bridge beginning as well as a track parallel to the bridge, one of the tracks could simply be shifted by one quarter. Jc86035 (talk • contributions • uploads) 08:18, 28 September 2015 (UTC)

Crossings

I just created some kKRZo icons (  (kKRZ2o), etc.) with 50px formations offset 125px to match  (hSTR) icons, and then noticed that Imperator3733's curved crossings ( (KRZ2+ro) etc.) have 40px formations closer in, similar to the older crossing icons. Any thoughts about what the standard should be? Useddenim (talk) 02:05, 21 November 2015 (UTC)

Let's have everything at 50px, no reason (now) to have differing thicknesses. -- Tuválkin ✉ ✇ 04:13, 21 November 2015 (UTC)

Agreed. Lost on  Belmont ^3200N_1000W  (talk) 17:17, 21 November 2015 (UTC)

What about things like  (dKRZo)? Useddenim (talk) 21:18, 21 November 2015 (UTC)

See... Crap like this is why I hate formations on narrow icons. Lost on  Belmont ^3200N_1000W  (talk) 20:06, 26 November 2015 (UTC)

Three-quarter shifts

Legend

hvSHI3l+R hvSHI3l hvSHI3l+L

(pinging Useddenim, Tuvalkin, Lost on Belmont) So for some reason I thought it would be a good idea to make three-quarter parallel shift elevated icons. Unfortunately the edges don't really align with the straight ones; is there a workaround? Jc86035 (talk • contributions • uploads) 10:07, 5 August 2016 (UTC)

Maybe a special set of vSHI3 icons needs to be created? Doesn’t seem neat at all… -- Tuválkin ✉ ✇ 02:49, 30 January 2017 (UTC)

@Tuvalkin: At the time I didn't realize that  (vSHI2l) etc. didn't have an exact 250px track centre all the way through, and since I tried to do that with the vSHI3 icons I uploaded they don't look very nice. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:20, 30 January 2017 (UTC)

uBHFCCe

moved from User talk:Useddenim

Re  (uBHFCCe): Is the formation supposed to be above or below the station circle? Just checking, as most of the others in the group have the circle above the formation. Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me 11:25, 3 December 2016 (UTC)

IRL the tunnel portal is above the track… Useddenim (talk) 12:58, 18 February 2017 (UTC)

I've created most of the possible combinations (playing around in Terminal's command line) with the portals moved slightly and over the station circle as with   (BHFCC sky), but I'd rather not upload them yet since we might end up renaming them. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:50, 18 February 2017 (UTC)

Formations

@Useddenim and Tuvalkin: Should 90° ABZs use an angular inner formation  (uehABZlf) or a smooth inner formation  (uxhABZlf)? (Would this apply to  (uhABZl+l)?  (hABZf+1r) for comparison.) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:34, 17 February 2017 (UTC)

Straight lines when ‘in’ and ‘out’ are directly opposite each other (e.g.  (uhABZl+l),   etc.), otherwise sharp corners (i.e.  (uehABZlf) (hABZf+1r) OK,  (uxhABZlf) not). Useddenim (talk) 13:09, 18 February 2017 (UTC)

STR2+1 vs. hSTR2+1

STR2+1 hSTR2+1

I have created the set of elevated curves between adjacent corners (2+1, 23, 3+4 & 14) that uses a “squarer” curve than the existing icons, so that the formation lines are (i) tangents at 45° at the icon edge, and (ii) completely on the icon to the the inside of the curve. (The mid-point of the existing curve is 125px from the edge of the icon, i.e. the same point as a parallel line.)

One happy result of this geometry is that the 90° junctions more closely resemble the orthographic versions rotated 1/8 turn:
 (uhABZ3+14)  (uhABZlg). Useddenim (talk) 11:43, 29 May 2014 (UTC)

Hm.. I have previously dabbled into this area, and File:BSicon lhSTR-L3+4.svgFile:BSicon lhSTR-R3+4.svg (STR3+4※ lhSTR-R3+4※ lhSTR-L3+4)  is pretty much everything that is possible without changing the shape of the curve (can be seen live at en:Template:DLR Route diagram). So possibly your solution is better. However, I hope nobody thinks about changing the geometry of  (STR3+4): it's a great feat that is can be overlaid with  (lvHST-),  (vSTR+4-) etc. YLSS (talk) 15:49, 31 May 2014 (UTC)

While I appreciate the idea (and the skill!) behind this alternative curve shape in  (hSTR2+1), I’d say that there should be no reason to have the track shaped any different from  (STR2+1). The latter has the evident advange of allowing vertical alignment in things like  (STR2+1※ vSTR+4-※ exvSTR) , as said, and we all think that’s a good idea.

The conundrum that a differently shaped  (hSTR2+1) addresses is caused by the position of the elevated structure elements, which is being (finally!) analized below; I expect that the matter here will be moot once that is improved.

-- Tuválkin ✉ 03:25, 12 July 2014 (UTC)

'hSTRc2'hSTR3 'hSTR2+1'hSTRc3

@Useddenim and Tuvalkin: Tried updating the elevated icons with narrow formations (and a circular curve); any issues? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:29, 29 January 2017 (UTC)

Doesn't look like you quite have it correct for the inside curve. Useddenim (talk) 17:50, 29 January 2017 (UTC)

That can be easily fixed, I suppose (@Jc86035: ), but I still think it “should” mimic File:BSicon lhSTR-L3+4.svgFile:BSicon lhSTR-R3+4.svg (STR3+4※ lhSTR-R3+4※ lhSTR-L3+4)  (though I’m not adamant). -- Tuválkin ✉ ✇ 02:43, 30 January 2017 (UTC)

Matching the non-elevated (*)      Same as above *(outd. template!)

@Useddenim: Put the curve slightly further away from the edge; is this good enough or should it be a little bit further away? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:21, 30 January 2017 (UTC)

@Tuvalkin and Jc86035: At 20px × 20px I'd prefer a smooth curve over a fractional misalignment. Useddenim (talk) 11:07, 30 January 2017 (UTC)

@Useddenim: Smoothened it a bit more, although it's now a bit wider than the original one was. I think making it the same as the non-elevated version would require the use of an auxiliary icon, like  (hSHI1r+R), but if that's what we want… Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:16, 30 January 2017 (UTC)

@Useddenim: Maybe a solution like  (uhdSTR+4+R) +  (uhvSTR+4-SHI2gr) might be better? (Would the corner icons be named hSTR23+E, hSTR23+F or hSTRc2+3?) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:21, 17 February 2017 (UTC)

Stick with hSTRc2+3; we don’t really want to create additional suffixes that would be very rarely used. Useddenim (talk) 12:55, 18 February 2017 (UTC)

@Useddenim: If so, would such an icon looping around all four corners be named hSTRc1+2+3+4+1? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 15:01, 18 February 2017 (UTC)

@Useddenim: An issue with not having +A/+E suffixes is that there's no way to indicate (for example) the top formation icon for  (hvSTR+lg-). (Both hSHI1 and hSHI2 formation icons don't line up exactly.) It could be named hv-STR+rg+Lq, but that might be a bit too confusing. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:51, 21 February 2017 (UTC)

There are now five icons with the +G and +F suffixes, so this will be basically resolved when the aforementioned icons are uploaded. Jc86035 (talk) 09:38, 13 August 2017 (UTC)

SBRÜCKE

@Useddenim, Tuvalkin, and Axpde:

1. Why the difference between  (vSBRÜCKE) and   (vSBRÜCKE-) and  (SBRÜCKE)?
2. Is an SBRÜCKE supposed to be a pedestrian bridge, or am I missing something?

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

okay, so there's  (SBRÜCKE1) (≈   (vSBRÜCKE-)), but they're all still slightly different for some reason… Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:55, 5 March 2017 (UTC)

SBRÜCKE is originally a Street bridge only, with no track running across ... a×p_de^Hello! 15:06, 5 March 2017 (UTC)

@Axpde: Are all four of them supposed to have different widths? Should they be standardized? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 15:13, 5 March 2017 (UTC)

Well, the original BSicon wasn't supposed to be overlaid by tracks running aqross, so there was no need to make the bridge too wide. How about two versions: One narrow as standalone and one wide for overlaying? a×p_de^Hello! 15:49, 5 March 2017 (UTC)

SBRÜCKE1 File:BSicon vSBRÜCKE-.svg BRIDGEq

@Axpde: Okay. I would use the formations from  (v-BRIDGEq) for the wide ones and the existing  (SBRÜCKE) formations for the narrow ones, although I don't really mind because they're all a bit inconsistent anyway. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 16:09, 5 March 2017 (UTC)

Icon	Created	Creator
(SBRÜCKE)	4 October 2006	Bernina~commonswiki
(vSBRÜCKE)	22 June 2007	Lantus
(vSBRÜCKE-)	19 November 2013	Géofer
(SBRÜCKE1)	24 May 2015	MelioraCogito

@Useddenim and Axpde: I've renamed the vSBRÜCKE-/v-SBRÜCKE group to use vSBRÜCKE1 instead. How do these fit with  (hNULl) etc., the  (BRIDGE) group and   (BRKukf)/g? (See also Talk:BSicon/Renaming#NULs.) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:38, 26 March 2017 (UTC)