Wikidata talk:WikiProject Railways

Archive: Wikidata talk:WikiProject Railways/Archive 1

Track gauges that are similar

When looking at track gauges that are similar but not identical, is it best to use a single track gauge or create a separate track gauge item? I am specificaly thinking about 2ft/600mm/603mm/597mm etc. I created an item for 603mm: https://www.wikidata.org/wiki/Q133887156 but then realised there is https://www.wikidata.org/wiki/Q18980194 and I don't know which is best Asdfghjohnkl (talk) 22:39, 16 April 2025 (UTC)

Hi @Asdfghjohnkl,
I'd say that different items are required.
For example, there are different items 1520 mm track gauge (Q1197451) and 1524 mm track gauge (Q19750814), and this case seems similar to yours. Michgrig (talk) 07:19, 17 April 2025 (UTC)

Disused/former railway lines

Is there a standard for representing lines that are no longer in use? I noticed there's a section "Disused/former railway stations?" above but don't know what the norm would be for whole line. I've seen various things, e.g. date of official closure (P3999) or state of use (P5817), or date qualifiers on the "instance of", or types like abandoned railway (Q357685) 188.212.135.134 16:51, 31 July 2025 (UTC)

Docklands Light Railway rolling stock

Docklands Light Railway rolling stock (Q16988848) appears to be based on a mix of B07 and P86 stock (e.g. an image of the former and builder of the latter). Before I fix it I want opinions on whether it would be best to have information like builder, capacity, introduction into service date, etc on this item with applies to part (P518) qualifiers or to have that information on separate items for each stock (which don't currently seem to exist)? Thryduulf (talk) 02:50, 7 December 2025 (UTC)

It is definitely better to create a separate item for each class. Feel free to use ‎Trainspo model ID (P13817) as well. Jklamo (talk) 11:45, 18 February 2026 (UTC)

Modelling the relationship between train services and railway lines

Where an instance of a train service (Q15141321) (or one of its subclasses) operates over an instance of a railway line (Q728937), which properties should be used to represent this relationship? So far I have come across examples of uses (P2283) on the train service and the inverse property used by (P1535) on the railway line, uses (P2283) on the train service with no inverse property, and connecting line (P81) on the train service with no inverse property. It doesn't seem to be a regional thing—I found examples of all three just within Germany. Is there a preferred approach? Tomiĉo (talk) 02:30, 4 September 2026 (UTC)

Removing disambiguators from train station labels

The other day, I noticed an inconsistency in the English labels for train stations in the San Francisco Bay Area (Q213205): many ended with "station" per the English Wikipedia, while a number of others did not (and never did). At least in this region, the word "station" isn't formally a part of most station names, though it can be used as an optional generic (Q141440583). For consistency within these systems, I relegated the "station" form of each station to an alias and added the proper name as the mul label. This also effectively allows non-English speakers to see labels such as "San Bruno" and "Cropley". The affected systems are: Caltrain (Q166817), Bay Area Rapid Transit (Q610120), Santa Clara Valley Transportation Authority light rail (Q1337235), Sonoma–Marin Area Rail Transit (Q7562166), and Muni Metro (Q278074). Another editor has asked me to undo the changes to Muni Metro (Q278074) station items, so I want to get a second opinion from the community.

My understanding is that the "station" suffix came from English Wikipedia article titles. After a spate of move wars back in the day, we settled on a set of U.S. railway station naming conventions that generally appends "station" to article titles as a form of natural disambiguation to work around a technical limitation in MediaWiki. Wikidata's de facto guidelines discourage disambiguators in English labels, because the technical limitations do not apply. I take this to mean natural disambiguators as well, especially since items in other classes have also dropped natural disambiguators. For example, language item labels no longer end with "language": "French", not "French language". We've systematically removed "station" from the labels of items for most of the country's major rapid transit and commuter rail systems, including New York City Subway (Q7733), Southeastern Pennsylvania Transportation Authority (Q2037863), Los Angeles light rail (Q62086544), Portland Streetcar (Q1753708), Utah Transit Authority (Q7902494), TRAX (Q962390), Link light rail (Q2778618), and (almost) Chicago "L" (Q820880). External references such as Onestop ID (P11109) and SFMTA ID (P11618) also omit disambiguators in general.

I'm aware that removing "station" from the labels causes them to diverge from page titles on Wikipedia and Wikimedia Commons. This may take some getting used to for Wikipedians, but I think it's more useful in the long run. Wikidata labels shouldn't be subject to workarounds for technical limitations in MediaWiki page titles. Other consumers of Wikidata labels have also expressed a strong preference for the undisambiguated form. [1] That said, I'm aware that conventions in the real world and published sources can differ regionally, so I'm not necessarily suggesting that we eliminate "station" everywhere. I'd be open to handling it on a system-by-system basis if necessary.

(Crossposted at Wikidata:Project chat.)

 – Minh Nguyễn ^💬 20:02, 12 September 2026 (UTC)

I firmly disagree. "Station" is not a disambiguator; it is generally part of the common English name of the station. It's fine for the mul label to leave out "station", but the English labels should use "station". If reusers like OSM don't like "station", they can do their own processing. Pi.1415926535 (talk) 20:26, 12 September 2026 (UTC)

My local station, Q2382124, is named "Hamstead". Nowhere—not on signage, tickets, maps, timetables, ticket booking websites, or anywhere else—is it called "Hamstead railway station" (as we currently label it).

Even en.Wikipedia can't decide whether to call it "Hamstead railway station", "Hamstead Station" or simply "Hamstead". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:26, 13 September 2026 (UTC)

Contra @Pi.1415926535, I agree with the OP. "Station" is not usually part of the common name of stations in the English-speaking world (although there are exceptions) and is only added when context is not clear that it is a station being discussed in exactly the same way that common nouns are appended to the names of other things when context alone is not sufficient to be unambiguous. Thryduulf (talk) 20:30, 12 September 2026 (UTC)

I think you should be cautious here. A query of US stations shows a right muddle of labels, but if you want to introduce consistency, I think you should use the properties name (P2561) and especially short name (P1813). There will be a lot of downstream users of station names that would not appreciate them changing, but you can clearly argue that short name (P1813) does not need the word station, and perhaps name (P2561) consistently does, so users can pick. Much better than trying to select labels, aliases and mul. I had this problem with ship names, and policing labels was too hard. Producing consistently country and worldwide would be a good cause. Vicarage (talk) 00:45, 13 September 2026 (UTC)

@Vicarage: I appreciate your note of caution. It was never my intention to make the labels consistent worldwide, though others may have such ideas. The trend in the U.S. is to drop "station", but you're right that we don't have full consistency nationwide either. In the Bay Area, the status quo ante was unsupported by any guideline: internally inconsistent even along a single line within a single system, while the external references generally omit the "station" suffix or use "Station" as part of a more formal name. I agree that setting name (P2561) is a good idea, but we already see above that some editors feel "station" (lowercase) is an integral part of the name in English, so we would be having the same dispute anyways. Meanwhile some stations already have true short name (P1813) for reasons unrelated to Wikipedia, such as California Avenue (Q5020256) and Berryessa/North San José (Q4894857). It's impossible to know who all would depend on "station" being present in the label – Hyrum's law (Q141442631) and all that – but there have already been instances where the prevalence of this suffix has hampered Wikidata adoption. Minh Nguyễn ^💬 01:58, 13 September 2026 (UTC)

Hi, my two cents: I would personally favour keeping the shorter name without “station” in the English label.

Adding “station” can lead to several equally valid naming patterns — “X station”, “X railway station”, “X train station”, “station of X”, etc. I therefore think the shorter and more neutral name should generally be preferred for railway stations, while the more explicit variants can be kept as aliases.

A similar principle can be seen in other fields: for example, “Paris” rather than “City of Paris”.

That said, I’m reluctant to change English labels myself, since English isn’t my native language and I may be missing some naming conventions specific to English-speaking countries. However, as far as I know, there is no specific rule stating that the (English) label should necessarily match the title of the corresponding (English) Wikipedia article. Bouzinac ^{💬●✒️●💛} 17:57, 13 September 2026 (UTC)

When dealing with Russian labels of train stations in Russia, I do the same - remove the suffix in parentheses from labels. Michgrig (talk) 18:09, 13 September 2026 (UTC)

Generally I would expect the label to only include the actual name of the station. Which may include the word Station, but usually does not. Not sure if that is clear if you change all the labels automatically though. That it is a station should be in the description or I guess as an alias could be acceptable too. Kordishal (talk) 12:09, 14 September 2026 (UTC)

Yeah, I made the changes manually to avoid accidentally munging anything that should’ve had a different label entirely. There were a few stale station names in the set that I touched. Minh Nguyễn ^💬 14:56, 14 September 2026 (UTC)