Template talk:Routemap

Template-protected edit request on 28 August 2024

Special:Diff/1242768726/1242768909

Fixes [1]. Andumé (talk) 17:00, 28 August 2024 (UTC)

@I Am Andumé I think more work needs to be done before we can switch the background to black. Looking at Template:Routemap/testcases#In_infobox in dark mode, unliked text is almost unreadable (such as all the text in the first box and the word "to" or "Tai Wai Depot (Ma On Shan Line)" in the second box). The gradient as shown at Victoria Harbor would also need to be reworked so it fades to transparent instead of white. --Ahecht (TALK
PAGE) 18:16, 17 September 2024 (UTC)

 Not done for now: See #Dark mode problems below. --Ahecht (TALK
PAGE) 18:26, 17 September 2024 (UTC)

Symbols

Where can I find which code produces which symbols? Criticalthinker (talk) 04:10, 30 August 2024 (UTC)

@Criticalthinker: As noted in the documentation, for a tabulated list of many of the pictograms available for railway routemaps, see commons:BSicon/Catalogue. --Redrose64 🌹 (talk) 07:49, 30 August 2024 (UTC)

I am thoroughly confused by Template:South Shore Line. What is "BScvt"? I'm also trying to show a grade crossing with the Michigan Line in between Willard Avenue and 11th Street, but can't figure out how to do it for the life of me. Criticalthinker (talk) 11:08, 30 August 2024 (UTC)

"BScvt" is {{BScvt}}. The two braces on either side mean that it is a template. If you edit the template and then fold down "Pages transcluded onto the current version of this page", you will see the templates and modules that are used on the page. As for the grade crossing, asking on the template's talk page as you did will probably work. – Jonesey95 (talk) 13:26, 30 August 2024 (UTC)

"fold down "Pages transcluded onto the current version of this page" Excuse me, what? Edit which template? I do not see this option anywhere. Criticalthinker (talk) 00:02, 31 August 2024 (UTC)

When you are editing Template:South Shore Line, look directly below the "Publish changes" button for "Pages transcluded onto the current version of this page". You should see a little gray triangle to the left of that text. If you click it once, it will reveal a list of the templates and modules that are used on that page. One of them is Template:BScvt. You can click on that template's name to see an explanation of what that template is and how it can be used. – Jonesey95 (talk) 00:18, 31 August 2024 (UTC)

Dark mode problems

@Jonesey95, Jdlrobson, and TheDJ: Thanks for your recent edits to Template:Routemap/styles.css addressing dark mode problems. Unfortunately, there are still some issues, and I'm wondering if the solution of forcing a white background is the right one. To be clear what I'm seeing, I edit in dark mode, and when I look at Greenbush Line, the route map in the infobox has a white background, but some of the text (like "lines via") is unreadable because it is still using the dark mode text color (which is light grey). Looking at Template:Greenbush Line, I see a black background, but some of the text (namely the distances in mi and km) is unreadable because it's being forced to black by the .RMsplit block.

Given the dark mode version with black background is mostly OK, I'm wondering if we can't do the thing most friendly to dark mode users, and start letting railroad diagrams on articles display with a black background? We should be able to fix the text issues. Are there any issues with icons or anything that would cause problems if we go in that direction? I'm not even sure where the CSS is that is forcing the white background, so I can't test changing that. Thanks! -- Beland (talk) 18:50, 9 September 2024 (UTC)

I reached the limit of my technical skill in making a few small changes. I tried a few others, but they didn't work for me. I will defer to others. – Jonesey95 (talk) 00:43, 10 September 2024 (UTC)

I cant look at this until oct 3rd as my userpage mentions —TheDJ (talk • contribs) 14:20, 12 September 2024 (UTC)

In addition to unlinked text, icons such as woulnd't work on a black background, and the gradient as seen at Victoria Harbour in Template:Routemap/testcases#In_infobox would need to fade to transparent instead of fading to white. The hard blue arrows in that diagram aren't particularly readable against a black background either. --Ahecht (TALK
PAGE) 18:29, 17 September 2024 (UTC)

can be fixed by adding class skin-invert, og class skin-invert-image. This will make the icon white instead of black. If you check this site in dark mode you will see the icon in white. Tholme (talk) 18:56, 17 December 2024 (UTC)

Where would that be added? The line which (I think) generates that icon looks like gibberish: "\eABZg+l\exKBHFeq\lDAMPF~~Hong Kong Railway Museum". -- Beland (talk) 02:32, 18 December 2024 (UTC)

In that line, there are three icons separated by backslashes - the icons are  (eABZg+l) (exKBHFeq) (lDAMPF). They look like gibberish because they are abbreviations of longer terms, often German (because the whole RDT system was devised on German Wikipedia). Each icon code has a stem (three or more capital letters) which indicates the main feature, an optional suffix (lowercase) which normally indicates the orientation; and an optional prefix (lowercase) which normally indicates the colour scheme.

• ABZ icons are junctions (Abzweigstelle); the g+l suffix shows that the branch goes from bottom to right; and the e prefix shows that the branch is pink, the straight line being the default red.
• KBHF icons are terminal stations (Kopfbahnhof); the eq suffix shows that the line is horizontally and on the left; the ex prefix shows that the whole icon is pink.
• DAMPF icons depict steam locomotives (Dampflokomotive) and the l prefix simply means "legend" - it's a standalone icon without any railway lines.

It is impractical to add classes for specific icons, not least because the code to do so does not exist in the routemap module. Whilst it would not be impossible to add such code, we would need to consider the fact that icons are designed to be overlaid (two or more icons occupying the same cell) - what would we do with a cell containing an icon that ought to be inverted for dark mode, and also one not intended to be inverted? The only feasible thing to do is to invert every icon in the diagram, or invert none of them. It follows from that that a class would be added to the diagram as a whole, and not on a cell-by-cell basis. --Redrose64 🌹 (talk) 18:36, 19 December 2024 (UTC)

Sounds like this system would benefit from having the abbreviations translated into English.

Simply being in the same "td" cell doesn't mean that images have to have the same classes; each "img" tag (or [File:] in wikitext) can have its own class memberships. It looks like Module:Routemap is what is generating this. Is there anything that distinguishes the black icons from other icons (like the lines and dots) that the code could use to know when to add skin-invert-image? The lines and dots should not be inverted, because that generally results in sickening hues and colors wouldn't match what's used locally if they are chosen that way. Alternative solutions are to change the color of these icons to something that shows up on both backgrounds, or to force a specific background color for both modes. As Ahecht points out, there are other diagram elements that are also not working well without a white background. -- Beland (talk) 20:58, 19 December 2024 (UTC)

@Beland: Sounds like this system would benefit from having the abbreviations translated into English. - I tried to explain this three months ago, at Wikipedia talk:WikiProject Trains/Archive: 2024#Line colors.

Is there anything that distinguishes the black icons from other icons - no. They are all SVG files with a transparent background. The SVG files are held on Commons. The whole RDT system is designed to suit a white (or very pale) background. --Redrose64 🌹 (talk) 22:41, 21 December 2024 (UTC)

Yes, and I replied to your explanation in that thread that this is very user-unfriendly to anyone who doesn't speak German, which is the vast majority of people. I think it would be worthwhile to replace the system with something more flexible and more easily localized (like the YAML markup I suggested in that thread), but another option is to make the existing system easier to use. If we make a map between German and English abbreviations, a bot (which would be less work to code than a full replacement) could create redirects from the English versions to the existing icons, and switch all the existing templates from German to English, if there is consensus to do so.

It sounds like the easiest dark mode fix would be to force a white background, then, even though this ends up being a jarringly bright spot on the page. Otherwise I think there'd need to be a list of which icons need to be inverted in the module or somewhere accessible to it. (Which is not that much harder.) -- Beland (talk) 00:20, 22 December 2024 (UTC)

Curiously, the appearance in dark mode varies whether the routemap template is inline or not. I'm looking into what causes that. Mackensen (talk) 23:14, 21 December 2024 (UTC)

I've tweaked Template:Routemap/styles.css so that the contrast filter is applied both when the template is free-standing (which was done in September) and when it's inline in an infobox (such as on Greenbush Line). Mackensen (talk) 23:37, 21 December 2024 (UTC)

Hurray, thanks for that! -- Beland (talk) 01:35, 22 December 2024 (UTC)

You're welcome. Does this address dark mode sufficiently, or are there specific outstanding issues? Mackensen (talk) 15:22, 22 December 2024 (UTC)

As Ahecht mentioned above, there are visible problems in test cases like Template:Routemap/testcases#In_infobox. For example, there are lots of black icons like , a few dark blue icons which are hard to make out, the Victoria Harbor gradient which fades to white instead of transparent, and low-contrast black and dark blue lines and arrows. -- Beland (talk) 22:40, 22 December 2024 (UTC)

@Beland as a test, I've replaced the contrast function with invert, with the sensitivity of 100%. This has the effect of color flipping every image. Say goodbye to blue-on-black, but it ought to resolve most contrast issues. Mackensen (talk) 23:24, 22 December 2024 (UTC)

Water bodies are orange. --Redrose64 🌹 (talk) 00:00, 23 December 2024 (UTC)

Yeah. I use f.lux on my laptop when I'm in a low-light situation and see some odd outcomes. The default blue for water (#007CC3) does actually contrast well with white and black. CSS selectors can be used to identify icons based on span titles so in theory water icons could be exempted; in practice I'm not sure how performant that would be and I doubt it would scale. The larger question is whether we're relying on color qua color to convey information. If we are we probably shouldn't be. Mackensen (talk) 00:23, 23 December 2024 (UTC)

When viewing in dark mode, this has broken the color correspondences on articles like MAX Light Rail. For example, the MAX Blue Line went from being blue to orange, which is confusing because there is a MAX Orange Line which is now light blue, and a MAX Yellow Line which is now dark blue. -- Beland (talk) 02:02, 23 December 2024 (UTC)

I've reverted; you can always preview with the old change in place for testing. I don't know if proper support for dark mode and color correspondence are both achievable goals. For one thing, in light (normal) mode, the yellow isn't sufficiently contrasted with the background. This is less of an issue in contrast dark mode, although the colors don't really correspond to their actual map colors.

I've never been a huge fan of coloring individual lines; it adds *a lot* of overhead and you have to worry about the accessibility of every color. Mackensen (talk) 04:44, 23 December 2024 (UTC)

It shouldn't be hard to assign a dark yellow in light mode and a light yellow in dark mode, and so on. Following the single source of truth principle, color for a specific line should be defined in only one place. Normally I'd expect that to be in a CSS class which could have different attributes applied for different modes, though here the base colors are hard-coded and picked by specifying the right SVG file, which violates the principle and makes things a bit harder to reengineer. (That is also why it takes more overhead than necessary to encode the color of a line, since it has to be done separately for each tiny segment.) It might be possible to apply a satisfactory CSS filter to change the dark/light balance of the existing colors based on which mode the reader is using without affecting the hue. If not, then individual colors would need to be manually mapped to the right shades of yellow, etc., either in the module or by having the calling template pass two color parameters. -- Beland (talk) 08:40, 23 December 2024 (UTC)

-collapsible formatting

Is there a way to have a -collapsible section default to expanded? Useddenim (talk) 14:39, 11 September 2024 (UTC)

It looks like -startCollapsible-nil works. See my sandbox for examples. – Jonesey95 (talk) 17:05, 11 September 2024 (UTC)

Thank you! Useddenim (talk) 13:47, 12 September 2024 (UTC)

Routemaps accessibility

Currently, route maps are not accessible to blind people. However, it would likely be a complex task to make them accessible. After typing this, I'm going to add {{accessibility dispute}} to the Routemap template, and hopefully we will get some discussion going on the best ways, or at least feasible ways, to improve the situation.

Issues:

• Icons in the route map do not have alternative text. For example, the BHF icon for a major station, <img alt="" src="//upload.wikimedia.org/wikipedia/commons/thumb/7/76/BSicon_BHF.svg/20px-BSicon_BHF.svg.png" decoding="async" width="20" height="20" class="mw-file-element" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/7/76/BSicon_BHF.svg/30px-BSicon_BHF.svg.png 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/7/76/BSicon_BHF.svg/40px-BSicon_BHF.svg.png 2x" data-file-width="500" data-file-height="500">, is missing alternative text reading "major station."
• Hovering the icon shows "BHF." While this may be helpful to editors trying to copy other's work, it is confusing to readers. It makes sense as a hover when editing a page but not when a random site visitor is visiting. When view a page in Read mode, it would be better for the hover to show "Major station."
• However, hover is either difficult or impossible to do on a touch screen. It's also tedious to have to do it for each icon.
• Also, for route maps with two or three columns of route line and text on both sides, it can be difficult to associate the alt text with the visible text.
• Further, sometimes the lines are actually parallel and sometimes they are going in different directions, only forced to be side by side by the routemap construction method.
• There may be icons with less than a 3:1 contrast with the background.

Possible solutions:

• Add alternative text to the icons.
• Show the tooltips in plain English in read mode, code name in edit mode.
• Add an automatically-generated collapsible section at the bottom of the map which reveals a text-only version. We still need to figure out how to handle parallel maps so they will make sense to someone using a screen reader.
• Add the ability to add a collapseable section at the bottom containing an editor-crafted equivalent table.
• Examine the icon catalog and improve contrast on problematic icons.

Thisisnotatest (talk) 04:25, 25 October 2024 (UTC)

I would suggest replacing these diagrams with conventional tables like we have at Interstate 95 in Massachusetts#Exit list. This allows more room for notes and explanations, and the use of words instead of icons makes everything easier to interpret for anyone who doesn't already know what all the symbols mean (which I expect would be most readers). This would also solve the problem of these diagrams being too hard for most editors to construct and maintain, especially those who don't speak German. The current system also isn't very flexible; just changing the colors of the lines to match what's used locally seems to require a major re-engineering. The tables aren't as beautiful, but I would value accessibility and comprehensibility over aesthetics. -- Beland (talk) 21:03, 19 December 2024 (UTC)

I'm afraid I have to say that the tables aren't as beautiful is the understatement of the year to date. "Pig ugly" would be an injustice to pigs. 𝕁𝕄𝔽 (talk) 16:31, 20 December 2024 (UTC)

I agree that RDTs are inaccessible as implemented. I doubt there would be consensus for dropping RDTs altogether; Beland, you're in a minority of one there. We're probably better off thinking of ways to represent the information contained therein in an accessible way. Tables are one possibility, though tables have their own accessibility challenges. A textual description is another and this was discussed at Template talk:Sepulveda Transit Corridor#Accessibility. Mackensen (talk) 17:55, 20 December 2024 (UTC)

I would at least hold an RFC before concluding only one person supports a given solution. -- Beland (talk) 23:20, 20 December 2024 (UTC)

Thisisnotatest seems to have concluded in that discussion that tables would be better than prose descriptions of diagrams. I'm fine with starting out by adding accessible tables to all articles that have route diagrams. Then we can see if editors are able to maintain both formats or if one becomes neglected. Route diagrams are already showing signs of maintenance breakdown, as maintainers haven't been able to fix the dark mode icons nor change the color of lines to match local conventions. -- Beland (talk) 23:34, 20 December 2024 (UTC)

@Beland I'm going to refer you back to Wikipedia talk:WikiProject Trains/Archive: 2024#Line colors, where a host of editors tried to work with you. Nothing that was suggested was good enough for you. I'm disappointed that you're still taking a dismissive, high-handed attitude here, and I wonder if you'd consider a more constructive approach. I come back to what I said then: All this for the Greenbush Line?

With dark mode and line coloration you're proposing massive changes based on nothing more, at the moment, than personal preference. Accessibility is a different question, but again, no one's held an RfC to determine an appropriate approach. As you say, I would at least hold an RFC before concluding only one person supports a given solution. Mackensen (talk) 01:18, 21 December 2024 (UTC)

I already replied to "All this for the Greenbush Line?" on the other thread, but to give a clearer motivation here: no, it's not just the Greenbush Line where the MBTA Red Line shows up or where a line is named after a color. All the MBTA rapid transit lines are named after colors, and lots of metro systems around the world (though perhaps not in Germany) do the same thing (see e.g. Red Line#Public transit). Their diagrams would be considerably easier to understand if the color names didn't clash with the assigned colors. There are lots of other systems which consistently use colors for certain lines without those being the line names. For example, the many lines of the NYC subway have official colors, even though they are named after letters and numbers and somehow also shapes (see New York City Subway#Nomenclature). The articles I spot-checked do not carry these colors into route diagrams. I'd say there's an argument to be made that doing so would be helpful in orienting readers and making correspondences between diagrams, maps, and prose more obvious. There's an opposing argument to be made that on systems where there are weak or no official associations with specific colors, especially if there's a small number of lines, that color be used to differentiate heavy vs. light rail, etc. Given the smaller number of options, rail type could also be differentiated by thickness or outline style or something else. I don't have much of an opinion about cases where there are no official colors, but given that we currently have articles doing both, it seems like our diagram system should be able to support either choice.

I'm not sure what you mean by "personal preference". Not putting black icons on dark grey background is a requirement of accessibility, and not coloring blue something called the "Red Line" seems like a basic principle of good visual design. Perhaps you are referring to my personal preference for a different technical solution? Sorry if I was undiplomatically blunt in my assessment of the existing system which people have put a lot of work into, but the main arguments for keeping it seem to be "it would be a lot of work to change" and "we'd have to learn a new system" rather than having good attributes compared to alternatives, like "novice editors find it easy to understand and it is flexible and accessible". The editors on the other thread were certainly helpful in explaining the existing syntax, but they also pointed out not all the colors have all the needed icons, and when lines cross there is an explosion of combinations needed. I could push through and repair the existing system by adding missing color icons in addition to making a lot of intricate changes to specific diagrams, but I feel like this would be a waste of time compared to working on an improved replacement. I don't blame anyone else for not implementing a more intuitive color alignment in the existing system, either, since it's hard to figure out and would take a lot of work. I've put this on my "should work on this but it's a big headache so not right now" todo list, which means I need to wrap up work on some other big projects before I start coding.

The YAML markup I proposed in the other thread could also solve the accessibility problem pretty easily. Some screen readers - those optimized for computer programmers - could actually just read the YAML as-is and it would be pretty intuitive. But it would be easy (certainly easier than building the visual representation) to transform the YAML markup into a prose paragraph or bulleted list or table or whatever we want that would be read properly by pretty much every TTS system.

I'm certainly open to other suggestions, and no one's under any obligation to help. I hope that in the meantime we can solve in the existing system the dark mode accessibility problems and also the problems of text-text and text-icon collision and even overlap (which depending on your browser you can probably see at e.g. Template:Kaohsiung Metro Red line map and Template:Red Line (Doha Metro)). But I also accept that the persistence of these problems might just be a sign the system has become too difficult to maintain. -- Beland (talk) 22:26, 21 December 2024 (UTC)

By personal preference, I mean your insistence on the importance of the line color in the diagram matching the color on routemaps. Many routemaps describe physical infrastructure, not services, so there wouldn't even be a matching color to use. Aside: the red may have been chosen because it's close to the red found in the excellent Schweers + Wall railway atlases for Central and Western Europe.

Not getting much action on a change that is important to you and no one else, you start talking about implementing an entirely new set of templates to deliver this functionality. Meanwhile, you've also suggested that these templates should be abolished entirely and replaced with tables. With respect, you're rushing around like the proverbial bull in the china shop, and at no point have you stopped to ask current editors what challenges they're dealing with and what improvements they might like to see. The BSmap to Routemap migration, concluded in the last year, featured a significant change in syntax that alienated at least one major contributor.

Accessibility is important. I agree that the current templates are not accessible. I don't think it's helpful to repeatedly assail the existing implementation because no one's delivering the features that you want. Mackensen (talk) 23:03, 21 December 2024 (UTC)

Matching diagram colors to the colors lines are named after is something other editors have done in existing articles. I remember seeing it on one MBTA article but not others, and today I ran across it on MAX Light Rail. When there's no color name or no official color at all to match to, yeah, those are different situations.

I've felt the railroad diagram syntax is user-unfriendly for a long time before I noticed the line color-name mismatch, so I've avoided touching those diagrams and left it up to people who are more excited about railroads than I am. It's become a more pressing issue lately because of the problems I've come across and have tried to help fix, and it has given me a closer look at just how the current system does and doesn't work. I'm a programmer, and I usually find when fixing bugs or adding new features to a codebase becomes "swampy" - harder than it really needs to be or involving a mismatch between natural ideas and code - it's a good time to propose a refactor. Sometimes proceeding with the old code base is advantageous because dealing with it is less work than replacing it, sometimes the benefits of the refactor are widely desired. I've suggested two different potential replacements; if you don't agree either would be better than the current system, that's fine, and I'm happy to read your comments about why.

Here, we have the prospect of a potentially very long-lived codebase that is constantly being used and to which new users are constantly arriving. All of the existing editors who work on railroad diagrams will eventually leave the project, and need to be replaced as Wikipedia carries on for decades or centuries. If the codebase isn't sufficiently easy to learn, the number of people who maintain it will drop low enough that it will start to (or in this case, continue to be) glitchy, and in the worst case just be abandoned because no one is willing to deal with it. If that's going to happen eventually, replacing it sooner rather than later would let us enjoy the benefits of the new system (higher editor productivity, more participating editors, higher output quality) for a longer period. There are certainly things that could be done to make the existing more user-friendly and longer-lived short of a complete replacement, like translating the German abbreviations to English.

I expect the editors most likely to benefit from an easy-to-use system currently do not edit railroad diagrams because like me they have been turned off by the opaque syntax, and the editors who have learned it are somewhat non-representative in that respect. For sure that does not mean the current community has nothing useful to say, or that these editors wouldn't have enthusiastically learned whatever system was available when they started out. I expect existing editors to chime in on what they do and don't like about the existing system when someone starts proposing changes or replacement, and I expect the issues already brought up on talk pages to be somewhat representative of the problems editors are having with the current system, but if you want an explicit invitation, here it is: for railroad diagrams, what challenges are you dealing with and what improvements would you like to see? -- Beland (talk) 01:34, 22 December 2024 (UTC)

This paper on accessible circuit diagrams suggests some ways forward.. Mackensen (talk) 01:29, 21 December 2024 (UTC)

References

Add city border between stops?

Line 15
Keilaniemi Otaranta Aalto-yliopisto Maari Lahdenpohja Laajalahti Linnoitustie Alberganesplanadi Leppävaara station Perkkaa Vermo Ravitie Talin siirt.puutarha Takomotie Kutomotie Vihdintie Huopalahti station Ilkantie Hämeenlinnanväylä Pirkkola Pirjontie Maunula Kustaankartano Teininpuisto Oulunkylän keskusta Oulunkylä station Veräjämäki Viikinmäki Viikin tiedepuisto Latokartano Karhukallio Kauppamyllyntie Roihupelto Itäkeskus

Is it possible to add some sort of symbol for a city border between two stops? Attached here is a copy-paste of the line 15 in the article Trams in Helsinki. I'd like to add a city border between the stops "Ravitie" and "Talin siirt.puutarha". Is this possible? JIP | Talk 15:03, 27 October 2024 (UTC)

The dark arts of {{routemap}} are a mystery to me but what you want does seem possible, see {{Oxford area RDT}}. Maybe you can raid it? --𝕁𝕄𝔽 (talk) 15:26, 27 October 2024 (UTC)

Template:Oxford area RDT (which is one of mine) draws the boundary using icons selected from those in c:Category:BSicon/hub, overlaid on regular icons for stations, junctions, etc. --Redrose64 🌹 (talk) 23:01, 27 October 2024 (UTC)

I've updated the template to show one possible technique for doing this. Mackensen (talk) 15:28, 27 October 2024 (UTC)

CSS to visualize routemap alignment

I decided to play with routemaps again on my local wiki for worldbuilding, but found it annoying to constantly have to sort out alignment issues, made even slower by how long preview takes and all that other stuff.

So I made some CSS that makes the routemap grid visible instead of having it be invisible.

.RMir div {
    border: 1px solid black;
    margin: -0.75px;
}

I would probably recommend using something like the browser extension Stylish for this so you can turn it on and off with a checkbox, though I might be able to get the same thing done with a gadget, I don't know. Is there already something similar to this or anything else that could make the quality of life higher when making routemaps? A diehard editor (talk | edits) 21:41, 16 November 2024 (UTC)