Wikipedia talk:WikiProject Trains

The Trains WikiProject
General information
Main project page	(WP:TWP)	talk
Portal	(P:Trains)	talk
Project navigation bar		talk
Project participants		talk
Project banner (doc)	{{TWP}}	talk
Project category		talk
Manual of style	(WP:TWP/MOS)	talk
Welcome message		talk
Departments
Assessments	(WP:TWP/A)	talk
Peer review	(WP:TWP/PR)	talk
To do list		talk
Daily new article search	search criteria	talk
Task forces
Article maintenance		talk
Assessment backlog elim. drive		talk
By country series		talk
Categories		talk
Images		talk
Locomotives		talk
Maps		talk
Rail transport in Germany		talk
Monorails		talk
Operations		talk
Passenger trains		talk
Portal		talk
Rail transport modelling		talk
Timelines		talk

Requested move at Talk:Midland Mainline#Requested move 9 August 2024

There is a requested move discussion at Talk:Midland Mainline#Requested move 9 August 2024 that may be of interest to members of this WikiProject. JuniperChill (talk) 19:29, 9 August 2024 (UTC)

Train Stop Priority

Hi all, I am currently looking into an extension of the Altamont corridor express and Amtrak San Joaquins as part of a rail agreement. I wanted to know, at a point where both trains have service, do I put the Altamont Corridor as the template style for the page here on wikipedia, or do I use the Amtrak template style? Cloudsarepretty (talk) 16:21, 10 August 2024 (UTC)

Who owns the station? Trainsandotherthings (talk) 18:01, 10 August 2024 (UTC)

There's no hard-and-fast rule. Generally it comes down to whatever the most visible presence at the station is: whether one style of signage is used, who owns the station, whether one system runs by far the most trains, etc. It's also fine to omit the style parameter entirely. Pi.1415926535 (talk) 19:48, 10 August 2024 (UTC)

Rewrite of JGR Class 150 from ja:国鉄150形蒸気機関車 on Japanese Wikipedia

(I understand this is better suited to Wikipedia:WikiProject Trains in Japan, where I have also posted this, but that project has recently been marked as Inactive, and I'm not sure that I will find anyone to help there.)

I have just finished rewriting the locomotive article JGR Class 150 almost completely, basing the rewrite on a translation of the Japanese version ja:国鉄150形蒸気機関車, including its list of sources cited. However, I have made many further edits for style and content, including rearranging some portions of text, and I also omitted a few parts of the Japanese version (mostly concerning appearances in modern media) as probably not wanted on the English Wikipedia.

I am still pretty sure about the basic correctness of the results, but I really want people to look this over, particularly people knowledgeable of Japanese railways and people fluent in both Japanese and English. My Japanese ability is, in my own judgment, non-existent; while I have learned some features of the language on my own, and I do know bits of vocabulary, I've never been anywhere near Japan and I'm pretty sure that I couldn't so much as read a road sign or ask a cop for help on my own. I'm utterly dependant on machine tools like Google Translate (carefully applied and checked — I'm well aware that it can't be simply trusted as is!), the "10ten" dictionary-lookup browser plugin (an invaluable aid), and Google Lens (for OCR-reading graphical Japanese text) to do something like this.

Unfortunately, the original Japanese article does not have inline citations of its sources, and none of those sources are online anyway (they're rather old and Japanese-only), so I haven't been able to check them directly. Colin Douglas Howell (talk) 08:22, 15 August 2024 (UTC)

@Colin Douglas Howell, does this article still need checking? ABG (Talk/Report any mistakes here) 02:18, 8 September 2024 (UTC)

Yes, please! I haven't done anything new with it since I posted that message, but it doesn't look like anyone else has really looked at it either. Colin Douglas Howell (talk) 01:04, 9 September 2024 (UTC)

@AlphaBetaGamma Sorry, when I wrote that reply, I forgot to ping you on it, so I'm doing that now. Colin Douglas Howell (talk) 02:24, 10 September 2024 (UTC)

• Weird thing to point out, but the ill seems a bit odd for me. The page leads to a page in jawiki describing events leading up to the first railway in Japan, so the title is probably appropriate when considering that, but another thing is that the jawiki article seems to be already translated in History of rail transport in Japan. Therefore, I've retargeted both links to that article instead. Will complete this in the next 24 hours if it goes smoothly.ABG (Talk/Report any mistakes here) 02:38, 10 September 2024 (UTC)

New source needed for BART annual ridership and List of United States rapid transit systems page

The source for the 2023 BART annual ridership and the entire source for List of United States rapid transit systems now leads to a 404. Needs a new source. I will try to go on Wayback machine, but please help me find a current source. Maybe from BART's own website? Alexysun (talk) 17:20, 29 August 2024 (UTC)

Line colors

Does anyone know how to change the line colors on the diagram maps? Template:Greenbush Line is very confusing to read, because the MBTA Red Line is shown in blue, and the commuter rail line is shown in red. (The normal system map color for MBTA Commuter Rail is a dark purple.) -- Beland (talk) 05:31, 5 September 2024 (UTC)

The convention for RDTs is that red is for heavy rail and blue is for light rail. It is possible to use other colours, but there needs to be a consensus established to change the diagram first. Mjroots (talk) 07:25, 5 September 2024 (UTC)

Where would be a good place to discuss the question and move toward consensus? I'm unsure if you mean there should be a consensus for this specific article, for all MBTA lines, or for systems that color-name or color-code their lines in general. -- Beland (talk) 17:27, 5 September 2024 (UTC)

Well, what about Wikipedia talk:WikiProject Greater Boston Public Transit? --Redrose64 🌹 (talk) 18:59, 5 September 2024 (UTC)

That project is marked as semi-active and it looks like only one human has posted there in the past 7 years or so. I've posted a link to this thread there anyway. How would we go about changing this for MBTA lines, assuming no one objects? -- Beland (talk) 06:02, 6 September 2024 (UTC)

@Beland: I don't oppose such a change, but I'm not optimistic about it being worth the effort. If there is a consensus to change, then all the icons would need to be swapped into the desired color palette. If any of the correct color icons don't exist, then those would need to be uploaded (and any future modifications to the RDTs may require that as well.) It would only make sense to do if all of the relevant templates in Category:Massachusetts Bay Transportation Authority line templates were converted - having a single RDT with a different scheme would not make sense. My off-the-cuff guess would be somewhere in the 40-80 hour range for a moderately skilled editor to do it all. Pi.1415926535 (talk) 03:50, 8 September 2024 (UTC)

@Beland: These are all of the different icons used in Template:Greenbush Line, including Template:MBTA South Station Quincy rail approach which forms the upper two-thirds of the diagram. They are divided into groups according to whether you can use them unchanged, whether you need to change some of the coloured portions, or all of them.

• Spacers (no need for change)

   (c)  (d)  (o)

• Icons where none of the colours may be changed:

   (lACC)  (lhdSTRae+L)  (lv-ACC)  (lvINTACC)  (POINTER4)

• Red set, where part of the icon should not be changed:

   (d-KRZ2+4u)  (HSTACC)  (KACCxe)  (KINTACCa)

• Blue set, where part of the icon should not be changed:

   (uACC)  (udACC)  (utdACC)  (utINT2+4)

• Mixed set, where part of the icon should not be changed:

   (mvÜWBr)

• Red set, where all of the colours may be changed:

   (ABZg+l)  (ABZgr)  (ABZgr+xr)  (cSTRq)  (CONTfq)  (CONTgq)  (dCONTfq)  (dCONTgq)  (dSHI3+l)  (dSTR)  (dSTR~R)  (dYRDa)  (exCONTf@F)  (exSTR+r)  (SHI1+l)  (SHI3gr)  (STR~L)  (STR~R)  (v-SHI2r)  (v-STR)  (v-STRr)

• Blue set, where all of the colours may be changed:

   (uCONT3+g)  (udCONTgq)  (udSHI2g+l)  (udSTR+4)  (udSTRc1)  (udSTRc3)  (udYRDe)  (uSTR)  (uSTRr)  (utCONT2)  (utdSTR)  (utdSTR3+1-)  (utSTR+4)  (utSTRc1)  (utSTRc2)  (utSTRc3)  (utSTRc4)  (utv-STR3)  (uv-SHI2r)  (uvABZg2-)

• Mixed set, where all of the colours may be changed:

   (mvSTR)  (umtdKRZ)  (umvSTR)

For all of the blue icons, a red equivalent exists and this is produced by removing the initial "u":  (uCONT3+g) →  (CONT3+g)

For most of the red icons, a blue equivalent exists and this is normally produced by adding an initial "u":  (ABZg+l) →  (uABZg+l)

But to produce other colours, you add a suffix:  (ABZg+l black)  (ABZg+l orange)  (ABZg+l yellow)  (ABZg+l green)  (ABZg+l violet) - see c:Category:BSicon/railway/other colors for a list

Not all alternative colours have a full icon set. Consider the red set, some of the matching icons in the green set are missing:  (ABZg+l green)  (ABZgr green)   (ABZgr+xr green)  (cSTRq green)  (CONTfq green)  (CONTgq green)  (dCONTfq green)  (dCONTgq green)   (dSHI3+l green)  (dSTR green)   (dSTR~R green)   (dYRDa green)   (exCONTf@F green)  (exSTR+r green)   (SHI1+l green)   (SHI3gr green)  (STR~L green)  (STR~R green)  (v-SHI2r green)  (v-STR green)  (v-STRr green)

HTH. --Redrose64 🌹 (talk) 11:53, 8 September 2024 (UTC)

Hmm, where there are two colors in the same image, the number of needed combination gets a bit excessive. The names for all these icons and how they are put together seems not very editor-friendly, so maybe a better solution would be to come up with a new way to do this.

One way would be to make normal images, either by screenshotting the existing template and editing the colors. Another would be to use a simple table to list the stops and other elements. I like the idea of a simple table because it would cut out some visual clutter, making the diagram more accessible, and it would be easy to edit and easier to keep the links to stations and whatnot. -- Beland (talk) 18:19, 8 September 2024 (UTC)

RDTs are inherently a very complicated system because railroads (and the other linear features such as waterways and paths that RDTs are used for) are complicated. There are something like 300,000 BSicons currently on Commons, and that necessitates a system of abbreviated file names. That complexity is worth it: it is possible for users to create useful and visually consistent diagrams entirely within a template on Wikipedia. No need to use an external program (unless you're creating new icons), no need for graphic design skills, and every diagram across Wikipedia uses the same visual language.

I don't disagree that a better way to create and edit RDTs would be desirable. A graphic editor that makes it easy to find and choose icons, and get everything properly aligned, would be a great Community Wishlist item. But there's no need to reinvent the wheel, especially by screenshotting RDTs. Many line and service articles already have a station table, such as Greenbush Line#Station listing. Pi.1415926535 (talk) 02:26, 9 September 2024 (UTC)

The same benefits could be achieved with a far less-complicated markup, if we take advantage of modern wiki and graphics technology instead of using the 1990s hack of putting tiny images together in a table. Adding a visual editor on top of an overly-complicated markup I think makes things a bit worse, given that it will be very difficult to reliably render GUI inputs into the markup, at least without putting the burden of keeping track of all the little pieces on the user.

The existing markup does not have some critical user-friendliness and bug-avoidance features, for example by having a single point of truth defining the color of a line, and using English words that make intuitive sense to users who are seeing the markup for the first time. Consider how much cleaner this would be:

connections:
- Red Line (MBTA):
  icon: red_line_mbta.png

metro_line:
  name: Greenbush Line
  system: MBTA Commuter Rail
  color: violet
  accessible: yes
  stops:
    - Quincy Center:
      miles: 7.9
      connection: Red Line (MBTA)
    - Weymouth Landing/East Braintree
      miles: 11.8
    - East Weymouth:
      miles: 14.6
    - West Hingham
      miles: 16.2
    - North Scituate
      miles: 23.3 
    - Greenbush:
      miles: 27.6
  branches:
    - Old Colony Lines:
      after: Weymouth Landing/East Braintree
  rail_yards:
    - Yard:
      before: Greenbush
  continuations:
    - end: [[South Shore Railroad|South Shore RR]] to Plymouth

-- Beland (talk) 19:12, 9 September 2024 (UTC)

The number 300,000 has got me wondering how many railroad lines there even are in the world. It seems a bit silly to have just as many, if not more, reusable icons than there are objects those reusable icons are supposed to describe. I also wonder if loading and arranging lots of little images isn't slowing down page rendering, compared to loading one pre-assembled diagram per article. They are small and partially cached across pages, but I'm not sure that's a net benefit. -- Beland (talk) 19:38, 9 September 2024 (UTC)

The icons don't use English words because they were devised by the Germans. For example, for this icon,  (BHF), the letters BHF are a contraction of Bahnhof. More at de:Wikipedia:Formatvorlage Bahnstrecke. --Redrose64 🌹 (talk) 20:56, 9 September 2024 (UTC)

Yes, and that's very user-unfriendly to anyone who doesn't speak German, which is nearly everyone. A well-designed system could be localized into any language, for example by translating the keywords in the YAML-like syntax above. -- Beland (talk) 01:15, 10 September 2024 (UTC)

All this for the Greenbush Line? Mackensen (talk) 21:41, 9 September 2024 (UTC)

No, presumably this would be a project-wide alternative to the BSicon system that could be used by any article, and which if significantly better, would be something we'd migrate to en masse. -- Beland (talk) 01:16, 10 September 2024 (UTC)

Not another migration. We've had two in the past, and have only recently (mid-2023) finished migrating all of these RDTs to Template:Routemap from Template:BS-map (many of which were migrated from older forms like Template:Railway line header/Template:BS-header/Template:BS-table). The icons that were created for Template:BS-map (and those older forms) are also used with Template:Routemap: the icon names (like BHF, STR) are completely unchanged, but the syntax that is used to fit them together is completely different. Compare this:

{| {{Railway line header}}
{{BS-header|Example}}
{{BS-table}}
{{BS|CONTg||Somewhere to the north}}
{{BS|BHF||High Street}}
{{BS|HST||Market Street}}
{{BS|CONTf||Somewhere to the south}}
|}
|}

with this:

{{BS-map
|title = Example
|map =
{{BS|CONTg||Somewhere to the north}}
{{BS|BHF||High Street}}
{{BS|HST||Market Street}}
{{BS|CONTf||Somewhere to the south}}
}}

where the middle part is exactly the same but the beginning and end are different; now compare that second one with this:

{{routemap
|title = Example
|map =
CONTg~~Somewhere to the north
BHF~~High Street
HST~~Market Street
CONTf~~Somewhere to the south
}}

where the beginning and end are (almost) the same, the icon names and text are the same, but the rest of the middle part is different They all use the same four icons ( (CONTg) (BHF) (HST) (CONTf)) and produced a reasonably-similar output. Some people still can't manage the routemap syntax. Imagine the additional confusion if we introduced a "project-wide alternative to the BSicon system". --Redrose64 🌹 (talk) 08:14, 10 September 2024 (UTC)

These appear to be slightly different versions of the same relatively user-unfriendly BSicon system, rather than an overhaul that meets usability criteria like single-point-of-truth and intuitively understandable keywords.

What was the motivation for creating a LUA module to power all of this in the last migration? -- Beland (talk) 09:21, 10 September 2024 (UTC)

I can't imagine any of these existing markup styles are good for editor retention. The last one in particular looks nothing like Mediawiki syntax, and gobbledegooky enough that even as a professional programmer who could figure this out with some hours of effort, my first instinct was to run in the other direction. I'm impressed and somewhat horrified that editors have managed to use this system to create a huge number of useful and good-looking diagrams in existing articles, but given the unrepaired malfunctions of the existing system, it also seems like we are in danger of having a legacy system we can't maintain. If new editors can't be easily recruited, we'll have the wiki equivalent of trying to find COBOL programmers. Small-language wikis are going to have a really hard time finding enough people both very interested in trains and willing to plow through this user-unfriendly syntax to make and maintain diagrams, which means we're probably going to have problems getting railroad diagrams for countries where those languages are primarily spoken. -- Beland (talk) 10:12, 10 September 2024 (UTC)

Beland, the code you are suggesting would require an entirely new parser to dynamically generate the map. It would only be able to handle extremely simple RDTs - a much larger amount of code would be needed to replicate the existing {{Greenbush Line}}, much less complex track arrangements like those seen in {{JFK/UMass station}} and {{Harold Interlocking}}. Instead of the simple process of creating SVG files (much of which can be done in a few seconds in a text editor), any new function would require new functions to be added to the parser. That would require rigorous testing to ensure nothing gets broken, whereas uploading new SVG files carries no risk to the core system.

To be blunt: You don't seem to be very familiar with the routemap architecture and why it is how it is. If you want to improve this system, get more experience learning how it works by editing and creating RDTs. Right now, you're just tossing out vague ideas that would require a huge amount of work to implement, and that doesn't help anyone. Pi.1415926535 (talk) 23:08, 9 September 2024 (UTC)

Yes, you suggested a visual editor as a Community Wishlist item, which would require a huge amount of code that could both parse the BSicon format as written by human editors and also output this format. That would also require a lot of rigorous testing to make sure that the system both produces correct output when using the GUI and that round trips don't break existing diagrams. And it would have the same problem when people create new icons.

I don't think that would work nearly as well as a Community Wishlist item for building an easy-to-use transport mapping system from scratch. If we're going to be asking programmers to spend time on this, I think it's helpful to think through the pros and cons of feasible alternatives.

In the short term, I'll try and tweak the colors using the existing system, and get a better sense of the pros and cons of abandoning this system (even without a nice replacement) and merging information into the existing redundant station tables. -- Beland (talk) 01:34, 10 September 2024 (UTC)

It appears we already have problems with colors being inconsistent; Template:JFK/UMass station is already using red for the Red Line and violet for Commuter Rail. That template (and many other diagrams) are also malfunctioning in dark mode in ways that editors have tried and failed to fix (see Template talk:Routemap#Dark mode problems), and they have typological problems like from one line running into text on the line below it. Unfortunately, because everything is composed of SVG images instead of being laid out by a more intelligent rendering engine, I think if text height is increased to avoid the overlapping problem, we would be in danger of breaking the diagrams by introducing whitespace between segments of a given line. -- Beland (talk) 01:41, 10 September 2024 (UTC)

I'm a programmer and do my code-thinking in the shower, which is where I just realized I've run into the same testing problem (generally speaking) at previous employers. The problem is that when you make a change that should make no user-visible changes to a complex processing system (for example, refactoring some messy code, or adding a new icon no existing pages are currently using), you want to make sure you didn't break any existing functionality. An easy solution is to make an automated test (all quality software has lots of automated tests) that runs all instances in existing wikitext through the system, both with and without the proposed changes, and diffs the result. Any differences detected should be a red flag to the code reviewer that the changes not be deployed.

Another problem with the existing system is that it doesn't allow sharing across languages. I was just looking at the English and Spanish versions of the MBTA Red Line map. They have gotten out of sync, with the English one showing more details on abandoned stations, and the Spanish one having a more readable design (though it has CSS layout issues, overlapping the References section text). The German one is yet another design that uses different symbols for some of the same things on the English diagram, but is slightly broken (there's visible whitespace between some of what should be continuous segments) and adds unnecessary details (like the shapes of crossing lines) which make it harder to read. It's missing information about accessibility. (Though the accessibility icons on the English version are sometimes too small to be able to make out clearly, and increasing my browser zoom level doesn't help; it looks like some SVG files have been rendered into PNG files just a few pixels square.) The Chinese Wikipedia doesn't have a diagram at all; just a station table. Even though there's a big Brazilian popuation in metro Boston, the Portuguese Wikipedia only has an MBTA article, and none on the Red Line at all, though the geographically-accurate system map is very good.

A typical modern web site would provide a spot to put translations of individual snippets. For example, this YAML-like syntax could have "name_en", "name_es", etc. so that the source code could live on Commons and maps could be produced for any language for which there are translations (perhaps defaulting to the native language of the rail system where there are holes). -- Beland (talk) 02:59, 10 September 2024 (UTC)

The German one is yet another design that uses different symbols for some of the same things on the English diagram - which symbols? The icons are all held on Commons, they should all have the same names. --Redrose64 🌹 (talk) 08:38, 10 September 2024 (UTC)

(Correction: Found the route diagram for Chinese; it was hidden by default, as are most. It's very similar to the English one.)

I mean, if you just look at the English and German ones side by side, you'll see lots of differences. The German one uses blue dots (which vary in size for no discernible reason) to represent stations, and white-center circles to represent train yards. The English version uses both white-center circles and fork-like icons to represent train yards. For stations, it has a variety of symbols which vary for no discernible reason - person in wheelchair in a big blue disc, a small blue disc, a white-center circle, or a white-center oval.

The German one has splotches of red next to the terminal stations, which are unexplained and are not accessible to people who are color blind. The English one doesn't have those, but it does have icons showing connecting services. They are linked to explanatory articles, which is nice, but the icon for the Commuter Rail is confusing. It's a generic black T-in-white-circle, which is the logo for the entire MBTA, rather than having the violet color that system maps use to indicate the Commuter Rail specifically.

Unfortunately, the English version is also lacking a legend, so it's unclear if the dashed lines mean proposed, closed, underground, part-time, or what.

It seems like we're failing to achieve the promised consistency (even within the same diagram, much less across articles) because editors are sometimes picking slightly-wrong icons. I assume this could be prevented if instead of hunting manually through a large icon set, they were specifying the properties of stations and connections in words and an algorithm was picking the correct visual representation. -- Beland (talk) 10:03, 10 September 2024 (UTC)

Tracks and lines are somewhat different types of things, so a representation with different semantics would probably be helpful, though a lot could be shared. {{JFK/UMass station}}, for example, could be represented with something like the below. The system could generate much better hover text, for example "MBTA Red Line Track 4 (Alewife)" instead of "vSTR red". (Directionality is assumed in places to be top-to-bottom and left-to-right.)

station:
  name_en: JFK/UMass
  tracks:
   - service: MBTA Red Line
     name: 1
     direction: Ashmont
   - service: MBTA Red Line
     name: 2
     direction: Alewife
   - service: MBTA Red Line
     name: 3
     direction: Braintree
   - service: MBTA Red Line
     name: 4
     direction: Alewife
   - service: MBTA Commuter Rail
     name: 5
     # bidirectional
   - service: MBTA Commuter Rail
     name: Greenbush Line
  flow:
   - crossing:
      name_en: Columbia Road
      type: road
   - segment:
      - track: 1
      - platform: Outbound
      - tracks: 2, 3
      - platform: Inbound
      - tracks: 4, 5
      - platform: Commuter Rail
   - crossing
      name_en: Southeast Expressway
      type: road
   - segment:
      - tracks: 1, 2, 3, 4
      - track_branch:
         left: 5
         right: Greenbush Line
   - segment:
      - tracks: 1, 2, 3, 4
      - track_crossing:
         moving_track: 5
         moving_to_after: 2
         type: tunnel

Lots of track_crossing syntax could represent the complicated interlocking further north, adding type=at_grade and type=bridge, with tunnel_exit indicating where to render certain tracks as underground. Yeah, there's a bunch of code to write to transform any given combination into a diagram, but it seems nicer to write out and verify those rules once for all time, and have a computer implement them flawlessly every time, instead of having lots of different humans try to learn them incompletely at various times and implement them in a mistake-prone way. There is already a lot of software for making diagrams that automatically connects entities that humans drag-and-drop into the right places. -- Beland (talk) 10:58, 10 September 2024 (UTC)