Talk:BSicon/Icon geometry and SVG code neatness/Archive 2

Corner to side in narrow icons?

This  (dSTRr+1) is probably against the gods of geometry: Too narrow for the natural curve of  (STRr+1) to develop, I’m afraid. And the one use of it doesn’t do it any justice. -- Tuválkin ✉ 04:07, 16 April 2012 (UTC)

Exactly, half-width icons are too small to show "ÜW"-type curves. The earstwhile use of this icon is definetely no reason to keep that awkward icon. That's why I "reused" the name, see Talk:BSicon/New icons and icon requests#Half-width curves. Regards a×p_de^Hello! 20:59, 9 May 2013 (UTC)

LUECKE dots as dashes

Just take a look at File:BSicon_mevLSTR.svg and see what Magasjukur2 did there. LUECKE dots as dashes of a path instead of discs placed along an immaginary path means much faster and simpler creation of LUECKE icons. Good work! -- Tuválkin ✉ 00:02, 27 July 2012 (UTC)

More Grenzen

Corners to be not needed

GRENZE2lg+rf
doesn’t need corners

GRENZEr
needs corners!

About these recent additions to the Category:Icons for railway descriptions/experimental/borders:

•  (GRENZEg)   (GRENZEf)   (GRENZEl)   (GRENZEr)
•  (GRENZErg)  (GRENZElg)  (GRENZElf)  (GRENZErf)

I have naming, topology, and geometry issues about them, even though I think they are a frankly positive and welcome-worthy addition. Here's the simplest of those comments:

The series  (GRENZEg)  (GRENZEf)  (GRENZEl)  (GRENZEr), as drawn by AlgaeGraphix, is meeting the icon corner with a piece of stroke showing, not a gap (unlike all the older ones: cp.   (GRENZE2x) etc.). That demands the need for corner icons, and needlessly so, IMHO. A slight change in the width of both strokes and gaps would fix this, with no noticeable aesthetics drawback.

-- Tuválkin ✉ 16:37, 29 October 2012 (UTC)

As long as you remember they are supposed to form a perfect circle when combined, no one will complain if you fix the things. Circeus (talk) 17:24, 30 October 2012 (UTC)

Point taken. Is this better? AlgaeGraphix (talk) 13:24, 31 October 2012 (UTC)

Hmmm… still need to work on the corner-to-corner version–compare with the revised quarters. AlgaeGraphix (talk) 15:49, 31 October 2012 (UTC)

If you look closely at the original attempt, you'll see that if it were made of a simple line, you should (or so it looks anyway) get a perfect fit bit shifting it a little counterclockwise, with five dashes to the icon. Circeus (talk) 19:57, 31 October 2012 (UTC)

I «tried this at home» and four dashes to the icon is a better approximation than five. I’ll be uploading the new icons ASAP. -- Tuválkin ✉ 12:29, 4 November 2012 (UTC)

 Done -- Tuválkin ✉ 12:54, 4 November 2012 (UTC)

Gapping and symmetry

GRENZE2 exlGRENZE GRENZE2

(Besides, the details of the stroke/gap sequence are assymmetric for some of all these new ones. A general fix is in order?) -- Tuválkin ✉ 16:37, 29 October 2012 (UTC)

This → is my idea (for a general fix on gapping and symmetry). Please compare modified  (GRENZErf) with unmodified  (GRENZErg). -- Tuválkin ✉ 04:32, 30 October 2012 (UTC)

I agree with the problem and I don't think a conversation was needed to do fixes (other than signaling the issues to the uploader). Circeus (talk) 17:19, 30 October 2012 (UTC)

 Done (75% done by AlgaeGraphix, not me!) -- Tuválkin ✉ 18:46, 1 November 2012 (UTC)

Color Sets

Moved to Talk:BSicon/Colors.

Passing siding

PSLr PSL already existed PSLl

|}

I found no icons for a passing siding so I made some: How would these icons look:

Deonyi (talk) 13:42, 12 April 2013 (UTC)

Looks good. A bit excessive code, but at least no inkscape tags. I would've used the following:

  <g stroke="#BE2D2C" fill="none">
    <path d="M 250,0 V 500" stroke-width="100"/>
    <path d="M 275,20 C 275,75 375,95 375,150 V 350 C 375,405 275,425 275,480" stroke-width="50"/>
  </g>

--YLSS (talk) 14:14, 12 April 2013 (UTC)

Needs more white-space between the loop and the main—see the u example. Useddenim (talk) 23:12, 12 April 2013 (UTC)

Remainder of set added:  (ePSLr)  (ePSLl)  (uePSLr)  (uePSLl)  (exPSLr)  (exPSLl)  (uexPSLr)  (uexPSLl) Useddenim (talk) 23:30, 12 April 2013 (UTC)

Déjà vu... YLSS (talk) 00:57, 13 April 2013 (UTC)

Getting confused. Why isn't the icon updating? Deonyi (talk) 01:22, 13 April 2013 (UTC)

Parallel lines krw + 1/2 shift

While fiddling around en:Adelaide_–_Port_Augusta_Railway I noticed that either I'm using them incorrectly or the uvSTRc# icons do not actually line up. Circeus (talk) 19:41, 25 September 2011 (UTC)

Hmm…  (uvSTRc2) was drawn to match up with  (uvSTRer). I hadn't considered other uses. Useddenim (talk) 19:51, 25 September 2011 (UTC)

Now I'm wondering if the whole group should be redrawn so that they will also match to the KRW icons ( (uKRWgr) etc.)? Wiebevl suggests using the half-width icons  (udSTR+l) &  (udSTRr) or   (udX+l) &   (udXr). Useddenim (talk) 20:15, 25 September 2011 (UTC)

Do you mean that  (uvSHI2r-) is not supposed to be the upper corner of  (uvSTRer)? Kinda odd... Circeus (talk) 20:35, 25 September 2011 (UTC)

---

udXl udWg+r udXl udWg+r uexdXl uexdWg+r uexdXl uexdWg+r

When I grouped several icons into Category:Icons for railway descriptions/set u/parallel lines/krw, I though them to be usable together; however, it proved otherwise. The earliest of them (top left quarter) are those uploaded by Useddenim, and they are usable together, naturally. The "uex" corners were later re-uploaded bu Vunz with the summary "connection fix"; they do connect together now (middle row), but not with 1/2 shifts (top right quarter). On the other hand, we have four krw icons uploaded by Tuválkin, which, again, do work together; however, they also work with the new "uex" corners (bottom right quarter). So I guess it would be better to redraw all non-ex icons and "uex" shifts? (BTW, the same names are occupied in the basic red set by 1/4 shifts! These tables look quite funny. But this should (or was?) discussed elsewhere.) YLSS (talk) 11:23, 24 April 2013 (UTC)

These icons should also match with the half-width ("d") versions: dX~ (without branch) and dW~ (with branch). Useddenim (talk) 14:29, 24 April 2013 (UTC)

Yup, now it's 100% clear that the "uex" corners are correct, and "u"/"uex" 1/2 shifts should be redrawn. As well as "ud" corners, BTW. YLSS (talk) 15:54, 24 April 2013 (UTC)

Re-uploaded "uex" 1/2 shifts. The inner curve is less smooth now, but some things have to be sacrificed. Should I proceed with "u" icons? YLSS (talk) 18:39, 24 April 2013 (UTC)

I was going to ask, “If not you, then who?”, but I think Tuvalkin has already answered that question… Useddenim (talk) 10:45, 25 April 2013 (UTC)

(Grumbling and mumbling...) All  Done. (Actually, I do not really get why Tuválkin had to upload these one by one... ) I just wanted to know if it's OK that the lines would be not so smoothly parallel as in your original design. YLSS (talk) 14:52, 25 April 2013 (UTC)

I did those 3 one by one because I didnt have much time and wanted (us to) test if it was working as intended. -- Tuválkin ✉ 16:05, 25 April 2013 (UTC)

How’s the bahn-red version of these? Also messed up, or doe it match? -- Tuválkin ✉ 20:45, 29 April 2013 (UTC)

There are no such icons for the bahn-red set. The names are occupied by other icons, as you've pointed out yourself a year ago. YLSS (talk) 12:01, 4 May 2013 (UTC)

Thin Lines

I noticed this strange icon quote browsing:   (KBSTl-C) What does the thin line mean? Deonyi

As I understand the matter, it stands for a siding, generally a single-track service line. In the "u" set, it is additionally employed for a feeder; or for example, it can be used for a canal of lesser width than another one. See Talk:BSicon/Renaming/Archive 2#Siding icons. YLSS (talk) 18:55, 28 June 2013 (UTC)

I see... but why does it have a depot at the end? It may confuse readers.00:30, 29 June 2013 (UTC)

A small circle can also signify a factory, works, or even siding(s). Useddenim (talk) 16:08, 29 June 2013 (UTC)

I guess that works too. Deonyi 09:20, 30 June 2013 (UTC)

INT circle radius

moved from User talk:Axpde/Archive 3#INT circle radius

There are (or had been) some uncertainties with the correct measurements of the width and stroke-width of the circle. From what is calculated, the total radius of the circle = (width) + (1/2)*(stroke-width) and this value is expected to be 150 to match that in the BHF icon. The syntax is given by:

<circle cx="250" cy="250" r="___" stroke-width="___"/>

where "r" represents the width (or radius, without the stroke border). There are several measurements used in the INT files:

Width value	Stroke-width value	1/2 Stroke-width value	Total radius	Sample BSicon		Comments
123.853	52.2936	26.1468	149.9998	uINT		Currently used on most INT icons, with a few changes in decimal places in the stroke-width for certain files.
120	60	30	150	utKINTr	File:BSicon utKINTr.svg	Closest rational values, but with a rather thick border.
123.5	53	26.5	150			Possible set of measurements (1) with close resemblance to the first one.
124	52	26	150			Possible set of measurements (2) with close resemblance to the first one, if integer values are desired.
120	60	30	150	DST		used by all DST-type BSicons
120	60	30	150	TokyoMita		used by all (13) Tokyo Metro special BSicons

It is actually not advisable to use smaller values for the width of the circle itself, because of the use of the INTACC icons involved. What is your take regarding this - do you intent to standardize the measurement for all INT icons? Regards, NoNews! 12:34, 21 May 2011 (UTC)

Well, a good question. Actually I never cared for those special icons created by w:en:, it was enough effort to ensure a consistent naming scheme at least for those icons used by w:de:. If you want to hear my thoughts about it, I'd suggest to use the same parameters as all DST-type BSicons do. Regards axp_de^Hello! 18:12, 21 May 2011 (UTC)

I just fixed this one  (fINT) (misnamed ^{as BHF tr, meanwhile renamed (-- Tuválkin ✉ 14:07, 3 August 2012 (UTC))}, too). -- Tuválkin ✉ 00:22, 30 November 2011 (UTC)

So what exactly should the values for the circles be? The specified values appear to be the old ones. Lost on Belmont (talk) 23:54, 15 November 2014 (UTC)

That's some error, we settled at 60px for full-sized stations. YLSS (talk) 12:13, 16 November 2014 (UTC)

All DSTs are stroke-width=50 and this is "up2date". Conc. INTs I have no preference, obviously it was settled to use the same values as the DSTs rather than smaller circles. a×p_de^Hello! 08:26, 16 November 2014 (UTC)

You must be mistaken. DSTs were always 60px, even in Bernina's  (DST) from 2006. YLSS (talk) 12:13, 16 November 2014 (UTC)

Interchanges too?

moved from Talk:BSicon/Renaming#ugINT

BTW, Tuválkin, are you really going to re-upload all INT-interchanges? I thought that discussion only concerned the circle radius. The "extended" versions currently use either 52.smth or 50. (I've uploaded a couple using the latter.) YLSS (talk) 14:20, 18 June 2013 (UTC)

I assumed the above applies to all INTs. I see avdantages:

1. They look better together: vs. (blues were not modified yet).
2. The current icons, regardless of the measures, are messy, with sloppy SVG causing rendering issues — they could use a rehaul.
3. The same values for both round and pillbox shapes allow for combinations both like this File:BSicon lINTl.svgFile:BSicon lINTr.svg to look identical to this , and like this one File:BSicon lINTl.svg to look identical to this other , just like we do routinely with DSTs and BHFs.

Of course, while this change is being done, some icon pairs will look crooked. -- Tuválkin ✉ 17:26, 18 June 2013 (UTC)

Diferent design

File:BSicon lDSTr.svg File:BSicon ulDSTr.svg File:BSicon ulDSTr.svg File:BSicon lDSTr.svg ulDSTr

Just an aside: Icons   (lDSTr) and   (ulDSTr) should be identical except for line color but, even if both use stroke thickness of 60 nominal pixels, the different curve type (quadratic bezier v.s ellipse) gives slightly different results (red is thicker), which is not acceptable. There may be more cases like this -- Tuválkin ✉ 04:42, 30 June 2014 (UTC)

The issue is not with circle vs. circular arc in path (which do indeed produce different results, but just on the verge of noticeability at 500px), but in that   (lDSTr) has the radius of 125 instead of 120. So it's a singular mistake, not a trend. YLSS (talk) 08:05, 30 June 2014 (UTC)

Ugh 125 > 120 indeed, I should have noticed the obvious! Thanks, YLSS! -- Tuválkin ✉ 15:57, 10 July 2014 (UTC)

Urm, but you did pretty much the contrary. Better replace that with a circle, and don't forget   (lDSTl) ;) YLSS (talk) 16:09, 10 July 2014 (UTC)

I just  did that, after some coffee… :-) -- Tuválkin ✉ 16:20, 10 July 2014 (UTC)

DST,ACC,INT

Is it currently now standard for the INT borders to be 60 or 50? The current version as seen here:  (gINT) looks and feels too small when placed next to standard BHFs. In fact, one would possibly propose that the size of the interchange icon to be slightly increased simply due to the fact that when placed along with other icons, it looks far too small, tiny and unimposing. 22:28+22:25+22:24, 18 June 2013‎ Deonyi‎

It may be like this as INTs have a black border which recedes into the grey. However, it seems the thinning of the border also helps alleviate this issue. 22:28+22:25+22:24, 18 June 2013‎ Deonyi‎

Small DST & INT

What are the standard values for "small" DSTs and INTs, those with the total radius = 125? r="100", stroke-width="50", right? As in  (uvKDSTe-STR) &  (uvINT-STR). YLSS (talk) 00:50, 22 October 2013 (UTC)

DST and INT are not distinguishable

See also: Talk:BSicon/Colors#Black.

Seeing the old discussion of #INT circle radius makes me think that we should do something to make the 2 sets of icons more distinguishable. The current similarity of the two is quite color weakness unfriendly. My proposal is to shrink the radius of the inner white circle of DST like this File:BSicon sameboat001.svg, so it's now easier to tell the different to INT . The reason to modify DST rather than INT is that the inner circle of INT may contain ACC icon, even though INTACC doesn't work quite well in 20px width. -- Sameboat - 同舟 (talk) 02:11, 9 August 2013 (UTC)

Let me strongly disagree with this solution, based mostly on esthetical grounds. The rationales for change are also weak in my opinion — this whole concept is «color weakness unfriendly», there’s no way around it: We use for fundamental semantics distinctions both colors (light vs. heavy) and shades (in use vs. disused), and that poses the same kind of “unfriendliness” the DST/INT causes. -- Tuválkin ✉ 11:08, 9 August 2013 (UTC)

I rather you ignore this topic than giving a heartless and weak response. -- Sameboat - 同舟 (talk) 00:49, 11 August 2013 (UTC)

I couldn’t care less what you’d rather I’d do. You wont get to say that nobody was against this idea in case you decide to go away and start implementing it. -- Tuválkin ✉ 03:56, 11 August 2013 (UTC)

There's no ground to judge a simple geometric icon bad or good by aesthetics. It only demonstrates you rejected my proposal because "I don't like it". The visibility problem is long standing so that I don't support the idea to add in more color sets for different lines of the same railway system like the Russian users do. I just have no right/privilege to stop it. However, it hurts me to hear my RDT fellow to imply "there is a mess, don't attempt to fix the mess, even for one of them." You didn't even give an alternative proposal even if my take on the new DST is so bad in your HUMBLE opinion. To answer your last question: no, I wouldn't do anything if no one respond to my proposal. I would just let it go, but I find your reply so unbearable to read. -- Sameboat - 同舟 (talk) 11:30, 11 August 2013 (UTC)

He makes a good point. That DST looks horridly obese, like it has been eating too many doughnuts. If using black DSTs really bother you, just add a white ring around the INT icon to help differentiate. Not replace simple, clear icons with obese ones. User:Deonyi 08:23, 13 August 2013 (UTC)

And the current version looks like they have anorexia, if we must be aesthetic. Please provide some idea on the classic red set instead of other unrelated color set. -- Sameboat - 同舟 (talk) 06:33, 14 August 2013 (UTC)

Sameboat, sorry, but I would also vote against such a radical proposal, and likewise primarily on aesthetical grounds. The main issue here is that people around the would are used to different designs, and it would be better to provide them with a diagram that they would readily understand (unless of course it would confuse others). For example, en:Template:Sokolnicheskaya Line was quite dazzling for me at first because of the blue colour (instead of red) and by the peculiar INT stations; DSTs, on the other hand, are more intuitive. Colour blindness in case of different lines at the same diagram is usually solved in Moscow Metro by providing numbers next to the line's termini. In case of DST/INT, using both in the same diagram can be possibly avoided (e.g. having different diagrams for different purposes, like here); or one can use  (BHF-L) or various HUBs. YLSS (talk) 18:27, 13 August 2013 (UTC)

My whole point is that we cannot soly rely on color to differentiate 2 icons of exactly same shape. Is there is no way to improve the visibility because DST is so unmodifiable? Please bear in mind I am talking about using the original red set. How the black set unreadable does not concern me. -- Sameboat - 同舟 (talk) 05:56, 14 August 2013 (UTC)

But why exactly is colour so bad? Keep in mind the text generally also offers clues as to the purpose of the icon. I very much doubt 'Hollocks Street Depot' would be a station.User:Deonyi 07:21, 14 August 2013 (UTC)

This is not always obvious to the reader. For example, en:Template:East London Line RDT, without checking the article of en:TMD, I wouldn't know what it stands for in "New Cross Gate TMD", it is not linked. While YLSS suggested that reader can hover over the icon. Did you know that mobile device does not have the hover function? It does not matter whether the mobile reader is browsing in desktop mode or mobile mode. If we are using the same shape for two icons of different purposes, the icon itself must be totally unambiguous. The shape is causing problem now. -- Sameboat - 同舟 (talk) 08:49, 14 August 2013 (UTC)

Yes, I'm aware of all that. But I would say that the problem is not in the DST shape, but rather in using DST and INT in the same diagram. Personally, I would replace INTs with something else: either we provide a purely schematic diagram that only shows general topology, interchanges and other passenger business (like pt:Predefinição:Metro de Lisboa/Linha Verde), or else we fully immense into technical details, with parallel tracks, depots and relative positioning of stations (like in infobox at pt:Linha Verde (Metropolitano de Lisboa)). YLSS (talk) 09:51, 14 August 2013 (UTC)

It doesn't matter how you personally use the icons. Ton of UK maps use INT and DST in the same map. The problem of ambiguity can't be magically solved by your own habit. -- Sameboat - 同舟 (talk) 10:25, 14 August 2013 (UTC)

I have long lost the belief that anything can be solved magically in the BSworld. YLSS (talk) 11:25, 14 August 2013 (UTC)

Then what about substituting  (QST) for  (DST) and  (RST) for  (BST)? Useddenim (talk) 12:43, 14 August 2013 (UTC)

In the ideal world I would like to separate freight station and depot. -- Sameboat - 同舟 (talk) 14:43, 14 August 2013 (UTC)

Seriously I'm fine with any new shape of DST or INT as long as they keep things simple. QST and RST do the trick for me. The only comment I have for QST is that I recommend changing the square to slightly thinner rectangle in case of dQST (half width version). -- Sameboat - 同舟 (talk) 16:17, 14 August 2013 (UTC)

I drew it that size so it would not be necessary to change the existing  (DST-M) et al. However, compare the circle size of  (BHF) with  (dBHF). Useddenim (talk) 20:32, 14 August 2013 (UTC)

I had also considered using ◆ instead of ■, but realized that would create problems when joining to adjacent icons. Useddenim (talk) 20:46, 14 August 2013 (UTC)

Honestly, it looks fine right now. Differentiating between DST and INT is really easy if you are using the standard colours. You can also click on the icons to get to its description page. There are legends too. Changing a simple shape into a square is a bit superfluous to me. User:Deonyi 22:03, 14 August 2013 (UTC)

Using rectangular shape instead of square wouldn't require modifying DST-M as well, but a diamond shape ◆ could present problem in such case. -- Sameboat - 同舟 (talk) 23:20, 14 August 2013 (UTC)

If it comes to the need for differentiating DST and INT, I'm fine with having square/circle icons. Some problems, however, lie with the regulation, and the naming in my opinion. Once we start using squares, it would start a chain of new users inventing new icons (diamonds, ovals, triangles etc.) with all sorts of different root names and prefixes, to represent whatever landmark/feature. As such I think we have to standardize the use of shapes & the naming of the icons. Just my concerns. -- NoNews! 11:50, 15 August 2013 (UTC)

Although Useddenim used different names for the new icons, the new icons will overwrite the existing DST/BST eventually and QST/RST will be deleted regardless of the conclusion of this proposal. -- Sameboat - 同舟 (talk) 12:59, 15 August 2013 (UTC)

If you want to change the shape of the DST and BST icons, I think you should make a formal proposal at Commons:WikiProject BSicon and get consensus from all concerned (particularly de:WP). Useddenim (talk) 13:50, 15 August 2013 (UTC)

No German user has joined the project, but I will invite Axpde to the discussion. -- Sameboat - 同舟 (talk) 14:17, 15 August 2013 (UTC)

The German project does not support the use of INT symbols. Therefore we have no objections to altering INT symbols, but expect the persistance of all original symbols including DST as embodied in our Index of Icons. --$traight-$hoota (talk) 16:06, 15 August 2013 (UTC)

So the original author of INT really is not a German user. I guess a compromising proposal would be thinning the black ring of INT, so then the wheelchair component within  (INTACC) can be slightly enlarged. -- Sameboat - 同舟 (talk) 16:40, 15 August 2013 (UTC)

(ec) Although I'm not German, I oppose overwriting DSTs with squares. As of now, all stations are circle, and that's what differentiates them from all other technical objects on the line. If you want to use QSTs, use them, but do not overwrite DSTs. YLSS (talk) 16:44, 15 August 2013 (UTC)

No opposition to that one. INT as settled above has 60px width, that is slightly more than 2px in standard diagrams. Would 25px => 1px border in diagrams suffice? That said, I'm not against concurrent thickening of DST a bit, e.g. up to 75px => 3px in diagrams. YLSS (talk) 16:49, 15 August 2013 (UTC)

On behalf on the original project, DST shouldn't be changed (now that it has been settled so well). I like the idea to thin the black ring of INT, maybe enlarge it even a bit, then the ACC symbol will fit even better in the middle. Regards a×p_de^Hello! 18:11, 15 August 2013 (UTC)

Proposal 2: thinner black ring of INT set

Type 2 Type 1 sameboat002 sameboat-INT / DST / DEO-INT sameboat002 sameboat005 sameboat-INT / sameboat-DST / DEO-INT3 sameboat005 QST / DST (org) / sameboat-DST

  (INT),   (vINT),   (INTm). Now the black ring is 25px wide in the original 500px-wide dimension, effectively 1px after down-scaled to 20px wide. -- Sameboat - 同舟 (talk) 01:18, 16 August 2013 (UTC)

That seems the way to go. The current one looks slightly blurred and is not crisp. Although, I would prefer it liem this:

 (DEO-INT) User:Deonyi 07:05, 16 August 2013 (UTC)

Paradoxes of optics: the second one looks smaller that the first one. Sameboat, if your version is distinguishable enough from DST for visually impaired, and if it would look OK in diagrams for others, then I have nothing to oppose. Of course, only if all the parties in support of it are ready to implement it to the last existing icon. BTW, would the distinguishability hold in case of  (*dINT') and  (dDST) ? YLSS (talk) 08:32, 16 August 2013 (UTC)

It IS smaller. This one is slightly larger and has a thicker border. (DEO-INT2)User:Deonyi 11:06, 16 August 2013 (UTC)

I can tell both INT of yours are thinner, just not enough to me. But even so I still want to thicken the ring of DST by changing the white ring radius from 90 (3.6px) to 75px (3px) similar to YLSS suggestion. P.S. I'm bit concerned by the path data of the circle components of your  (DEO-INTACC), but I suppose it is temporary and will be cleaned up eventually, right? -- Sameboat - 同舟 (talk) 12:36, 16 August 2013 (UTC)

A comparison of the various INTs and DSTs with colour blindness filters.

http://i.imgur.com/SKveBp2.pngUser:Deonyi 02:21, 17 August 2013 (UTC)

Radii comparison

C = A- (B/2)
D = A+ (B/2) = C+B

(A) Base radius	(B) Stroke-width	(C) Visible white circle radius	(D) Total radius	B:D ratio	C2:D2 ratio	Sample BSicon					Comments
INT
123.853	52.2936	97.7062	149.9998	~34.86%	~42.43%	INTACC					Old standard
120	60	90	150	2:5	36%	INT					Currently in use
125	37.5	106.25	143.75	6:23 ~ 26.09%	54.63%	DEO-INT3					Deonyi's proposal
131.25	37.5	112.5	150	1:4	56.25%	PETERWHY-INT					Peterwhy's proposal
137.5	25	125	150	1:6	69.44%	sameboat-INT	File:BSicon sameboat002.svg	File:BSicon sameboat002.svg			Sameboat's proposal
120	60	90	150	2:5	36%	QINT					Useddenim's alternate
DST
120	60	90	150	2:5	36%	DST					Currently in use
112.5	75	75	150	1:2	25%	sameboat-DST	File:BSicon sameboat005.svg	File:BSicon sameboat005.svg			Sameboat's proposal
120	60	90	150	2:5	36%	QST					Useddenim's suggestion

So something like this? (keep adding for new proposed standards)
Great deal of upcoming changes though ... NoNews! 15:45, 16 August 2013 (UTC)

What exactly IS base-radius? Also, I fixed my icon; it was supposed to be DEO-INT3, not DEO-INT. User:Deonyi 02:28, 17 August 2013 (UTC)

Base-radius is the length from the centre of the circle to the middle of the exterior stroke, practically the "r" value that is used in the codes (for DST and INT). It does not directly show the visible white circle size though, you'll have to convert the value using the formula C = A- (B/2) as mentioned above.

P.S. Useddenim, have you checked the size of the INTACC icon to fit in your QINT? NoNews! 03:25, 17 August 2013 (UTC)

Yes:  (QINTACC). Useddenim (talk) 15:06, 17 August 2013 (UTC)

Is this discussion still active? Added my version between Deonyi's and Sameboat's. I followed the old 150px station radius, with 37.5px black stroke, equivalent to 1.5px in maps and 1/4 of station radius. — Peterwhy 19:33, 20 August 2013 (UTC)

I wanted someone not participated in this "contest" to give the comment, but it turns out no one is interested... -- Sameboat - 同舟 (talk) 23:51, 20 August 2013 (UTC)

I really don't care if you choose to use my suggestion or not. You said that you wanted something “more distinguishable”. I think that the square is most visibly distinct from the circle, but if you want an opinion on the circles, I think Peterwhy’s is the most æsthetically pleasing. On the other hand, thickening the ring ( ) just makes it look excessively heavy. Useddenim (talk) 00:15, 21 August 2013 (UTC)

I'm OK with square INT, but the rim still needs to thin slightly because the ACC inside still looks ambiguously small. Deonyi's color blind sample proves that circular INT doesn't look much difference to circular DST (which DE users oppose to change) no matter how thin the rim is. -- Sameboat - 同舟 (talk) 01:20, 21 August 2013 (UTC)

(edit conflict)

I’m “interested” but I had nothing more to add to my 1st statement. To quiet your passive-agressive smugness, here’s some sanguine bluntness: The whole endeavour, to make the differences between and color-independent, is both futile and disruptive. There — not what you wanted to hear, but what I had to say. -- Tuválkin ✉ 00:24, 21 August 2013 (UTC)

I personally don't like the idea of using a square for a station, all because I don't see real world maps using squares (or triangles, or hexagons) for stations. So the square INT might be something difficult for readers to relate.

For aesthetic concern, I know it is difficult to quantify, but I tried to add two ratios above to give some reference. For reference, the INT ring from London Tube map (probably the origin of INT icons) has a stroke-to-station-radius of 1:3.

For Sameboat's version, I think 25px/1px stroke is too thin, and map may pose another kind of accessibility issue. — Peterwhy 06:42, 21 August 2013 (UTC)

DST 60 INT 60 DST 60 INT 37.5 DST 60 INT 25 DST 75 INT 25 DST 75 INT 37.5 DST 75 INT 60 DST 60 INT 25 DST 60 INT 37.5 DST 60 INT 60 DST 60 INT 25 DST 60 INT 37.5 DST 60 INT 60 DST 60 INT 25 DST 60 INT 37.5 DST 60 INT 60 DST 60 INT 25 DST 60 INT 37.5 DST 60 INT 60 DST 60 INT! 60

I guess we should better compare the proposals in greyscale, since that's closer to the way the icons will be perceived by colour blind (am I right, Sameboat?). It should also be noted that (AFAIU) the black ring of INT will still differ in brightness from other colours, so it won't be "DST black" vs. "INT black". As an aside, my old proposal to distinguish the latter pair was like that:  (DST black) vs.  (INT! black). YLSS (talk) 11:21, 21 August 2013 (UTC)

I guess the darkest line colours after black should be either set u  (uINT), set f  (fINT) or set violet  (INT violet), depending on definition of dark. I am not familiar with lightness, intensity or luma, so I cannot say which colour is the closest to black in greyscale. May expert in that create a colourblind version for comparison? — Peterwhy 13:38, 21 August 2013 (UTC)

This website provides suggestion of background-text color accessibility. Surprisingly black (#000) to sharp red/green/blue (#f00/0f0/00f) are not accessible to color blind reader. But I buy YLSS' extra white rim of INT without drastic change to the shape itself. -- Sameboat - 同舟 (talk) 14:32, 21 August 2013 (UTC)

(ec) Extended DST vs INT comparisons for the three chosen colour sets. To me, even the original DSTs and INTs are distinguishable, and I will wait for colourblind view to see if they are confusing. — Peterwhy 14:39, 21 August 2013 (UTC)

For red/green INT/DST, they're sufficiently distinguishable, but for the blue set this is not true because blue has the least brightness compared to red and green[1], that means the visual contrast between blue and black is inferior to red/green to black. I don't know the brightness setting of your monitor, but I do have a hard time to tell the difference between uINT and uDST. -- Sameboat - 同舟 (talk) 15:00, 21 August 2013 (UTC)

ACC

new	old

Strangely enough, there are no ACC icons with neat and clear code (at least, I was unable to find one). The current version of  (lACC) uploaded by Useddenim is more or less close; however, it also has no less than three digits after the point, and relies heavily on Bézier curves where circle arcs would do better. I have uploaded three new icons with code created anew by myself using only Notepad++ (managed to keep them below 1 KB, sans bloated title). These can be seen at the first column; the difference with their already existent counterparts to the right is negligible. So I propose that hereafter the following code should be used (corrections are of course welcome):

  <circle cx="250" cy="250" r="150" fill="#034EA2" />
  <g fill="white">
   <path d="M 199,294 A 57.4,57.4 0 1 0 293,235 L 296,210 A 79.1,79.1 0 1 1 187,319" />
   <circle cx="275" cy="150" r="22" />
  </g>
  <g stroke="white" stroke-linecap="round" fill="none">
   <path d="M 277,193 268,254.5 H 198 L 164,322" stroke-width="26" stroke-linejoin="round" />
   <path d="M 215,216 H 272" stroke-width="21" />
  </g>

For HST and INT, 2/3 size seems perfect (currently different icons use different scaling...):

  <nowiki><!-- for HST --></nowiki>
  <circle cx="250" cy="250" r="100" fill="#034EA2" />
  <g transform="matrix(0.667, 0, 0, 0.667, 83.3, 83.3)">
   <g fill="white">
  ...
  </g>
  
  <nowiki><!-- for INT --></nowiki>
  <circle cx="250" cy="250" r="120" stroke-width="60" stroke="black" fill="white" />
  <g transform="matrix(0.667, 0, 0, 0.667 83.3, 83.3)">
   <g fill="#034EA2">
  ...
  </g>

--YLSS (talk) 23:03, 11 April 2013 (UTC)

Useddenim has now managed to make things even simpler using stroke-linecap="round" and stroke-linejoin="round", as can be seen at  (lACC). I've updated the code above accordingly. YLSS (talk) 20:32, 25 June 2013 (UTC)

Just checked the new  (lINTACC) uploaded by Useddenim, which has radius 123.5 and stroke-width 53. We are sticking to these values (I believe this is only for the INTACC subset), right? NoNews! 04:34, 9 November 2013 (UTC)

Dunno, I've been uploading with radius="120" stroke-width="60", as discussed above, e.g.  (tINTACC). However, I'm ready to review that. And I would prefer radius="125" stroke-width="50", if so. YLSS (talk) 10:46, 9 November 2013 (UTC)

(FYI. I use radius="125" stroke-width="50" now. YLSS (talk) 12:48, 7 February 2014 (UTC))

I have updated most of the related  (INTACC) icons back to the radius / stroke-width of 125 / 50 and used the off-color  (exlINTACC) where necessary. The remaining unchanged ones are mainly interchanges  (INTACC-M).

I also played around a bit with red-hue  (INTA) and  (BHFA) just to see how they'd look like. The colour (#C33245, versus original #BE2D2C) is derived from the difference between the current ACC (#034EA2) and uBHF (#003399) colours. But, as with what User:Lost on Belmont mentioned below about the ACC symbol, they are purely experimental and there are no plans to expand them further for the time being. NoNews! 09:42, 5 February 2016 (UTC)

half-width INTACC

The old  (udINTACC) was irritating, so I used and tweaked the code above, now it looks like this:

 <path d="M 125,0 V 500" stroke="#003399" stroke-width="100" fill="none" />
  <circle cx="'''125'''" cy="250" r="'''104'''" stroke="black" stroke-width="'''42'''" fill="white" />
  <g transform="matrix('''0.54''', 0, 0, '''0.54, -8, 117''')">
    <g fill="#034EA2">
      <path d="M 199,294 A 57.4,57.4 0 1 0 293,235 L 296,210 A 79.1,79.1 0 1 1 187,319" />
      <circle cx="275" cy="150" r="22" />
    </g>
    <g stroke-linecap="round" stroke="#034EA2" fill="none">
      <path d="M 277,193 268,254.5 H 198 L 164,322" stroke-width="26" stroke-linejoin="round" />
      <path d="M 215,216 H 272" stroke-width="21" />
    </g>
  </g>

I use r="104" stroke-width="42" , such that the area ratio of the white inner circle versus the larger circle (83²/125² = 0.4409) is similar to the normal width  (INTACC) (100²/150² = 0.4444).

The overall size of the INTACC, however, doesn't coincide with  (udINT) and  (udDST), which use r="96" stroke-width="53" giving circle radii of 122.5.  (udBHF) uses the full radius value of 125. I'm not sure if there's a standard to narrow-width INT sizes, so I'm sticking to the given size (125) for now.

For the ACC symbol, I sized it to 54%, as 50% ( (udINTACC !)) looked somewhat too small in a 83px circle. This is tentative and can be adjusted accordingly if the radius of the circle changes.

Any comments? NoNews! 10:53, 5 February 2016 (UTC)

exACC

moved from User talk:Axpde/Archive 2#ACC off-use colour?

Hi Axpde, just asking, is it desirable to use an "off-colour" for the ACC symbol? This will produce the "off-state" exACC symbol and it can be used to create icons like "eACC", "ehACC". (Currently, all the ACC icons just use the same ACC symbol throughout.)
NoNews! 12:46, 26 June 2010 (UTC) (P.S. I've just changed my user name and signature.)

Interesting question. The ACC icons are not part of our German Bilderkatalog, I have no directive for such a colour. When I created the new set of suburban commuter service icons, I created a new light green colour for the erstwhile icons by shifting the RGB-palette in the same manner they did with dark and light red and blue colours ... Maybe you should consult the English wikipedia, too ... Regards axp_de^Hello! 13:49, 27 June 2010 (UTC)

---

moved from Talk:BSicon/New icons and icon requests/Archive 1#Pale ACC icons

For some reason, the ACC series of icon were not originally designed to include pale forms (i.e. the e- and ex- forms), as a result only the ex- series use the dark color on ex- line: this is the x- form! A fair amount of them may need to be adjusted, ranging from  (uexKACCe) to  (exCPICArr). Circeus (talk) 17:47, 7 September 2011 (UTC)

---

#034EA2	#6281C0	#6592C5	#72A5DF

I don't know whether this was ever discussed, but it doesn't feel right that we use the same colour both for regular accessible station and for unused ones. As yet I know of two attempts to break this custom:  (uxHSTACC) &  (ueHSTACC) by Imperator3733 (who used  #6281C0  = uex for exACC colour) and  (exHSTACC) by Newfraferz87 (who used  #72A5DF ). If we apply the standard method to ACC's  #034EA2 , we actually get  #6592C5 . So I uploaded  (uexHSTACC), as well as  (exlHSTACC) &  (exlACC). What do you think, is it worth overwriting existent icons with this colour? (That is, moving them to "xACC" titles and uploading new files instead of redirects at the "exACC" titles.) Cf. en:Template:WMATA Silver Line. YLSS (talk) 12:48, 7 February 2014 (UTC)

Before we go too far down this road (track?), how do we differentiate between a closed accessible station, and a station that is open but is not currently accessible? Useddenim (talk) 13:36, 8 February 2014 (UTC)

Literally, common sense, judging from the state of track. I remember this is the reason that Axp complaint about the existence of  (xBHF) which may or may not make sense. -- Sameboat - 同舟 (talk) 15:07, 8 February 2014 (UTC)

A compromising proposal would be changing the base color of the ACC accordingly to the usual track and station set so there is no concern of creating new set of color. -- Sameboat - 同舟 (talk) 15:11, 8 February 2014 (UTC)

How about  (uxACC), with the same background color for both circle & line? (I propose a black bar for  (xACC).) Useddenim (talk) 17:41, 8 February 2014 (UTC)

For such intricate wheelchair icon to have another big slash over it is difficult to read when downsized. -- Sameboat - 同舟 (talk) 07:02, 9 February 2014 (UTC)

I also consider that red bar extraneous. It's at odds with the whole BSicon philosophy, IMHO. And it looks as if it represents a ban on wheelchairs... That said, I don't ever use ACC icons by myself and voted against using them at ru.wp; so you can disregard my words ;).

However, I generally support the idea of differentiating between an existent station that is going to become (or was previously) accessible, and a non-existent station that will be opened as an accessible one (or was one before its closure). However, we would need a new method of naming such icons, because it would only be consistent to have   at xACC! Either we should use something like ACCx for what you represented by  (xACC) (in which case  (exHSTACC) will have to be renamed to exHSTACCx, if we do everything properly); or we resurrect Circeus's proposal:  (ACC) → BHFA. An existent station with non-existent facilities for disabled could then be called  (BHFxA).

And I like the idea of dropping that #034EA2 background for ACCs and simply marking a station with a wheelchair (like in Useddenim's design, but without the bar). YLSS (talk) 15:55, 9 February 2014 (UTC)

I like the idea for the A/xA suffix. But that still doesn’t really resolve how to show accessible status that is different from the station overall. Useddenim (talk) 16:53, 9 February 2014 (UTC)

I don't think that showing the accessibility status for a non-open station is helpful. If the station is not open, there are often locked gates, fences or other barriers preventing entry by all persons, not just those with accessibility needs. Even if there are no barriers, trains will not be calling and so the station's owners will not be under an obligation to provide accessibility for intending passengers. There are thus three cases: (i) station open and accessible; (ii) station open but not accessible; (iii) station not open. --Redrose64 (talk; at English Wikipedia) 23:48, 9 February 2014 (UTC)

Totally agree. If the editor still wants xACC/xBHFA, s/he should look somewhere else rather than BSicon. -- Sameboat - 同舟 (talk) 00:53, 10 February 2014 (UTC)

You know, purely theoretically, I agree with you. However, you can see by the usage of  (uexACC) and others that people consider these icons useful, so I think we should not proscribe them. Going around and replacing  (uexACC) with  (uexBHF) would be returning to the philosophy of "this thing is impossible, so we should delete it". YLSS (talk) 07:45, 10 February 2014 (UTC)

I'm not against exACC (closed accessible station). The problem is that I don't want to invent new rules to differentiate the availability of ACC over both BHF and exBHF (e.g. BHFxA, existing station without disabled-accessibility). If the ACC is not available to the station, the usual BHF icon suffices perfectly. -- Sameboat - 同舟 (talk) 09:22, 10 February 2014 (UTC)

I'm with sameboat here. For the purpose of diagrams, it seems inappropriate to distinguish between a current station that was never disabled-accessible and one that once was. Circeus (talk) 20:20, 20 February 2014 (UTC)

I'm in favor of replacing the #034EA2 background with the standard colors, and having four cases for the accessibility/operating status: 1) open and accessible, 2) open and not accessible, 3) closed/planned and accessible, and 4) closed/planned and not accessible. If a station is still open but it is not currently accessible, then it should fall under case 2. I've made two prototype icons:  (KCPICAal__beta) and  (uKCPICAal__beta). -- Imperator3733 (talk) 02:46, 2 April 2015 (UTC)

That's a question for Britons. These ACCs derive from London tube map (AFAIK), so it's mainly up to them whether they're ready for such a change or not. Of course, it would simplify things a lot... YLSS (talk) 11:26, 2 April 2015 (UTC)

I would have to object to this change. The blue background isn't arbitrary. Blue is used for accessible icons because of the International Symbol of Access. Lost on  Belmont ^3200N_1000W  (talk) 21:54, 2 April 2015 (UTC)

Yes, see en:WT:UKRAIL#Route diagrams and accessibility (wheelchair) symbol; also, returning to my point of 23:48, 9 February 2014, why is it necessary to show the accessibility "status" for stations that are not open? --Redrose64 (talk; at English Wikipedia) 21:24, 13 April 2015 (UTC)