Misplaced Pages

Revision as of 22:58, 14 October 2020

Template:Infobox station is permanently protected from editing because it is a heavily used or highly visible template. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by consensus, editors may use {{edit template-protected}} to notify an administrator or template editor to make the requested edit. Usually, any contributor may edit the template's documentation to add usage notes or categories. Any contributor may edit the template's sandbox. Functionality of the template can be checked using test cases.

This is the talk page for discussing improvements to the Infobox station template.

Put new text under old text. Click here to start a new topic. New to Misplaced Pages? Welcome! Learn to edit; get help. Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed

Archives: 1, 2, 3, 4, 5Auto-archiving period: 28 days

This is the talk page for discussing improvements to the Infobox station template.

Put new text under old text. Click here to start a new topic. New to Misplaced Pages? Welcome! Learn to edit; get help. Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed

Archives: 1, 2, 3, 4, 5Auto-archiving period: 28 days

Trains: Stations Template‑class

Trains Portal This template is within the scope of WikiProject Trains, an attempt to build a comprehensive and detailed guide to rail transport on Misplaced Pages. If you would like to participate, you can visit the project page, where you can join the project and/or contribute to the discussion. See also: WikiProject Trains to do list and the Trains Portal.TrainsWikipedia:WikiProject TrainsTemplate:WikiProject Trainsrail transport Template This template does not require a rating on Misplaced Pages's content assessment scale. Associated projects or task forces: /  This template is supported by WikiProject Stations.

This template was considered for merging with Template:Infobox Ireland station on 2014 December 29. The result of the discussion was "merge Template:Infobox Ireland station and Template:Infobox Ireland disused station into this template".

This template was considered for merging with Template:Infobox Deutsche Bahn station on 2015 February 8. The result of the discussion was "merge Template:Infobox Deutsche Bahn station into this template".

This template was considered for merging with Template:Infobox Paris metro on 2015 February 8. The result of the discussion was "merge Template:Infobox Paris metro into this template".

This template was considered for merging with Template:Infobox China station on 2015 February 8. The result of the discussion was "merge Template:Infobox China station into this template".

This template was considered for merging with Template:Infobox Japan station on 2015 May 9. The result of the discussion was "merge Template:Infobox Japan station into this template".

This template was considered for merging with Template:Infobox T&W Metro station on 2015 June 11. The result of the discussion was "no consensus".

UK stations merge

Following a TfD on the merge of various UK stations templates, I've begun work on setting up wrappers for them to make sure we get everything useful in. ProcrastinatingReader (talk) 17:38, 1 August 2020 (UTC)

Wrappers:

• {{Infobox GB station/sandbox}} (testcases)
• {{Infobox UK heritage station/sandbox}} (testcases)
• {{Infobox UK disused station/sandbox}} (testcases)

Course, we need to make decisions on a few parameters/pieces of functionality, and some implementation details should be noted, so I figure I'll start a discussion here for continued input.

Missing parameters:

•  Done pte: Passenger transport executive
•  Done gridref: Ordnance Survey National Grid

Merge notes

(for the sake of avoiding surprises and catching nitpicks)

•  Done (using extra param for Foryd railway station) {{Infobox GB station}} supports 12 historical year/event entries, this template supports 11. No change required, since no templates are actually using the 12th.
  • {{Infobox UK disused station}} supports 16 of them, but only one uses more than 11 (it uses 12). We can move "Opened" to the proper opened param, then it'll only have 11, problem solved ;) -- so no additional history params required here either. edit: added a years12/events12 param to account for the usage at Foryd railway station
• {{Infobox GB station}} supports an "other name". According to the documentation this is meant to be used for "Welsh/Gaelic/etc" names, these cases we can safely map to native_lang (with some format adjustments, and bot can interpret the template used to fill in native_name_lang), but de facto this param is 'abused' to use a literal other name (in English) for stations (eg at Newcastle railway station). These alternate names should probably be removed by hand, but there's no harm to just carrying them over and having them be fixed later. It would be improper use, of course.
• {{Infobox GB station}} has two place parameters, |locale= and |borough=. The testcase merges this into borough, per documentation here. In many cases, the values are awfully similar (eg see testcase for Manchester Piccadilly), so I'm not sure why the values are duplicated. Ideally, one value should probably be trimmed, since it looks clumsy. (e:) For the sake of merge, they're just combined into |borough= as comma-separated, as is typically done in this template.
•  Done {{Infobox GB station}} has an extra 'passengers' value for 'interchange' numbers. These rows are prefixed with "– Interchange", and often repeated per year entry. We'd need to add support to {{Rail pass box}} to retain custom labels to keep these, although it does beg the question, do we need interchange figures in the infobox?
• The designation grade is given as a wikilink (eg ]). Bot will need to strip these into valid values for {{Infobox designation list}} - trivial find/replace.
  •  Done (in template in the meantime)
• Usages of these templates often give the opening date as a year/event value, rather than use their own start param. Not a problem, a simple map will retain the view as exists, but for proper usage of this template those values should be remapped. A bot could do this pretty easily, by checking if |events= (ie events1) contains "Opened", but eh. Striking from merge, can be discussed later if need be.
  • Retain usage of events for disused stations, per Redrose below, but active stations should probably start using opened (eg it's confusing Google)–most don't have multiple openings.
• These templates link to external boxes to enumerate letters for UK railway stations. We can still support this using embedding, probably, but I believe TfD consensus was going towards it not being necessary, so perhaps it should just be omitted?
•  Done (in template) {{Infobox GB station}} has interesting functionality for tracking categories where passenger numbers aren't updated for a year. Effectively just: {{#if:{{{usage1415|}}}{{{lowusage1415|}}}||]}}{{#if:{{{usage1516|}}}{{{lowusage1516|}}}||]}}{{#if:{{{usage1617|}}}{{{lowusage1617|}}}||]}} -- I'm not yet sure how/if we want to replicate this. There are a number of ways to do this, should we wish to keep it, ranging from luaification to bot runs.
• Testcase note: Passenger lists are not complete. I haven't added every single mapping for the years yet. For a better idea of how it'll look, look at the Manchester Piccadilly testcase, which has more rows filled.
•  Later (can be discussed after merge) Infobox structure: See testcase for GB infobox, mainly the differences between the two in terms of headers and how labels are 'categorised'. Can/should we organise the labels differently in this template? That template seems to structure better (eg into location, operated, etc)? Effects on other countries' templates should be considered.
• Passenger values: That template manually does {{increase}}, whereas this template uses {{Rail pass box}} which prefers |pass_percent= (and calculates up/down based on if %>0). Ideally, over time and for newer years, articles supply the percentages instead.

Discussion

Regarding passenger numbers, many articles will have data going back to 04ish, but with anything before the last five years commented out. There have been discussions in the past about some sort of chart, but no one could quite work out how it should be displayed. Also of note that some stations which are now closed may have stats but for 10 years ago. -mattbuck (Talk) 19:21, 1 August 2020 (UTC)

I have some questions on the "merge notes" above.

1. Please do not move "Opened" to 'the proper opened param', we have been trying to go the opposite way for some time - moving them to the initial year/event pair. Having a dedicated "Opened" parameter is OK if a station opened once, has stayed open ever since and kept its name throughout, but if it was ever closed and reopened, or was renamed at some point, it is desirable to have consistent presentation.
2. On no account should locale and borough be conflated. They have different purposes, and there are comparatively few cases where they hold similar values.
3. These templates link to external boxes to enumerate letters for UK railway stations - what external boxes are these?

--Redrose64 🌹 (talk) 23:14, 1 August 2020 (UTC)

1. Noted
2. I believe this template (and its usages) often combines city+province fields in |borough= with a comma (eg see example in doc). See current testcase for the quick implementation of that currently.
3. Bottom of the infobox, the A-Z row with links to UK railway stations

ProcrastinatingReader (talk) 23:34, 1 August 2020 (UTC)

Just a comment, but I see "Operated by" in the new infobox, and that's a bit of an iffy word in UK railways as the train operator is not always the company which manages the station. -mattbuck (Talk) 10:09, 2 August 2020 (UTC)

There's a separate parameter, train_operators, that reflects that distinction. Mackensen (talk) 12:16, 2 August 2020 (UTC)

My point is that saying Network Rail "operate" a station is problematic. -mattbuck (Talk) 15:25, 2 August 2020 (UTC)

Mattbuck, what exactly do they do in their "managing a station" capacity? Do they only 'manage' some railway stations, or do they manage all UK railway stations? Reading they own a number which are operated by train operators, and operate 20 directly? ProcrastinatingReader (talk) 13:08, 29 August 2020 (UTC)

ProcrastinatingReader, Network Rail own pretty much every station in the UK (excepting a few specialist ones like Heathrow Terminal 5). They manage (as in staff, let shops etc) a few specific big stations, they do not however run any trains, instead this is done by a train operating company (TOC). TOCs manage most stations, and maintain them in concert with Network Rail - I think that it's something like floor level to 8ft above is the station manager, everything else (including track, signals, bridges, etc) is Network Rail. -mattbuck (Talk) 15:45, 29 August 2020 (UTC)

Mattbuck, they only operate 20 stations though, right? If so, for these 20, isn't it accurate to use "Operated by"? (for the rest, it wouldn't be of course, and I don't think it is shown on most currently, because it's a bit redundant to put "owned by" National Rail on each one). ProcrastinatingReader (talk) 15:48, 29 August 2020 (UTC)

ProcrastinatingReader, for me the problem is terminology. The "operator" of a station to me might be a train operating company which runs trains from it - one of many - while saying the station is managed by is the specific company who are responsible for that station. -mattbuck (Talk) 16:01, 29 August 2020 (UTC)

Mattbuck, that part I get. Let me try rephrase what I'm getting at: Network Rail do operate 20 stations, right? The rest are operated by the TOCs. So for those 20, is saying "Operated by: Network Rail" a problem? Seems accurate to me? For the others that aren't part of this 20, Network Rail shouldn't be in the infobox at all imo, it's redundant to say for each rail station in the UK that it's owned by Network Rail. ProcrastinatingReader (talk) 13:04, 30 August 2020 (UTC)

ProcrastinatingReader, there are some stations not owned by Network Rail, but not many. If we are using "Operated by" to mean "managed by" then we also run into places like Burton-on-Trent, where the only TOC is CrossCountry, but the station is managed by East Midlands Railway. Again, I just don't like the term "operated" as it means something specific in a UK context. -mattbuck (Talk) 21:01, 1 September 2020 (UTC)

Gotcha. Sounds good to me. I'm happy to add the parameter if no other objections. Caution should be advised, however, as whilst this usage may be more clear for UK usage, it could be misinterpreted more globally (likewise, it could have valid uses globally, too). We need clear definitions for the "Operated by" and (new) "Managed by" params to prevent misuse. ProcrastinatingReader (talk) 21:05, 1 September 2020 (UTC)

"Operated by" in a UK context is the organisation responsible for the day-to-day management of the station building and facilities (platforms, bridges, information posters, PA system, etc. not the track or signals). This is most commonly the train operating company that runs the majority of the services to the station but might also be a different TOC (e.g. Burton on Trent), Network Rail (e.g. London Paddington), London Underground (e.g. Queen's Park), a PTE, some other organisation (e.g. Heathrow Terminal 5, Corfe Castle) or multiple organisations (e.g. Liverpool Lime Street). That the term means something different elsewhere in the world is another example of the unnecessary problems caused by trying to shoehorn a template designed for the UK's idiosyncratic rail network into a generic one. Thryduulf (talk) 12:34, 3 September 2020 (UTC)

I aim to please.  Done. ProcrastinatingReader (talk) 13:04, 12 September 2020 (UTC)

Let me just say that I'm not all that satisfied with how passengers are presently implemented (see above discussion); if a wholesale refactoring is necessary to properly integrate the GB passenger data then I'm all for it. Mackensen (talk) 13:07, 2 August 2020 (UTC)

A locale is not necessarily a city, it might be a hamlet, village or town; it might be a named part of a town or city. It should be wikilinked, but need not be.

A borough is not a province. The correct use of the |borough= parameter is described at both Template:Infobox GB station#Syntax and at Template:Infobox UK disused station#Example.

Concatenating these two - even with a comma - is not helpful. --Redrose64 🌹 (talk) 08:29, 3 August 2020 (UTC)

A few thoughts from the merge notes not yet addressed - open and disused stations need to present data in the same way for consistency. Interchange numbers do need to remain in infoboxes as the entry/exit figures alone present a misleading view of the use of some stations (e.g. Clapham Junction, Dovey Junction and Birmingham New Street). Thryduulf (talk) 01:58, 1 September 2020 (UTC)

Thryduulf, does it matter that much, keeping open and disused stations consistent, when they're not even consistent amongst each other in how they show the opened date? Opened stations use events params instead of |opened=. On some articles like Haymarket railway station it just looks worse than using "Opened: 1842" (label: value) in my eyes. It's not consistent with other articles, some which have the label as the date (like Bramley railway station (Hampshire)), with a varying value. Others use "Opened" as the label. It looks like Google is actually extracting data from the infoboxes. Sometimes it can parse it, so it uses the "Opened" label in sync with its own opened val, other times it can't tell that it's the opened so it uses the date as a label (eg "Hunts Cross station"), and sometimes it can't make sense of the input at all. Admittedly, it's less work for me to keep it as-is, so I'm going to strike it from the merge and keep it as-is (noting it can still be addressed later if consensus dictates it's an issue), but I do think it's problematic. ProcrastinatingReader (talk) 19:02, 1 September 2020 (UTC)

Neither {{Infobox GB station}} nor {{Infobox UK disused station}} provide an |opened= parameter (it is tested for, in order to detect unusual parameter usage, but is not displayed). They do have |start=/|end=, but these are really only there to provide an easy change from |starting= when a proposed station gets opened for real. We have been trying to move away from start/end parameters towards |yearsn=/|eventsn= because these are much more flexible. This has been taking some time, on account of the sheer number of stations - there are 2,500 open stations and many times more that are disused, and also because in each case the data needs to be checked to ensure that it's not a rogue value. --Redrose64 🌹 (talk) 06:54, 2 September 2020 (UTC)

Native name

"Native name" is not an appropriate mapping for "other name", neither English nor Welsh names for a station in Wales are more or less "native" than the other, and using it for the Punjabi name at Southall railway station would be actively misleading. Thryduulf (talk) 10:22, 3 August 2020 (UTC)

I think 'native' should be considered more loosely than that. I don't think it's inappropriate for a Welsh name of a station. For Southall railway station, yes, if that's not an official name it would probably be misleading. But in terms of visible output it looks pretty much the same, so it's mostly a semantic difference in how the parameter is named. I don't think adding a second |other_name= to show up there is a good idea - it's only going to conflate the two and cause them to be misused, as is often seen with templates. It's also feels a little vague. For Southall, I think the appropriate usage might be to move it into the infobox's "Other names", but a bot can't really tell the difference between conflated official and unofficial other names. ProcrastinatingReader (talk) 10:33, 3 August 2020 (UTC)

More parameters leading to inappropriate use, misuse and added confusion was exactly why many of us argued against this merge. To then use those same arguments as reason why the merged template cannot have the same functionality as the ones it is replacing seems rather disingenuous. Thryduulf (talk) 10:44, 3 August 2020 (UTC)

imv, I don't think it's necessarily more parameters that leads to misuse, I feel it's broadly named parameters that does. The official name of the station, and the unofficial but commonly used name by a local community, should not really be conflated into the same parameter in my view (regardless of languages or if it's just an alternate colloquial name in the same language). There's no loss of functionality indicated w.r.t. |other_name=, display output is pretty much the same. Unless having to instead use the parameter name "native_name" is a loss of functionality, but I personally feel the distinction is helpful? ProcrastinatingReader (talk) 10:55, 3 August 2020 (UTC)

We don't specify "the unofficial but commonly used name by a local community". We specify only that name (or those names) that are actually shown on the station's nameboards. In Wales, some stations (e.g. Bangor) have the same name in both English and Welsh, so their nameboards show the name once only; but most stations have two names on the same board: a green one in Welsh, and a black one in English - even if the spelling difference is slight (e.g. Treforest; nameboard). When there are two, which one is official? Answer: both of them are used by the railway, therefore both must be equally official. So we show both in the article - we have absolutely no reason to deny recognition to one of them. --Redrose64 🌹 (talk) 15:39, 3 August 2020 (UTC)

Those are mapped to native_name, which is shown at the same place as {{Infobox GB station}}. So for Treforest, for example, it would look like . Obviously some work to the layout would be beneficial, but it follows the same idea. ProcrastinatingReader (talk) 16:34, 3 August 2020 (UTC)

The point here is semantic: Use of "Native name" for Welsh implies that the English name is not equally native in the same way that Qom railway station and ايستگاه راه آهن قم are not equal and as already noted it is also completely wrong for stations like Southall. Remember that our structured data will be used semantically by Wikidata and other projects (not all WMF) so its important to get it right. I also note that the important note regarding the passenger usage figures is missing and that comments about the difference between a station being managed by X and operated by X have not been addressed so far. Thryduulf (talk) 12:55, 10 August 2020 (UTC)

PTE

What's our consensus on the two extra parameters? The discussion in the TfD was headed towards implementing PTE somehow, and scrapping gridref? Ideas on implementing PTE nicely? (ping @Mackensen ProcrastinatingReader (talk) 09:33, 9 August 2020 (UTC)

I am against the removal of any existing functionality, particularly gridref. --Redrose64 🌹 (talk) 16:34, 9 August 2020 (UTC)

I'm going to restate what I said during the discussion: gridref appears to get turned into another coordinate link that gets routed through toolforge. I appreciate that Ordnance Survey National Grid is its own thing, but from the end-user's perspective the end result is the same, except the level of specificity differs. I'm not sure it makes sense to have both. Regarding PTE, I'm unsure. This sounds similar but different from Swiss Tarifverbands, which get linked in through zones or otherwise not mentioned. I don't believe anyone, pace Redrose64 (talk · contribs), proposes a loss of functionality. Infobox station already supports the display of coordinates; it's not clear why we would need two methods, with differing levels of precision. Regarding PTE, I'm unsure. What are these bodies? How do they compare to bodies in other countries? Are they like Swiss Tarifverbands? US commuter agencies? The RER networks in France? The various sub-national operators in Italy? Clarity would be helpful. Mackensen (talk) 17:24, 9 August 2020 (UTC)

I'm sure I've explained this before. A PTE (Passenger Transport Executive) is a body with responsibility for coordinating bus, rail and tram transport, as well as other functions, in seven of the larger metropolitan areas of England and Scotland, except for London (where TfL functions very much like a PTE but with extra responsibilities). They were set up between 1969 and 1974, and occasionally enlarged. --Redrose64 🌹 (talk) 20:34, 9 August 2020 (UTC)

That's pretty close to the Swiss concept of the Tarifverband. Do I understand correctly that there's no direct connection between the station and the PTE? Mackensen (talk) 22:20, 9 August 2020 (UTC)

The PTEs propose and fund new stations, and fund refurbishment of existing stations. But the day-to-day running of the stations is carried out by the train operating companies. --Redrose64 🌹 (talk) 23:01, 9 August 2020 (UTC)

PTEs can also be involved with route/network and station branding, publicity and (to a certain extent) with fares (e.g. rover tickets) so they are often visible to the passenger, especially where they also have involvement with other passenger transport (buses, trams, ferries). Its important functionality to have, but whether they are directly comparable to anything in other countries I don't know - please link to the relevant articles or other information about them so that we can actually do the research (which should have been done before a merge was proposed by the way), but most things related to public transport in the UK correlate poorly to equivalents in other countries. Certainly they are different to RER networks. As for grid references, these are only the same as coordinates from an end users point of view if 100% of their use comes from people clicking on them to be taken to mapping services via toolforge - which sounds very unlikely so unless you have evidence of this I'm going to agree with Redrose64 that removal would be a loss of functionality. Thryduulf (talk) 12:42, 10 August 2020 (UTC)

A PTE sounds a good deal like a Transit district, which is pretty close to the Swiss concept. I think a general-purpose transit district field would make sense, in the same part of the template as zone. Mackensen (talk) 16:06, 10 August 2020 (UTC)

While a PTE is similar to a transit district in some respects, the article strongly implies that the key feature of a transit district is that it controls and operates public transport. In the UK, only Transport for London (which is technically not a PTE) meets this definition. Thryduulf (talk) 22:25, 10 August 2020 (UTC)

I find Passenger_transport_executive#Similar_authorities an interesting section. With the caveat that I am not an expert on transport organization, my impression is that most countries (even us backward folk here stateside) have created something along these lines. The German article (Verkehrsverbund ) is much more comprehensive. Mackensen (talk) 22:34, 10 August 2020 (UTC)

Thryduulf, out of curiosity, what's the difference between TfL and the PTEs? As in, legally, why isn't TfL just a PTE? Does it have powers that PTEs don't, or is it just a legacy thing? ProcrastinatingReader (talk) 12:45, 11 August 2020 (UTC)

The simple answer is that TfL does a lot more than PTEs do. It's a sui generis organisation that's legally a special purpose local authority, meaning it operates under different legislation and has more responsibilities. It specifies and (directly or indirectly) operates almost all local public transport in the Greater London Area and has involvement (to varying degrees) with cross-border local public transport and some long distance public transport, and controls advertising on local public transport. It is also a roads authority and the licensing body for taxis, private hire and river services operators. Thryduulf (talk) 13:12, 11 August 2020 (UTC)

I see, interesting. Regarding the parameter itself, I have two ideas:

1. Just use "transit authority". De facto, that's what the PTEs are, kinda, even if they're named somewhat differently? Obviously there's power/authority differences, but I imagine the same applies for transit authorities worldwide (some will be named slightly differently, have different scopes, etc.)
2. Use a template check to support both. Effectively, if the country param is GB/UK, and the transit authority param value is one of the PTEs, (eg value is "Greater Manchester") it'll show the label "PTE" instead. ProcrastinatingReader (talk) 14:22, 11 August 2020 (UTC)

1. More parameters and so more work to maintain and more complicated for users (i.e. exactly the opposite of the alleged benefits of a merge), but the only solution that I think works for all cases would be to have a "transit_authority" parameter and a "transit_authority_type" parameter, the latter accepting defined values only and defaulting to "Transit authority" if unspecified or an unrecognised value (with the latter showing an error on preview). Thryduulf (talk) 14:42, 11 August 2020 (UTC)

   It rather does the opposite. Insisting on maintaining what amounts a parallel module because of one parameter seems hard to justify on its face, especially when it would support other, similar concepts in other countries. Seems like everyone benefits. Mackensen (talk) 19:51, 11 August 2020 (UTC)

   But the point is that there would be no need for a module in the first place as a single parameter with a hardcoded label would be all that would be required - zero maintenance requirement and nice and easy for users. Thryduulf (talk) 21:08, 11 August 2020 (UTC)

PTE (2)

I'm going to split this out for readability. We've determined in the above discussion that a PTE is something of a transit district/transit authority/tarifverband, but does not fit neatly into any of those categories. Indeed, the implementation of such organizations varies from country to country. In addition, the infobox doesn't currently support that concept, though such information is often brought it via the zone parameter. Thryduulf suggested having separate parameters for the transit authority and its type (which would override the default label), and I think that makes a good deal of sense. I'm not too concerned about usability; realistically this is a parameter that is set once and never changed. A reasonable default would be Transit district, with an override available for PTE to start, and other country-specific systems as the need arises. Mackensen (talk) 22:01, 11 August 2020 (UTC)

Working example at Template:Infobox_station/testcases#Duddeston. One immediate issue: I don't know if this comes up in Great Britain, but in Switzerland overlapping zones are common. Mackensen (talk) 22:20, 11 August 2020 (UTC)

I suppose you can have a fare zone without a PTE, so I don't think using a header would work consistently? I think a label might work best.

@Thryduulf: to clarify my two suggestions above, I was going for either:

1. One label for "transit authority". Don't use "PTE" in infobox at all. De facto, the PTEs appear to be transit authorities. If we think about this more broadly, globally, transit authorities in various countries will have different names, responsibilities and scopes. I don't really see the need to make the PTE distinction in the infobox, personally. After all, they do seem to be "transit authorities" when considered broadly. OR
2. If we are to retain the PTE label, have the template decide when to use it automatically. i.e. if |transit_authority= = "Greater Manchester" for example, the template automatically changes the label name from "Transit authority" to "PTE". Since there are only 6 PTEs, this isn't infeasible to do in a template. I'm not a fan of making a |transit_authority_type=. Params can be misused (see the massive numbers of articles in infobox tracking categories). If something can be misused in a template, it almost certainly will be. Soon we'd be seeing Swiss railway stations as PTEs in the infobox. The template can automatically have a switch for the 6 PTEs and change the label based on that automatically.

In my view these are the two best options from a technical standpoint, and accommodate for both the "no PTE" and the "PTE" viewpoints. Again, in both cases there is just one parameter (the PTE switch is entirely behind the scenes in the case of option 2). From a reader standpoint I personally prefer option 1, but the four of you know trains far better than I do so I defer to your expertise. ProcrastinatingReader (talk) 10:57, 12 August 2020 (UTC)

A few different versions in the sandbox (edit source and preview Template:Infobox station/testcases):

• Transit authority only: Special:Permalink/973191730
• Same as above, but as header not label: Special:Permalink/973188626
• Variable header: Special:Permalink/972406929, implementation Mackensen mentioned
• Variable label: Special:Permalink/973188540, slight adjustment of above

Thoughts? Any of these options desirable? ProcrastinatingReader (talk) 21:58, 15 August 2020 (UTC)

I can't see any examples using the formats at those links? Thryduulf (talk) 01:48, 1 September 2020 (UTC)

Gridref

discussion on gridrefs, plus Special:Diff/972003302 and Special:Diff/972148227, split from PTE section above. ProcrastinatingReader (talk) 13:49, 22 August 2020 (UTC)

What is the point of the grid reference? I get that in principle you could look it up on an OS map, but you could do that with the coordinates. What benefit does the grid reference provide? -mattbuck (Talk) 14:56, 10 August 2020 (UTC)

I already explained this. On an OS map, gridrefs are much easier to use than lat/long. --Redrose64 🌹 (talk) 17:44, 10 August 2020 (UTC)

I just don't see why that's helpful. If we really need conversion between grid refs and lat/long, is not the solution for the geohack page to calculate the grid reference? We also don't put the station's postal address in the infobox, nor the three words reference, despite both being ways to describe a location. -mattbuck (Talk) 15:59, 11 August 2020 (UTC)

The geohack page does display a grid ref, it's to one metre accuracy (which is perhaps misleadingly accurate). Here's how I use them. Let's say I'm writing an article for a closed station. I get an old OS map which shows the station, and then I use this method for obtaining the grid ref (to 100 metre accuracy, good enough for a station). Then I put it in the |gridref= parameter - job done. It's very easy, because all I need is a map and ruler - I don't need to make any calculations, or compensate for the difference between one degree of latitude being a greater linear measure than one degree of longitude. --Redrose64 🌹 (talk) 18:33, 11 August 2020 (UTC)

I'm glad it's easy to enter, but I still don't see what benefit it gives that the latitude and longitude don't already provide. I think coordinates are a lot more comprehensible than the grid reference. -mattbuck (Talk) 20:18, 11 August 2020 (UTC)

For many people, grid references are far more comprehensible than coordinates - especially given that the latter don't appear on paper maps. "NZ 318 037" to me is much easier to remember than "54.428550 -1.5102218" and would be very significantly easier for me to use to find that point using a paper map. Thryduulf (talk) 21:06, 11 August 2020 (UTC)

This is not a paper encyclopaedia. If you want to know where something is, click the link to take you to Bing Maps. -mattbuck (Talk) 06:21, 12 August 2020 (UTC)

What is the advantage to requiring people to click a link to be taken to another page where they will find what they are looking for in a sea of information they are not looking for (and knowing that they have to do this) vs presenting the information cleanly in a logical place right where they are looking? I cannot think of a single advantage to that approach, particularly as that information has been presented in the obvious way for many years. Remember we are supposed to be serving the reader not doing things solely for the convenience of editors and especially not for the convenience of template maintainers. Also your argument would apply equally to all location information other than coordinates. Thryduulf (talk) 09:27, 12 August 2020 (UTC)

@Mattbuck: You've got me the wrong way around. I'm not some tourist who is curious about something they've stumbled across when surfing the web. I write the station articles, for which I need to enter the position of the station. Accordingly, I find the station on a map, I work out the grid ref, I enter it. I have started dozens more articles for closed stations than open stations, and Bing is useless for a closed station where the site has been redeveloped. --Redrose64 🌹 (talk) 19:53, 12 August 2020 (UTC)

Redrose64, are you able to look it up using gridref as you do currently, then use some kind of site to find the coordinates? The display of gridref should really be useful for readers to be kept. ProcrastinatingReader (talk) 15:30, 24 August 2020 (UTC)

It is useful to readers who want to look up things on paper maps they have (e.g. to visit the site) or who understand grid references more than coordinates. I dealt with grid references every day in a former job and so could place a grid reference approximately within the area I dealt with (Somerset Levels) much easier than coordinates which we didn't use. Don't conflate your lack of understanding of the utility with a lack of utility. Thryduulf (talk) 01:46, 1 September 2020 (UTC)

It is also useful to readers who want to use the National Library of Scotland's NLoS Find maps by place repository of old OS maps: a grid ref takes you to the specific location whereas finding by name is fraught at times. --John Maynard Friedman (talk) 09:08, 1 September 2020 (UTC)

It seems a useful addition to the generic template in any case. My Garmin GPS receiver has British, Dutch, Hungarian, Estonian, Finnish, German, Icelandic, Indonesian (three), India (10), Irish, Latvian, MGRS, NZ, ONG, Swedish, SA, Swiss, Taiwan, US, UTM, Malaysian. --John Maynard Friedman (talk) 08:57, 1 September 2020 (UTC)

Thoughts Mattbuck & Mackensen? ProcrastinatingReader (talk) 18:51, 1 September 2020 (UTC)

ProcrastinatingReader, I still don't see the point personally, but if others want it then fine. -mattbuck (Talk) 20:57, 1 September 2020 (UTC)

Cleaning up GB station

I think gridref is the only remaining issue for {{Infobox GB station/sandbox}} (see testcases)? At least for a wrapper sync. May re-evaluate borough per above, but as I don't plan to make a bot run to replace yet the param isn't going anywhere. Participants: is there anything I've forgotten about?

Regarding gridref, really not sure what to do about it. My reading of the above discussion together with TfD puts it at a tossup, so I'd like more participation honestly, as I don't want to make any judgement on it myself. May ask at {{Infobox settlement}} for thoughts. ProcrastinatingReader (talk) 21:04, 19 September 2020 (UTC)

It looks like |gridref= is a "no consensus" above and at the TFD, which (I think) means that we include it in the wrapper as part of the status quo. If someone wants to start a separate discussion about it later, they can do so. – Jonesey95 (talk) 00:01, 20 September 2020 (UTC)

Implemented as params for generic regional grid references. Any remaining issues on {{Infobox GB station/sandbox}}? ProcrastinatingReader (talk) 15:55, 21 September 2020 (UTC)

{{Infobox UK heritage station}} should also be ready. ProcrastinatingReader (talk) 16:06, 21 September 2020 (UTC)

Synced {{Infobox GB station}}. Little more to do on the other two, mainly in terms of tracking categories and adding in a decade of passenger years to disused. Let me know if any issues crop up. ProcrastinatingReader (talk) 04:34, 28 September 2020 (UTC)

Where was this edit signed off as good to go? --Redrose64 🌹 (talk) 12:32, 28 September 2020 (UTC)

It obviously wasn't good to go as it removed functionality, see the template talk page. I have reverted that change until it is corrected. David Biddulph (talk) 09:17, 29 September 2020 (UTC)

To be clear, your complaint is A change on 28 September has apparently deleted some of the functionality, such as the links to "Live arrivals/departures, station information and onward connections from National Rail Enquiries"? This has been mentioned since the first of August in this discussion, Redrose requested clarification and afterwards raised no objections. It has been slated for removal since, for two months with no objections raised. When it was mentioned in the TfD, it was mentioned in the context of removal as non-infobox material. Indeed, it is not infobox material. The change made was entirely in process, with issues having been discussed for months, in the sandbox for months, and completion signalled above without response for a week. All parameter functionality has been implemented, and further functionality the WikiProject didn't even request, so I don't really know what the issue here is? ProcrastinatingReader (talk) 11:33, 29 September 2020 (UTC)

I see no mention in this discussion (between 1 August and now) of the proposed removal of that functionality. Perhaps you can give us a specific diff to the relevant part of the discussion? David Biddulph (talk) 12:19, 29 September 2020 (UTC)

I would’ve considered it part of the extra lists/text personally. If that was unclear, I did say above after signalling completion if Any remaining issues on {{Infobox GB station/sandbox}}? —- and no issues were raised. ProcrastinatingReader (talk) 14:12, 29 September 2020 (UTC)

Yes, I requested clarification, and the scanty answers that were forthcoming were in no way satisfactory.

I asked that no functionality be lost: but clearly, it has.

There are several reasons that I "raised no objections".

• Every time that I try to do so, I start editing a post, but get so angry about what is happening here that I back out without saving.
• Because you still have not provided satisfactory answers to my earlier questions (which I asked on at least three occasions) so I feel that until those are answered, there is little point in asking further questions.
• Because I feel that whatever I say, you will ignore me and push through your desired changes regardless. Clearly, since nobody other than you has agreed to the proposed changes, this is exactly what you intended would happen.

There, I've written it now, and am angry again; so block me for NPA. --Redrose64 🌹 (talk) 16:29, 29 September 2020 (UTC)

I’ve listened to all your issues and took them seriously, no concerns raised were dismissed. In fact, all visible concerns were implemented, as is visible from the checklist and discussions above. Of all the discussion above, only two things have not been implemented: the concern of Thryduulf that |native_name= is semantically problematic for search engines etc, and that param |borough= and |locale= should not be merged into one. As mentioned above, as I do not plan to do the bot run to replace yet, neither is relevant at this stage, as neither is visible through the wrapper. I disagree with native name and maybe agree with borough/locale, but am giving both more thought before replacement. No visual concerns from you or anyone else have been raised above that I’ve failed to address and implement —- they were all implemented. I went further and spent time preserving eg tracking cats, something nobody else raised but I figured it’d help the WikiProject’s maintenance.I cannot read minds, if you have further issues, say them and I will read them and respond to them. I have no issue in conversing with you. Yes, in this merge you’re both sometimes a bit difficult to work with: you both clearly strongly disagree with the merge outcome, here and elsewhere; I’ve tried to consider it as genuine concern and passion, and you cannot fault me for not trying and listening. And the pre and post merge boxes are remarkably similar, other than in ordering of labels, so I really don’t get your objections, but if you make it I’ll read it. This will be a lot more productive if you stop seeing me as the enemy of UK station info boxes and focus on achieving the best solution (which imv has been reached already, but if you disagree, say it, specifically). ProcrastinatingReader (talk) 17:05, 29 September 2020 (UTC)

You might have listed to all the issues raised, but there has been almost no evidence on this page of you responding to them or taking them into account. There are questions that have remained unanswered for nearly two months - perhaps you could start by answering them and then we can progress to other issues. I'm still not seeing any consensus among those who actually have a stake in the template (i.e. the users of the template - article writers and maintainers) that the merge is a benefit (let alone a net benefit). Thryduulf (talk) 23:00, 29 September 2020 (UTC)

I genuinely, really don't know what you want me to say or do here, Thryduulf. You already know that it isn't the place to relitigate the TfD, you know as a matter of fact the implementation is in line with the TfD nom and the close, and I've further addressed and implemented every visual concern raised here. If it were about "my desired changes" gridref would be scrapped, as I think it's extraneous, but it's implemented anyway. The current state of merge is exactly what was proposed at TfD, and also addresses the concerns here, thus this is fully supported by the large consensus at TfD. Again minus "Next station" information and A-Z station nav (which, btw, does not exist on {{Infobox London station}} either, which is claimed to be a superset below) it's near identical to the existing infobox, so I genuinely don't know what the fuss is here, and you're not clarifying your objections to help me understand.No, I'm not going to play 'have the last word' with you on every thread when it devolves into a relitigation of the TfD - it's frankly tiring. That isn't evidence that I've failed to address concerns, but there's proof to the contrary (ref last response). Besides, if you really don't think the TfD/merge is in line with consensus, as you raised yourself 2 months ago, you could've requested review at the appropriate venue, but you haven't - and trying to bring it up countless times (above/below/elsewhere) isn't helping anyone here. So, what do you expect from me here? ProcrastinatingReader (talk) 01:33, 30 September 2020 (UTC)

Well, in trying to thinking of a way forward, since you mention consensus, and as I'm truly lost on how to proceed in this scenario, I guess it's a good idea to allow consensus to determine the best way forward... ProcrastinatingReader (talk) 02:21, 30 September 2020 (UTC)

Request for review of implementation

Pinging all involved parties at the TfD, as well as those involved in the merge discussion above:

@Jonesey95, Mackensen, Cards84664, Redrose64, The joy of all things, Soumya-8974, AlgaeGraphix, Schlosser67, Thryduulf, WT79, Tholme, Izno, Dogru144, Trialpears, Mattbuck, and John Maynard Friedman:

Due to the deadlock above, your input is requested to find a way forward. Please, if you can spare the time, could you review the discussions on this page, the sandbox with merge implementation ({{Infobox GB station/sandbox}}), or if short on time just the three testcases at Template:Infobox GB station/testcases (which show the before and after). Does this merge meet requirements and may it be finalised? If not, what issues exist which should be addressed. Thank you, ProcrastinatingReader (talk) 02:21, 30 September 2020 (UTC)

I don't have any skin in this game, but I have a couple of technical comments.

• YI fixed some spacing in the passenger numbering, FWIW.
• YI think it would look nicer if the subheading "Interchange" could be indented a bit to indicate that it is a subheading of the year above (assuming that I am reading things correctly). I don't think the live template's dash looks right, but a bit of space to the left of the word would help.
• YIt looks like all of the fields in the test case examples appear in both the live template and the sandbox renderings. Are all of the possible parameters being used? If not, someone familiar with the template should comment on that, and ideally provide a link to an article where said parameter(s) is/are being used so that a new test case can be created.
• YDo we need to keep the sourcing that is provided by the asterisked note, per WP:V? It is currently missing from the sandbox. I think that the reference could be included in this template wrapper so that it does not have to be built into Infobox station.
• YMy recollection from the discussions above is that the "other name" header, or whatever the culturally sensitive name for it is (e.g. "Welsh: Trefforest") is supposed to be the same size as the main name header to show that the two languages are equivalent. If so, the sandbox appears to be an improvement over the live template. If my recollection or understanding of the discussion is incorrect, disregard this comment.
• NIf the loss of "Live arrivals/departures, station information and onward connections from National Rail Enquiries" is a show-stopper, it can probably be inserted in this wrapper in the interest of completing this process, and then discussed at a later date. Same with the A–Z listing of stations.

That's all I can see at the moment. – Jonesey95 (talk) 03:02, 30 September 2020 (UTC)

(edit conflict)Thanks, Jonesey95, for the helpful input and fix. For the record, I should note now that this will not stay a wrapper, per the TfD discussion & in line with past merges (linked in header), so I'm not sure wrapper-specific suggestions will work (+ also cause inconsistency). And for clarity, so I don't need to ping everyone again, "finalising the merge" in this discussion should be considered to include if the IB is ready for full replacement via bot run. Regarding some specific points:

• Good point on the spacing for interchange (I will add that).
• Good note on if all parameters being used - I am pretty sure all are (except imagesize, which is deprecated and only used on 2-3 GB station articles, and logo with 0 usages). The coincidence that they're all used is just due to the level of overlap I think.
• Regarding the asterisk, I'm not sure we do it for any other station infobox with passenger numbers, and I think it's distract-y in the infobox/header. If it's really required for WP:V, we should figure out a neater way to address it I think. Others will know more about this than me. WP:INFOBOXREF and WP:MINREF may also be relevant. I don't think it's required, personally, per MINREF: if an article contains none of these four types of material it is not required by any policy to name any sources at all.
• Re live arrivals/departures, and the A-Z, per TfD & Misplaced Pages:Manual_of_Style/Infoboxes#Consistency_between_infoboxes + Misplaced Pages:Manual_of_Style/Infoboxes#General_design_considerations.

My view is that the merge is to standardise GB stations into {{Infobox station}}, rather than giving it special exemptions and separate look/feel to everything else (maintainability, design, unnecessary inconsistency concerns). That functionality should've been removed from {{Infobox GB station}} before this merge imo, and should not be merged into here. If it really is to be merged in, it must be possible for any other world station to use it, so we'd need agreement that "infoboxes linking to timetable information on local station/government sites" is okay. ProcrastinatingReader (talk) 03:57, 30 September 2020 (UTC)

Keeping the template as a wrapper may be the best way to get most or all of the RFC consensus. Sometimes a full merge ends up being infeasible (or some editors essentially veto it, blocking all change). – Jonesey95 (talk) 16:07, 1 October 2020 (UTC)

Jonesey95, I think that view is from a diplomatic angle. In that sense I'd agree with you, if I were exploring ways to do something in a contentious area and it was my only option. But as a TfD (which listed clearly the transitioning functionality) has already found consensus to do a full merge, and as we've done this before on every other regional template (far more complex ones than this), I strongly oppose the idea. The point of merge was harmonisation, for various reasons documented at MOS:INFOBOXES, a wrapper for these points fails that totally. As you know, as you have technical experience with templates, we've encountered no technical infeasibility here - what was said in the TfD has been done with ease. I mean, honestly, we're talking about all passthru parameters here.I remain open to discussion on whether {{Infobox station}} should start showing timetable links (I oppose personally, but as always I will go with consensus), but if it's to be done it must be supported globally, for all train stations articles. No logical reason exists why only GB ones should show timetable links. But I am strongly opposed to cancelling or altering a consensus found by a diverse group of editors to merge, if the only reason for it is because some editors remain closed to the idea of one. FWIW, (I believe, may be wrong) the only grounds to change this would be via DRV and I think solely on grounds of newly discovered technical concerns. ProcrastinatingReader (talk) 18:45, 1 October 2020 (UTC)

You're making me angry again, so I will keep this short. I cannot agree to any "full merge" outcome, it would be far too disruptive. If the process cannot be aborted, a wrapper is the only feasible way of allowing a smooth transition. Let me ask you this: when creating articles about railway stations in the UK, or amending existing ones, how often do you add an infobox, or alter the input parameters of an existing infobox? --Redrose64 🌹 (talk) 22:32, 1 October 2020 (UTC)

I don't quite follow. {{Infobox station}} allows modification of parameters in the same way? ProcrastinatingReader (talk) 22:58, 1 October 2020 (UTC)

I'm asking about you, as an individual. Have you ever edited an article about a railway station in the UK? If so, did you change something in the infobox? Please give examples. --Redrose64 🌹 (talk) 20:09, 3 October 2020 (UTC)

Redrose64, I am sorry that you are feeling anger. I know how difficult it can be when it feels like people are just not listening. I'm not saying that I agree that people are not listening, but I have been there and acknowledge your feelings.

I have updated the sandbox to include an in-line reference for the passenger data (as suggested by Cards84664 below), and I have linked the term "Grid reference" (also suggested by Cards84664). I have indented the label "Interchange" as I recommended above.

Setting aside the process for a moment if you are able, are there any specific objections that you have to the current infobox examples on the testcases page? I believe that all of the issues that have been raised have been addressed. If they have not, please be specific about what still needs to be done. If there are no further objections to the code in the sandbox, we can move it to the live template. Having this template as a wrapper of Infobox station will improve consistency and should make editing easier for editors who edit railway station articles covering multiple countries. – Jonesey95 (talk) 01:19, 2 October 2020 (UTC)

(edit conflict) As a supplement to Jonesey95's comments, I will add:

The listing of live departures, station information, and onward connections are not "functionality" in regards to regular content being hosted on Misplaced Pages. The current inclusion of these links acts as a travel guide that changes on a day-to-day basis, and has no necessary purpose in an encyclopedia. As such, these links would be better suited for use on WikiVoyage. The exception to this policy is the use of passenger statistics, as they are permanent statistics, they can be cited in articles reliably. Next, while Gridref acts as a redundancy to the use of coordinates, it is a unique system that holds historical significance in Great Britain. One thing I have noticed is that the instance of "Grid reference" in the sandbox parameter should have its bluelink restored. This remains necessary as to inform new readers at minimum of why Gridref remains relevant as a feature of the infobox. Third, the removal of the station lists from the footer of the infobox is justified, as the functionality has long since been redundant to the navboxes of the stations. An example of this is the template of Cardiff, Newport and the Valleys. Lastly, the caption of "Annual estimated passenger usage" should be retained as a citation, inline with the Passengers header. This way, the infobox will not be bloated with the specific explanation. With the suggestions I have made above, I will Support the implementation of the sandbox. I will also note that I previously and impulsively attempted to rush this process through, and I apologize for doing so. Cards84664 03:55, 30 September 2020 (UTC)

As far as I am concerned, it would be sufficient if there was a single infobox template for the UK railway stations. Likewise, there may be reasons for country-specific templates for other countries (one for each), as there may be some information that applies to one or a few, but not to the others. For instance, you've got the company that operates the station, or the OS grid square (rather useful in the field), which are both UK specific information and unlikely to be relevant in, say, Germany. In Germany, however, there is the station class as specified by DB AG, something that does not apply elsewhere. I'm sure there are things specific to other countries. If someone manages to herd all these cats (pun intended) into one big template, I won't complain, but I fear that it will become rather unwieldy. Let's sort it out at the country level first. - PS: I see that you've done a good job with the three test cases. There seem to be more similarities across country borders than I expected. Still, there may need to be some provision for closed and heritage stations. --Schlosser67 (talk) 05:57, 30 September 2020 (UTC)

One of my principal concerns is the problem created when someone has put incorrect information in the space dedicated to historic train companies using the station and the so-called adjacent railroad station. I have seen many instances in which incorrect info has been put in for the next station, and it's impossible to edit the box to correct the error with information from train company references. Any new format must preserve the capacity for the infobox to be edited.Dogru144 (talk) 23:45, 30 September 2020 (UTC)

Interesting comparison. I am glad that the section previously labelled Traffic has been changed to Passengers, as, I think, traffic is an awful way to describe human beings (personal opinion). I do feel that Transit Authority is clunky, but in essence, I cannot see the major difference between the two, so no objections. I do thank you for your efforts and taking everyone's opinions and thoughts with policy into account can't be easy. Regards. The joy of all things (talk) 15:52, 1 October 2020 (UTC)

Dogru144, can you please provide an example of an article that illustrates the problem you describe? Does this problem exist in the live template, or the sandbox, both, or neither? – Jonesey95 (talk) 16:05, 1 October 2020 (UTC)

Jonesey95, thank you for bringing this up. The following is the last that came to mind, in the context of an infobox that had wrong information on adjacent stations: still-surviving stations along the NYC's West Shore Railroad stations. For example, see Highland Falls station on that route. It was possible to correct the stations that are north and south of the station. However, if there was the desire to correct information about the final destination to the north or the south, or to edit the division name, that is not possible at this article. That ability is locked elsewhere from the infobox at the above cited article. An additional problem exists with one of the options for infoboxes for train route maps. On many articles it is not possible to edit the infobox to make additions or corrections to those infoboxes.Dogru144 (talk) 21:34, 6 October 2020 (UTC)

Overall, it would be of great help if there were an easy to find page giving a tutorial on how to make these sorts of edits.Dogru144 (talk) 21:37, 6 October 2020 (UTC)

Dogru144: It sounds like you have an issue with {{Infobox station}} that should be moved to a separate talk page thread. This discussion is about the in-progress merge of {{Infobox GB station}} with this one. – Jonesey95 (talk) 01:42, 7 October 2020 (UTC)

Looking at the test cases I note the following issues with the merged template:

1. "Classification" is a less useful header than "DfT Category".
2. "Other information" listing an unsorted mix of information about the mainline station and tram station is confusing and badly presented. This is especially the case when the fare zone is just an unlinked number. For stations like Wimbledon in multiple zones (zone 3 for rail and tram zone for trams) this is likely even worse.
3. Nothing in the "Passengers" section makes it clear this is only related to the mainline station
4. The "Criteria" heading is misleading - it lists what is listed not why it is listed.
5. Why are "key dates" not part of "history"?
6. The note for passenger usage isn't working properly - it includes the unsubstitued parameter "{{{name}}}" (although this is conceivably a test-cases only problem)

Points 2 and 3 must be corrected before this goes live (if it absolutely must go live), the others do mean the template is inferior to the existing one but are less significant. It is telling that after months of development we still have something that is inferior to the existing template and has not demonstrated any of the advantages claimed a merge would bring - indeed the "simplicity" and "ease of maintenance" claims could have been written on the side of a bus for all they relate to the real world. Thryduulf (talk) 10:33, 2 October 2020 (UTC)

Good note on (4). Looking at other articles with designations (eg The Cenotaph), they don't include the criteria. So, I must ask, do we really need it in the infobox? If you want it we can easily use a custom label, but just saying, it feels a bit extraneous and {{Infobox designation list}} appears not to natively support it for probably that reason. Re (6), I think is probably a bug (Jonesey95?). Re (2) I don't follow, could you link an article where this becomes a problem? ProcrastinatingReader (talk) 14:46, 2 October 2020 (UTC)

Thank you for these detailed comments! I have adjusted the display to fix item 1.

For #3 (Passengers), can you please give an example or link to an article where this concern is relevant? {{Infobox station}} appears to show only a Passengers section for thousands of stations around the world; how are UK stations different?

For #4: the sandbox uses {{Infobox designation list}}, which is missing the "Feature" label that appears in the current Infobox GB station. The sandbox has mapped the Feature to the "Criteria" label, which does not seem ideal. I don't immediately see an easy way to make a "Feature" label appear, but I recognize that "Criteria" does not seem like the right label. Infobox designation list and {{Infobox historic site}} appear to assume that the name at the very top of the parent infobox is the name of the Feature, so they omit it, but that may not be the case with railway stations. This might need some research to see how other countries' stations handle this situation.

Re #5 Key dates, see the comment Please do not move "Opened" to 'the proper opened param', we have been trying to go the opposite way for some time above, where there was a request not to move dates to the History section.

Re #6, the note showing {name}, I have fixed that. A version of the problem exists in the current template (if |name= is not provided, the note will show a blank space).

I think that leaves items 2, 3, and 4 unresolved; please provide examples for items 2 and 3. Thanks! – Jonesey95 (talk) 15:23, 2 October 2020 (UTC)

Thryduulf: Update: I have used a different method to address item #4, the historic listing, copied from {{Infobox historic site}}, a widely used template that applies color coding for historic buildings. Does the historic test case look more reasonable now? We can change the labels; I chose the ones used in Infobox historic site for consistency with other historic site pages. – Jonesey95 (talk) 15:48, 2 October 2020 (UTC)

Jonesey95, creating a custom nested infobox in that way is not consistent/maintainable. It's effectively creating a fork due to 1 param. |feature= can be added to {{Infobox designation list}}, or one of the blank params can be used, ie |designation1_free1name= ProcrastinatingReader (talk) 16:16, 2 October 2020 (UTC)

@Jonesey95: Responses below for ease of reference:

1. "Classification: DfT Category A" is better than "Classification: A" but not as good as simply "DfT Category: A" would be. Not a major problem but still less good than what is there now.
2. Examples are right there on the Manchester Piccadilly test case. The station code relates to the mainline station (tram stations may have the same code, a different code or no code - I don't know); the fare zone relates to local transport (primarily trams in these instances) and with no links or other context is meaningless; the classification relates to only the mainline rail station and takes no account of and is irrelevant to anything else. This will also be an issue at every other station served by Network Rail and some other transport (tram, heritage railway, light rail, London Underground, etc)
3. Again see the Manchester Piccadilly test case. The existing heading "Annual rail passenger usage" makes it clear that it counts mainline passengers only, not tram passengers. The new heading "Passengers" implies that it is all passengers (rail and tram) using the station when this is not the case. Like #2 this is an issue that will apply at every station served by multiple modes.
4. This is now resolved, at least in the test cases. There is a possibility that if the entire station is listed just by name (e.g. "Wemyss Bay railway station") that is might be slightly confusing. I don't see that as a major issue, but get other opinions before rolling it out as others may disagree.
5. Hmm, ok.
6. I agree this is resolved, thank you. Thryduulf (talk) 17:09, 2 October 2020 (UTC)

   Mattbuck thoughts on 2 & 3? ProcrastinatingReader (talk) 18:53, 2 October 2020 (UTC)

   I don't know about Manchester, but certainly the codes that LU uses for stations are totally unrelated to the Network Rail ones. London Bridge station is LBG in NR parlance, but to LU it's N/113 (or something, I'm not at work so don't have the map right now). Similarly the numbers of passengers would be different - while there would be crossover, a lot of people would change at London Bridge LU without ever coming above ground, and LU certainly produces different usage statistics.

   Like many others, I fail to see a benefit from this. I don't mean to impugn your work, but nothing here will actually make things better than they are right now for readers. -mattbuck (Talk) 19:44, 2 October 2020 (UTC)

   Hmm, okay. So I took a look at other train station articles (eg Union Station (Los Angeles)), looks like |system= in {{Rail pass box}} is intended for issue #3, so I think that should fix that. We can also see how Union Station splits between Amtrak/Metrolink there, for reference, and considering some other articles along these lines may help us resolve #2. Other world stations must be dealing with #2 somehow (and if they're not, that's a problem that should be fixed) ProcrastinatingReader (talk) 20:58, 2 October 2020 (UTC)

   Thryduulf isn't #2 a problem with the live template, too? e.g. the page I linked specifies "Amtrak code" to 'fix' it, but that's a per-article thing. It's a problem, but is this merge compounding it? ProcrastinatingReader (talk) 22:58, 2 October 2020 (UTC)

   @ProcrastinatingReader: #2 is not a problem with the live template because the information about the mainline station is in one part of the template where context makes it clear it's about the mainline station, and information about the trams are in a separate section where context makes clear it's about the tram station. The only exception is the number of platforms, which are explicitly annotated to make things clear. Thryduulf (talk) 14:57, 3 October 2020 (UTC)

   Thryduulf, not ignoring you btw, just thinking. It's a bit of an inferred point, in that the grouping of params would infer that it's the mainline station only, but it isn't meritless. The general way to deal with this, when one station infobox/building is housing multiple systems, is usage of the params mentioned + |type= and notes where appropriate. e.g. at Union Station (Los Angeles) (which is a textbook case on how to deal with all such issues).But I note that the Manchester system has a separate infobox for the Metrolink system (Manchester_Piccadilly_station#Piccadilly_tram_stop), so I think this particular issue (for both Metrolink and T&W Metro overlaps) is resolved with eg |type=National Rail station on the main infobox (see User:ProcrastinatingReader/sandbox). Do you have an example of a station where a separate infobox isn't used for the other system, so I can see what cases would remain unresolved with this method? ProcrastinatingReader (talk) 13:09, 11 October 2020 (UTC)

Mapframe

Following the RfC I raise the matter of opt-in mapframes in this infobox. This was previously raised in 2018. Also pinging Evad37 for thoughts and implementation. ProcrastinatingReader (talk) 17:39, 3 September 2020 (UTC)

@ProcrastinatingReader: Implementation is relatively easy, see this diff to Template:Infobox station/sandbox2 (done there since /sandbox seems to be in use for the UK merge). Placement is a matter for local consensus per the RfC – I've put it at the bottom of /sandbox2 since that's where the location map is currently positioned. Documentation can be added just be transcluding {{Infobox mapframe/doc/parameters}} on the /doc page. - Evad37  01:34, 5 September 2020 (UTC)

@Jts1882: in case you miss this. We discussed this recently, looks like there may be momentum now. As you observed, there are many minor stations that have no maps at all and this would be an instant bonus for minimum effort. --John Maynard Friedman (talk) 10:03, 5 September 2020 (UTC)

I think there is no reason not to include mapframe maps as an option, with the default as no (don't show). An issue to discuss is whether the default should be yes (show mapfrane map) if there is no other map. —  Jts1882 | talk  10:31, 5 September 2020 (UTC)

Best take it one step at a time to avoid getting no steps at all. It should be easy to get consensus to add mapframe, initially set to off. Making it default to 'on' will take a longer discussion while editors search for special cases. So I support addition of mapframe. --John Maynard Friedman (talk) 12:52, 5 September 2020 (UTC)

I don't believe local consensus is needed to add, due to the wider consensus in the RfC. Just needs local consensus on where to place it. I'd say logically where the current map is now, at the bottom, makes sense. ProcrastinatingReader (talk) 16:02, 5 September 2020 (UTC)

Yes, I agree (to both). --John Maynard Friedman (talk) 17:07, 5 September 2020 (UTC)

Implemented at the bottom, where the current map is. Parameters added to doc. With thanks to Evad37 for implementation. ProcrastinatingReader (talk) 11:47, 10 September 2020 (UTC)

Thanks for implementing this! Can we set the default marker to be "rail"? I have it set that way at Ossining station and Scarborough station. Can always be set to "bus" for bus stations, likely a small minority. ɱ (talk) 13:56, 12 September 2020 (UTC)

Hmm. My personal thoughts: it'd be okay to do that now, since they have to be manually added, but it would create a big barrier if we wanted to enable mapframes by default. And since they have to be manually enabled currently anyway, I don't see it being too helpful to do it in the template automatically vs just adding advice on this into the docs. If we had some kind of way to tell which is bus and which isn't it (eg |station_type=) this would work better. ProcrastinatingReader (talk) 16:24, 12 September 2020 (UTC)

As far as docs go, if we go the 'not setting defaults for all stations' route, I wonder if we can create some sensible defaults, without suggesting explicit usage of mapframe params. Like, if we had |mapframe_type= (value: railway, for ex), and this implements a set of sensible defaults for mapframes. Big advantage to this over suggesting individually recommended mapframe param values is (a) less params required, (b) more friendly for most editors, (c) we can adjust defaults in template easily if need be, vs having to use a bot which wouldn't be able to tell which are 'defaults' and which are intentionally set differently. Thoughts, and ideas on how to best technically achieve this, Evad37? ProcrastinatingReader (talk) 16:28, 12 September 2020 (UTC)

On detecting station type this could be done via Wikidata, e.g. looking for instance of (p31) bus station (Q494829), railway station (Q55488), underground railway station (Q55491), London underground station (Q14562709) or combination thereof. A simple template or module could provide the symbol to pass to mapframe. There might be a case for something more general to pick symbols for buildings, stadia and other locations. —  Jts1882 | talk  16:48, 12 September 2020 (UTC)

Unless this conversation develops more (which it seems it might not?), can we go with the default for rail (likely the vast majority of uses)? It always has the option to change it out for "bus" anyhow. Unless someone can commit to some Wikidata-based solution? ɱ (talk) 02:25, 23 September 2020 (UTC)

This code should automatically pick an appropriate symbol based on the Wikidata P31 value - Evad37  03:03, 23 September 2020 (UTC)

OK, neat. How would I utilize that in an infobox? Is it automatic? I tried at Scarborough station (Metro-North), even previewed as the "/sandbox" template and the icon won't display for me. ɱ (talk) 11:01, 23 September 2020 (UTC)

You need to preview with the /sandbox2 template. And the page's wikidata item needs to have P31 set to one of the Q values duscussed above - Evad37  12:07, 23 September 2020 (UTC)

Right, looks good, thanks. I'm in support of implementing this solution. ɱ (talk) 13:36, 23 September 2020 (UTC)

Can we do this? No problems with Evad's solution here? ɱ (talk) 22:00, 26 September 2020 (UTC)

Looks fine to me. We may want some kind of parameter so that local articles can override, if for some reason the Wikidata value isn't correct/desired. But I suppose manually supplying |mapframe-marker= would do that, and be prioritised by the module? ProcrastinatingReader (talk) 23:03, 26 September 2020 (UTC)

Yes, mapframe-marker can work for any instance of overriding the default marker. ɱ (talk) 23:08, 26 September 2020 (UTC)

Seems fine to me then. I think this is safe to implement, with seemingly a rough consensus in favour. ProcrastinatingReader (talk) 23:57, 26 September 2020 (UTC)

 Done - Evad37  14:00, 1 October 2020 (UTC)

Evad37, I'm not sure it's working? Or I'm doing it wrong. See Union Station (Los Angeles) (which uses |map_locator= manually). Change to |mapframe=yes and no marker shows. On Wikidata it's an instance of railway station. I'm guessing it may be due to multiple values? ProcrastinatingReader (talk) 21:10, 2 October 2020 (UTC)

(←) yeah I tested it without 'tram stop' and it works. Evad might know a way to make it work without the removal... ɱ (talk) 21:20, 2 October 2020 (UTC)

The code only shows a default value when there is a single P31 value on wikidata. Not sure what you would expect to happen when there are multiple values, other than letting editors specify which (if any) marker icon to use via the parameter - Evad37  05:22, 3 October 2020 (UTC)

Evad37, many times the second value in 'instance of' has nothing to do with what 'type' of railway it has (eg ). For multiple values, I think it should match the first in the current ordering of the switch template. ProcrastinatingReader (talk) 14:48, 3 October 2020 (UTC)

Agreed that if it can be set to match the first entry in 'instance of' that should work. Even if a station is used for two or more types of transit vehicles, the first should still be the predominant usage. ɱ (talk) 14:55, 3 October 2020 (UTC)

 Done - Evad37  08:45, 5 October 2020 (UTC)

Evad37, by the way, is there an easy way to add the stuff in {{Infobox mapframe/doc/parameters}} to the TemplateData? Like a TD version that can be transcluded/kept in sync, or something. ProcrastinatingReader (talk) 19:29, 12 October 2020 (UTC)

I'm not sure if it as actually possible to transclude bits and pieces within a templatedata block, could be something interesting to try. It's possible to keep a copy of the TD for the mapframe parameters for easy copy-paste, much like the parameters list for the Check for unknown parameters. But there's no shortcuts just yet, because for with way it would need to be set up manually initially. - Evad37  22:33, 12 October 2020 (UTC)

Evad37, copy and paste works fine, too, if that's the best method. Is there one set up somewhere already, to paste from? ProcrastinatingReader (talk) 22:57, 12 October 2020 (UTC)

Not yet, as far as I am aware - Evad37  00:20, 13 October 2020 (UTC)

@ProcrastinatingReader: Now done at Template:Infobox mapframe/doc/templatedata - Evad37  01:28, 14 October 2020 (UTC)

Merger proposal

I propose to merge Infobox London Station into Infobox station. I think that the content in the London station template can easily be replicated in infobox station just like the move of Infobox GB station into Infobox station. Smithr32 (talk) 20:33, 26 September 2020 (UTC)

I'm not sure it should be merged. The biggest difference is the multiple sets of passenger figures under different headings. I am not sure how to smoothly implement that, whilst retaining generality for use in other stations, and also preventing misuse of the generality. Unless a good proposal to get around that is found, I do not think it's likely to be a good merge. ProcrastinatingReader (talk) 21:26, 26 September 2020 (UTC)

We should still hold on with London station, it is a situation similar to New York City Subway station. Both should be scrutinized before any mergers are put forward. Cards84664 23:45, 26 September 2020 (UTC)

It would have been better to merge {{Infobox GB station}} into {{Infobox London station}} because the latter is, by and large, a superset of the former - only a few features of GB station are not provided by London station. --Redrose64 🌹 (talk) 20:55, 27 September 2020 (UTC)

New(?) Passengers section

Could someone please fix the extra space below the header? It is particularly wider than the other ones. Thanks! --truflip99 (talk) 19:55, 10 October 2020 (UTC)

Truflip99, do you know roughly when this issue started to appear, by any chance? Technically, it's caused by a blank <tr> being dumped. I'm not entirely sure why it's being dumped. I tried show preview with old versions of Template:Infobox station and Template:Rail pass box and the issue still appears. ProcrastinatingReader (talk) 13:12, 11 October 2020 (UTC)

@ProcrastinatingReader: no clue... The last time I worked on an article with it was around August and I'm confident it wasn't an issue then. Certainly recent. truflip99 (talk) 18:06, 11 October 2020 (UTC)

Parameter deprecation

Designations

Per Template:Infobox_station#Embedding_other_infoboxes designations are meant to be embedded in |embedded=. A legacy param remains where |nrhp= is being misused in templates to replace core functionality. Page list. Examples: Washington Union Station, Philipse Manor station, Portland Union Station, South Orange station, Orange station (NJ Transit). The whole infobox is embedded to chuck in a map / extra map (rather than use this IB's map), repeat params (like address, coordinates, etc see Portland Union example). It's a mess. The param shouldn't really exist anyway, since designations are embedded into the embedded param. Proposing removal of the param, and a bot run to convert usages into proper designations, move maps / other relevant, provided non-duplicated info to this infobox, and retain only the standard set of designation parameters. ProcrastinatingReader (talk) 17:24, 12 October 2020 (UTC)

In what way is |nrhp= a "legacy" parameter? As far as I can tell, it has not been documented, but it has been in the template since 2009 and is widely used (|embedded= was added as an alias for nrhp in 2011 and then immediately separated into its own row). I don't see any discussion in the talk page archives, so there is no way to know whether one parameter is supposed to be preferred, or whether they have separate purposes. Maybe |nrhp= just needs to be documented. – Jonesey95 (talk) 19:06, 12 October 2020 (UTC)

I don't follow this at all. {{infobox NRHP}} is a whole separate infobox which is being validly embedded to include the relevant info about the property being listed on the National Register of Historic Places. This is done with many other infoboxes including {{Infobox lighthouse}}, {{building}}, etc. It includes the date added to the register, the refnum, architectural style, etc - info not included in the station infobox. I agree that duplicated info (e.g. address) should be removed. That calls for cleanup of the usage, not removal. MB 19:09, 12 October 2020 (UTC)

Removal of the parameter name, not of its value. Its supported purpose in this template, as far as I can tell, is designation, similar to {{Infobox designation list}} (which supports this exact functionality anyway...). That purpose is fine, but I can't see why it should be used as an actual embedded infobox almost the size of the main station one itself, or why it needs its own parameter rather than utilising |embedded=, like the other designations use. Aesthetically it looks weird, long & bloat-y. ProcrastinatingReader (talk) 19:31, 12 October 2020 (UTC)

Considering this a bit deeper, I think I'd like to split up |embedded= into a separate |designation= as well. It will also allow us to see non-designation usages of the parameter more clearly, and identify what non-designations are being embedded (helpful to realise if there's anything we should add as core functionality). A bot run can detect designation usages and replace parameter names (there are active 'deprecation bots', and this would be in scope I think). Both |designation= and |embedded= would be supported. Regarding |nhrp=, it should be folded into |designation=. Functionally, I think we should drop support for {{Infobox NRHP}} embedding and simply encourage {{Infobox designation list}}. It handles the same designation functionality of the former, and we don't want any of the excess fields. Noting that most usages are in excess, and either duplicate information or add bloated information, I think a bot run to trim/replace with {{Infobox designation list}} would be appropriate. No valuable information is lost, of course. Mapping will be folded into {{Infobox station}}.See User:ProcrastinatingReader/sandbox#Re_NRHP for a preliminary demo of what I mean (before/after). Location, coordinates, area should all go. The question remains on the labels "Architect", "Architectural style" and "Built". As you can see from Template:Infobox_designation_list#Embedding, the logic is to usually have these as part of the core infobox. They have little to do with the designation, and as such aren't natively supported by {{Infobox designation list}} either. I don't care too much about which option is taken w.r.t. these 3 params (blank fields/core implementation, vs removal), as that part is where this goes from routine cleanup to a content decision, but I do think they fail MOS:INFOBOXPURPOSE in relation to this template (and certainly in relation to a mere designation, solely a component of this template, which should really not be the length of this template itself). ProcrastinatingReader (talk) 12:16, 13 October 2020 (UTC)

Korean name

It's been sitting in the deprecation / slated for removal part of the doc for a while. Meanwhile, we're suggesting/recommending its usage in the very first example. So it's not really deprecated. Do we either want to move it out of the deprecation part, or do a bot run to convert the parameters on used articles under |mlanguage= (which seems to be the 'preferred' way of doing things. Visually no difference. I personally think converting to |mlanguage= is more logical, given also that's how Chinese names / other countries are currently doing it (see eg Kam Sheung Road station). ProcrastinatingReader (talk) 17:31, 12 October 2020 (UTC)

ProcrastinatingReader, I was just looking at Korean name because of the formatting issue at Gyulhyeon station. I'd worked up a change in my userpage (User:Mackensen/Infobox station) to suppress the header on the included child infobox and have Infobox station set its own. There's a similar formatting issue visible in your example. Mackensen (talk) 11:48, 14 October 2020 (UTC)

Mackensen, good catch. Yes, I think your fix resolves the issue for Korean stations. It won't fix the issue for Kam Sheung Road station though, since that uses {{Infobox Chinese/Chinese}}. Note also that both the Chinese and Korean templates are wrappers around {{Infobox Chinese/Header}} (which may help?) ProcrastinatingReader (talk) 12:46, 14 October 2020 (UTC)

ProcrastinatingReader, yes, for that I think we need an mlanguage_header parameter for infobox station, and then encourage a default usage of the child infoboxes that suppresses the header.

On your original question, I think it would make sense to formally deprecate the Korean parameters in favor of mlanguage, once the header is available and we have better documentation. Mackensen (talk) 13:00, 14 October 2020 (UTC)

Mackensen, hmm, we also don't want local articles to have to write |mlanguage_header=Korean name (or Chinese, etc) all the time. We could perhaps add that param with fallback automatic detection by checking the parameter value for "Infobox Korean name"/"Infobox Chinese name", etc, and giving a header based on that. But it's may be a little ugly (code-wise). We could also ask that template to add in a headerstyle param, and pass through our headerstyle (this duplicates code, but achieves the same effect), assuming they think it's appropriate to add that may fix our issue also. There may be other, better ideas. ProcrastinatingReader (talk) 13:10, 14 October 2020 (UTC)

ProcrastinatingReader, I looked into passing the header style, and I don't think it's a sustainable approach. You could have a default mlanguage_header of "Native name", with the Native part overridable. Mackensen (talk) 14:27, 14 October 2020 (UTC)

Mackensen, ah. Before throwing the towel in on the automatic part, I have an idea to simplify the 1st suggestion above. See Module:Sandbox/ProcrastinatingReader/ib. Basically, using a !regex capture group (the (%a*) part), whose value will be "Chinese", "Korean", etc., and just returning that part. If it exists, great, if not, default to "native name". It would be invoked with {{#invoke:Sandbox/ProcrastinatingReader/ib|nativeName|{{{mlanguage|}}}}}. At Kam Sheung Road station for example, the value of |mlanguage= is {{Infobox Chinese/Chinese|t=錦上路|s=锦上路|l=Brocade road|y=Gámséuhnglouh|j=Gam2soeng5lou6|p=Jǐnshànglù|showflag=y|}}. So it works in the debug console with that exact string value. Issue is, and I've ran into this once before, the template code is already parsed by the time it hits the module, so the module doesn't see "Infobox Chinese/Chinese", it sees the substitution of it. The result is my code returns "" rather than "Chinese".I've ran into this issue once before with modules, it's a slight pain... Pinging Jackmcbarn, is there any way to get the pre-parse value of the parameter? Or another way to achieve what I'm trying to do? At the same time, this may be an XY problem -- surely there's an easier way to get an embedded child infobox to obey the header style of the parent infobox? ProcrastinatingReader (talk) 14:57, 14 October 2020 (UTC)

@ProcrastinatingReader: is there any way to get the pre-parse value of the parameter? No. I submitted a PR for this functionality once, and the Parsoid team rejected it, because it would make things too confusing for people who edit with VE. Or another way to achieve what I'm trying to do? Perhaps you could instead add a marker class to something in the output of {{Infobox Chinese/Chinese}}, and search for that marker class with Lua. Your other option is to have this module call {{Infobox Chinese/Chinese}} itself (by taking its name), instead of doing so within a parameter. Jackmcbarn (talk) 19:10, 14 October 2020 (UTC)

Jackmcbarn, re the other option, we don't actually know what language template is being embedded. This template just offers |mlanguage=. There's a lot of possible templates which can be used, even if we support this set natively if there's another set it'd break support for that (if there's not, yeah, we could do this too I guess). But, shouldn't {{Infobox}} provide better support for inheriting header styling when an infobox is being embedded? Or at least add a class or something so we can force it with TemplateStyles. Or some way to do this easier, without even having to consider what particular IB is being embedded? ProcrastinatingReader (talk) 19:22, 14 October 2020 (UTC)

Re the patch, was/is there an issue ID for it that we can comment on? I've a few other use cases that would benefit from something like this. Also seems like Parsoid team has changed, so might have better luck with it now? ProcrastinatingReader (talk) 19:25, 14 October 2020 (UTC)

@ProcrastinatingReader: No, there was never an issue about it, but you could make one and then link it to my old PR. As for my alternative idea, I didn't mean hardcoding a list; I meant doing something like {{Infobox station|template name=Infobox Chinese/Chinese}}, and then inside that, doing {{ {{{template name}}}}} to use it, and then also using the name for what you wanted to use it for. Jackmcbarn (talk) 22:58, 14 October 2020 (UTC)

• Template-Class rail transport pages
• NA-importance rail transport pages
• Template-Class Stations pages
• WikiProject Stations articles
• All WikiProject Trains pages