Wikipedia talk:WikiProject Aircraft/Archive 7

WikiProject Aircraft talk — Archives

pre-2004  [ General | Strategy | Table History | Aircraft lists | Table Standards | Other Tables | Footer | Airbox | Series ]
2004  [ Mar–Aug | Aug ] — 2005  [ Mar | May | July | Aug | Oct ] — 2006  [ Feb | Mar | May | Jun | Aug | Oct | Nov–Dec ]
2007  [ Jan–May | Jun–Oct | Nov–Dec ] — 2008  [ Jan | Feb–Apr | Apr–July | July–Sept | Sept–Dec ] — 2009  [ Jan–July | Aug–Oct | Oct–Dec ]
2010  [ Jan–March | April–June | June–Aug | Sept–Dec ] — 2011  [ Jan–April | May–Aug | Sept-Dec ] — 2012  [ Jan-July | July-Dec ]
2013  [ Jan-July | July-Dec ] — 2014  [ Jan-July | July-Dec ] — 2015  [ Jan-July | Aug-Dec ] — 2016  [ Jan-Dec ] — 2017  [ Jan-Dec ]
2018  [ Jan-Dec ] — 2019  [ Jan-May | June–Dec ] — 2020  [ Jan-Dec ] — 2021-2023  [ Jan-June 21 | June 21-March 23 | March 23-Nov 23 ]

Lists: [ Aircraft | Manufacturers | Engines | Manufacturers | Airports | Airlines | Air forces | Weapons | Missiles | Timeline ]


Specifications survey

Rlandmann seems to have disappeared, and no one else is stepping up to the plate and publishing the survey results, despite a wait of nearly three weeks. Seeing this, I have decided to take the burden upon myself. For those interested parties, I have a detailed description of my reasoning at Wikipedia:WikiProject Aircraft/Specifications survey/Tally.

Please note that this is the first time I've done anything like this, and I don't feel completely qualified. If you believe that I've made a mistake, please discuss it here. Ingoolemo talk 06:05, 2005 August 20 (UTC)

The results have now been updated, based on some criticisms of my original results. Ingoolemo talk 03:20, 2005 August 21 (UTC)

The results

Adopt a parametrised template for specifications: passed
Official presentation format: text
Give force in lb or lbf: lbf
Include kgf thrust measurements: never
Include PS power measurements: never
What units should be used for range: no consensus
What units should be used for speed: no consensus
Rate of climb: m/s
Proper abbreviation for statute miles: no consensus
Proper abbreviation for nautical miles: nm
Proper abbreviation for knots: kt
Should units in the specs be linked to their respective articles: no consensus
Should the derived specifications be retained: yes
How should the 'thrust/weight' quantity be expressed: without units
How should the 'power/mass' quantity be expressed: no consensus
Add a 'cruise speed' stat: yes
Add a 'maximum overload weight' stat: no
Add description of number/type of landing gear: no
Add 'maximum surface land/sea speed': no
Remove 'loaded weight' stat: no consensus
Rename 'empty' to 'empty weight': yes
Rename 'maximum takeoff' to 'maximum gross takeoff weight': yes
Rename 'range' to 'maximum range': no consensus
Rename 'rate of climb' to 'maximum rate of climb': yes
Rename 'wing loading' to 'maximum wing loading': no consensus
Cease giving speed statistics in Mach numbers: no consensus
Include ICAO codes: no


:

Items needing further discussion

  • Units to be used for range and speed: no consensus was achieved among several different options. Note, however, that only a small minority directly opposed the adoption of nm and kt measurements.
  • Proper abbreviation for statute miles. mi (6), miles (5), and sm (3). The comments were too evenly distributed to successfully determine consensus.
  • Only one person came out against linking units, but the others were pretty evenly distributed among several very different options. More discussion is necessary.
  • Proper expression of 'Power/mass' quantity: the discussion needs to be broken up. The questions of 'power/weight' vs 'power/mass' and kW/kg vs W/kg must be resolved separately.
  • Removal of loaded weight stat: some support, but not enough to establish consensus. Closely related is the renaming of 'wing loading' to 'maximum wing loading'. More discussion needed.
  • Renaming 'range' to 'maximum range'. Some support, but not enough to establish consensus. More discussion needed.
  • Cease giving statistics in Mach. Not enough discussion to establish consensus.
    • Yeah, since this was under the section Are there any current specifications that should be renamed or clarified? and never actually explicitly said "cease" I actually thought this meant that we were voting to continue giving speeds in mach (I suppose this is my mistake as I should've figured that out from eric's comment). -Lommer | talk 00:20, 22 August 2005 (UTC)
    • Actually, I was proposing only giving supersonic speeds in Mach, unless an altitude is specified. Thus "Maximum speed: 1,440 km/h" would be unacceptable, while "1,440 km/h at 10,000m" or "Mach 1" would be fine. -eric 16:54, 22 August 2005 (UTC)
      • good, I wasn't totally mistaken, in fact I you did indeed mean what I thought you meant. -Lommer | talk 01:31, 23 August 2005 (UTC)

Procedural errors

You have made a major procedural error. You have failed to throw out non-qualified voters.

That is significant, because we know that we have other contributors who would have voted, had they known that their vote would still have counted even though they did not meet the voting requirements. Some specifically told us so. So the whole vote is tainted.

Note that I have specifically called this to your attention several times before. I think theat the oting should have been open in the first place, since none of the criteria for limiting it were met. But then, everybody should get that opportunity to vote, too. Not just those who ignored the rules and voted anyway. Gene Nygaard 10:48, 20 August 2005 (UTC)

Disputed vote count. I count rate of climb as 5 for m/min, 7 for m/s. Gene Nygaard 11:54, 20 August 2005 (UTC)

Another procedural error. Anything presented only in the additional suggestions part of the vote page, or not on the vote page at all and only on the project talk page, is not decided on the basis of a couple of comments. Often, these things weren't there when some of the people voted, and they were not given the same scrutiny as everything else. There is, of course, no need to decide all of these issues. Only those which seem to have clear, strong support or opposition should be included on your list. Otherwise, this might serve as a guideline for consideration in future tweaking of the rules, but they should not be listed as having been decided at this time. Gene Nygaard 12:06, 20 August 2005 (UTC)

Third procedural error. When several different options receive support, you cannot use some arbitrary combination of them for anything other than narrowing the focus for future consideration. You can't just arbitrarily lump together some of them, and assume those supporting one of them would support a particular choice if it were narrowed down to two or three options for a runoff vote, as in the case of units of range with (in Ingoolemo's numbers before throwing out illegal votes) a 3-5-2-1-3-1 split. Gene Nygaard 12:24, 20 August 2005 (UTC)

Fourth procedural error. Not all of these issues need to be decided now. Gene Nygaard 12:24, 20 August 2005 (UTC)

Other notes

  1. Note that for speed, the phrasing of the vote specified "(inclusion of km/h is assumed)"
  2. For range, the phrasing of the vote specified "(inclusion of km is assumed)" Gene Nygaard 11:54, 20 August 2005 (UTC)

Other Comments

Thanks for getting this done now Ingoolemo! To everyone, where do we go from here? Has anyone done any work putting together a template that incorporates all the items we reached consensus on? -Lommer | talk 00:20, 22 August 2005 (UTC)

Ericg is developing a specs template, Template:Airtemp-test. I would like to see a few changes made, but the template is close to being finished. Ingoolemo talk 00:00, 2005 August 25 (UTC)

Specs discussion

Before the specs template is implemented, there are some things that should be clarified, so the updating can be done in one go. Ingoolemo talk 00:47, 2005 August 25 (UTC)

Range and speed: kt and nm

My survey results showed pretty erratic comments, so there was no obvious choice with regards to implementing these. The survery was between three primary options (all others got one supporting comment or less):

  • Include whichever is in our source data, but always convert to the other (4 supporting for range, 4 for speed)
  • Include mph/mi only (3 supporting for range, 2 for speed)
  • Use whichever can be reasonably assumed to have been the units that the measurement was originally taken in, and permit a conversion to the other (3 supporting for range, 2 for speed)

Many respondents were concerned that the triple-unit solutions allowed under the first option would look ugly. I beg to differ: see User:Ingoolemo/Airspec demo. Ingoolemo talk 00:47, 2005 August 25 (UTC)

Proper abbreviation of statute miles

This should be an easy one. Spelling out the word miles seems to have failed, so the debate is mainly between mi and sm. I'm going to support mi, because it seems to me the less ambiguous obscure of the two abbreviations. Ingoolemo talk 00:47, 2005 August 25 (UTC)

I still support sm, because IMO both mi and miles could be taken to mean either nautical or statute miles. -Lommer | talk 06:33, 2 September 2005 (UTC)
sm. obscurity doesn't matter - if it did, we wouldn't be considering PS or arguing over lbf. -ericg 21:20, 2 September 2005 (UTC)
Again, I don't feel strongly either way, and would be willing to capitulate of stronger consensus appears in favour of sm. Ingoolemo talk 05:58, 2005 September 3 (UTC)
Support mi because it is the most common by a long shot. The symbol mi, like mph and sm and unlike spelled out but unidentified miles, are never used for nautical miles. Gene Nygaard 10:21, 4 October 2005 (UTC)
mi...whats the difference you might ay? a SMALL one. Some uninformed visitor might actually think sm is for small, however small this chance may be.

Antonio Small Arms Martin 9:21, 5 October 2005 (UTC)

...I would hope the context would clear that up. Why would an aircraft have a range of 500 small? That's absurd. ericg 16:48, 5 October 2005 (UTC)

Linking of units

How should units be linked. Each one to its article at first occurence? Only link less common ones? Link to a key to all units? Some support the first option because the tooltip allows complete unambiguity with regards to the unit (mouse over kt and kt to see what I mean). Some support the second and third because they dislike linking for æsthetic ræsons. Some oppose the second option because 'less common' would be a nightmare to determine. I personally prefer the first one, because of the tooltip. Ingoolemo talk 00:47, 2005 August 25 (UTC)

Should power/mass be renamed power/weight?

I'm going to go with no, for the reason of technical correctness. Weight is a measure of force, so our power/weight stats would most reasonably be given as kW/N or kW/kN. If we measure it in kW/kg, it should be power/mass. Ingoolemo talk 02:24, 2005 August 30 (UTC)

Should power/mass be expressed as kW/kg or W/kg

We should use W/kg, because it usually yields nicer numbers rather than decimals. And, as Bobblewik pointed out, the convention in metric is to tailor the prefix to fit the number (1 200 W is 1.2 kW, 0.200 W is 200 mW). Ingoolemo talk 00:47, 2005 August 25 (UTC)

I think so. eaders probably relate more to the word weight than they do mass.

Antonio Powerful Martin 09:25, October 5, 2005 9UTC)

Should the loaded weight stat be removed?

If we decide to remove it, we may wish to rename the 'Wing loading' stat 'Maximum wing loading'. Ingoolemo talk 00:47, 2005 August 25 (UTC)

Rename 'range' to 'maximum range'

I originally supported this, but now I vehemently oppose. My pet niche is bombers, which could never be successfully described by this statistic. Almost every source I've used for bombers has supplied a 'combat range' (a.k.a. 'normal combat diameter') and a 'ferry range' (the distance an unloaded plane can safely fly without refueling). Though 'ferry range' isn't always given, I have yet to meet a source that doesn't give 'combat range'. To adopt this change would deprecate the 'combat range' statistic, which is the most important range statistic for a bomber. Ingoolemo talk 00:47, 2005 August 25 (UTC)

better to give range and then the qualification after it - combat range could vary with the bomb load eg (B 29 low load to give maximum range to reach Japan) the entry would then look like one of these two examples.
Range: 1,250 miles (maximum bombload)
Range: 560 miles (unloaded)
GraemeLeggett 10:52, 25 August 2005 (UTC)
Not a bad idea, though I think the formatting could be better. Example:
  • Range:
    • Unloaded: 1,000 nm (1,100 mi, 1,800 km)
    • Maximum load: 260 nm (300 mi, 480 km)
The main problem, though, is that it's less simple and doesn't look as nice as just plain 'combat range' and 'ferry range'. Ingoolemo talk 15:49, 2005 August 25 (UTC)
Why not:
  • Range: 1,000 nm (1,100 mi, 1,800 km) unloaded; 260 nm (300 mi, 480 km) combat
or something like that? This way we can keep it on the same line and add more than one if needed. -eric 18:20, 25 August 2005 (UTC)
I'd prefer to have them on separate lines, because it clutters them up less. It's just a semantic difference, though, so I'd be willing to capitulate if more people support the one line format. Ingoolemo talk 20:33, 2005 September 1 (UTC)

Give speed for supersonic aircraft in Mach numbers (Mach)

  • I vote "exclusively", and would even support extending this to transsonic aircraft (e.g. those aircraft capable of >=0.80 mach)-Lommer | talk 21:53, 30 August 2005 (UTC)
  • exclusively, with altitude included. disagree with the transsonics; in that case it might be best to include it as a third (albeit primary) value. ericg 23:14, 30 August 2005 (UTC)
    • Just FYI, the maximum speed for new buisiness jets is usually at the barber-pole. IIRC, the VNE of the Citation X, Falcon 10, CJ3, and other several other bizjets new and old is given as a mach number in the POH. -Lommer | talk 04:35, 1 September 2005 (UTC)
  • Initially, I was opposed to this, but I'm starting to think otherwise. As in the case of nm and kt, a Mach number will have more meaning to a specialist (and arguably, more meaning to a layman as well). I also agree to the inclusion of altitudes, as recommended by Ericg, mainly because many supersonic aircraft cannot achieve their maximum speed below a certain altitude. Some comments and concerns:
    • Will we give Mach numbers for max speed only, or cruise speed as well?
    • I oppose using Mach for transsonic aircraft, except as a secondary value, because using kt/mph will allow a more direct comparison between transsonic aircraft and subsonic aircraft.
    • With supersonic aircraft, Mach should be a primary value, and no kt statistic should be given (Example: Maximum speed: Mach 2.1 (2,300 km/h, 1,400 mph)). I oppose including kt because it is meant to provide more meaning to the specialist, the same reason why Mach should be used. By including Mach, we satisfy the goal of 'more meaning for the specialist', so including kt is superfluous. Ingoolemo talk 20:19, 2005 September 1 (UTC)

Avionics

The old turquoise box included an optional avionics field, which was later dropped due to its frequent disuse. (Most editors did not feel comfortable with removing the avionics field, so they left it blank.) With the new templates, it is possible to toggle the avionics field off and on. Would we be willing to include avionics in the new templates? Ingoolemo talk 06:13, 2005 September 6 (UTC)

I think we should not. It's so uncommon that, if the avionics are of special note, they should be mentioned in the article itself. Most of the modern fighters have their radars linked, for example, and the rest of the actual avionics (radios, PFD/MFDs, etc) are not. If something is important and/or related to the aircraft's development, it can go into a see also or related development section. -ericg 17:43, 6 September 2005 (UTC)
Fair enough. Unless a flood of supporters appears, consider this recommendation dead. Ingoolemo talk 17:53, 2005 September 6 (UTC)
Agree with eric. The field is so rarely used that it isn't worth including in the template. -Lommer | talk 19:33, 6 September 2005 (UTC)

Abbreviation of pound-force

Our article on pound-force seems to indicate that the preferred abbreviation of lbf, not lbf as we are currently using in the WikiProject. (Presumably, lbf is an acceptable abbreviation becuase the subscript can be difficult to apply in some circumstances.) I move that we update our standard from lbf to lbf. Ingoolemo talk 18:34, 23 September 2005 (UTC)

The pound-force article does not say that, and has not at any time that I can remember.
The symobl used by NIST, the U.S. keeper of the standards, and by National Physical Laboratory, the U.K. keeper of the standards, is an unsubscripted "lbf". See, for example, the extensive list of conversion factors in NIST Special Publication 811, Guide for the Use of the International System of Units (SI), Appendix B.[1]
We should either use lbf only, or allow either. Gene Nygaard 06:21, 4 October 2005 (UTC)

General

Two comments on Ingoolemo's calling this discussion to our attention on our talk pages.

  1. This is not "policy".
  2. The unresolved issued do not need to be resolved before implementing the template. Rather, the template needs to accommodate the unresolved issues. Gene Nygaard 06:15, 4 October 2005 (UTC)

Just to clarify (based on Eric's added and deleted comment), I'm taking issue with the recent notice on my talk page, probably the same for most everybody else involved here, where Ingoolemo said in his editorial comment on those talk pages "Aircraft specs policy"—that's where my "not policy" comment comes from. An inadvertent comment, perhaps, but a point worth clarifying.

Also, in the text added to the talk pages, ingoolemo said, "However, several topics in the survey did reach establish consensus, and they need to be resolved before we implement the template."

Some of those topics perhaps can be resolved now. If they are, fine; I'm merely pointing out that there is no real crying need to do so, and if any remain unresolved, so be it. The templates then need to accomodate that. Gene Nygaard 07:19, 4 October 2005 (UTC)

I seem to have been somewhat misunderstood, which is solely my fault.
I believe that we should resolve the unresolved issues before implementing the template, for a very simple reason: If we implement the template now (which we can do, because the template is quite capable of accommodating nearly all changes to the standards), we'll need to do a massive wave of editing to every aircraft article we have, and do another wave later if any of the standards change due to the outcome of the discussion above. However, if we resolve those issues now, we can update both the template and the other standards in <cliché>one fell swoop</cliché>. If we resolve the issues now, we can cut our workload in half. Ingoolemo talk 08:02, 4 October 2005 (UTC)

a quick question

In my aircraft systems class the other day the instructor was discussing radial engines, and mentioned that they were more susceptible to damage / failure upon losing a cylinder than inline or vee types. This goes against everything I'd heard up to this point, and he had just claimed that the F4U Corsair was water-cooled, so I'm more than a bit skeptical. I'd like to expand our article here one way or the other—there's not much there now on use & reliability in combat, that sort of thing—so if anyone has more info or even anecdotes, I'd be grateful. -ericg 21:04, 6 September 2005 (UTC)

My understanding was consistent with yours. I thought that radial engines were more resiliant to the loss of one cylinder (due to plug fouling or whatever) than normal engines, if only because they generally have more cylinders to begin with. IIRC, In the heydey of radial engines, 22-cylinder engines were not uncommon. OTOH, I know that radial engines require a heck of a lot more maintenance than V- or straight-block engines. They suck back oil and gas like you wouldn't believe, and they usually have fairly complex vibrational modes that cause wear. -Lommer | talk 22:25, 7 September 2005 (UTC)

Template for aircraft specifications

In accordance with the results of the specifications survey, which showed strong support for incorporating our aircraft spefications into a template, Ericg and I have spent several weeks developing such a template. Through a clever system of subtemplates, we have made it possible to adjust the template so that it can be used for every plane we can think of:

  • Fixed-wing versus helicopters
  • Planes powered by jets, props, or both, and unpowered gliders
  • Cargo planes/airliners versus other kinds
  • Planes with and without armament

We chose to give the user editing the article full control over the units used.[2] We had a number of reasons for this:

  • More flexibility with the units. For example, User can decide whether to use kW/kg or W/kg as a measure of Power/mass.
  • Ability to include references (see proposal for PS/kgf solution above)
  • Ability to insert new lines of text. Useful when including alternate powerplants, differentiating between number of passenges vs weight of cargo in the capacity field, and other things.[3]

The template also gives us an option to switch the order of units. If a n00b gives the specs for a Russian plane in imperial units, for example, we just type |switch order of units?=yes and the order is reversed so that metric units come first.

Examples of the templates in action can be seen at User:Ericg/experimental/template and User:Ingoolemo/Airspec demo.

However, there are a number of things that the template doesn't control, include several of the points for discussion listed above. (Specifically, sections #Range and speed: kt and nm, #Proper abbreviation of statute miles, #Linking of units, #Should power/mass be expressed as kW/kg or W/kg, #Give speed for supersonic aircraft in Mach numbers (Mach), and #Abbreviation of pound-force.) Until we decide the solutions to those issues, there is little point in initiating a drive to templatise our articles. Please discuss the points above, so that we can begin our update drive as soon as possibe. Thanks, Ingoolemo talk 05:54, 4 October 2005 (UTC)

Notes

  1. ^  The difference in coding: when the template controls the units, the soure of the template looks like this: '''Empty weight:''' {{{empty weight imp}}} lb ({{{empty weight met}}} kg). When the user control the units, the source of the template looks like this: '''Empty weight:''' {{{empty weight main}}} ({{{empty weight alt}}}). In the first example, the user types:
    |empty weight imp=25,000
    |empty weight alt=11,000

    In the second example, the user types:

    |empty weight main=25,000 lb
    |empty weight alt=11,000 kg
    

  2. ^  For example, the V-22 Osprey can be represented thus:
    |span main=38 ft 0 in
    |span alt=11.6 m)
    * '''Wingspan:''' 45 ft 10 in (14.0 m
    |height main=17 ft 11 in
    |height alt=5.5 m
    |area main=9,100 ft²
    |area alt=840 m²)
    * '''Wing area:''' 1,745 ft² (162.1 m²)
    

    Which produces the text:

    • Rotor diameter: 38 ft 0 in (11.6 m)
    • Wingspan: 45 ft 10 in (14.0 m)
    • Height: 17 ft 11 in (5.5 m)
    • Disc area: 9,100 ft² (840 m²)
    • Wing area: 1,745 ft² (162.1 m²)

discussion

Suggestion '''Empty weight:''' {{{empty weight}}})
User types
|empty weight=25,000 lb (11,000 kg)
Rich Farmbrough 09:03, 4 October 2005 (UTC)
It's an interesting sggestion, and it simplifies things a bit, but eliminates the ability to switch the order. I'll talk to Eric about it, and see what he thinks. Ingoolemo talk 01:28, 5 October 2005 (UTC)
It limits later reformatting - if, for example, we again discuss the inline vs table specs and decide on tables, we could use the two-field template to create a table. This would be impossible with them on one line. And, as Ingoolemo says, we would be unable to switch the order, something that needs to happen more often than you might think. -ericg 04:06, 5 October 2005 (UTC)
I hadn't thought of that, and it's absolutely correct. It definitely swings me from wishy-washy to firm 'no'. Ingoolemo talk 04:53, 5 October 2005 (UTC)
I would like to support Eric's point about order. There are plenty of official specifications where some source values are metric (e.g. length) and some are non-metric (e.g. speed). It is important to know which unit is the source value and which unit is the converted value. There are different ways in which this can be done, e.g. source first, source above, source outside parentheses, source bold, source larger etc. Unfortunately some formats on Wikipedia have a two column (metric, non-metric) layout that is visually tidy but does fails to distinguish between source and converted values. I support tidy layouts but some method of identification of the source value for each dimension is generally a higher priority for me. Bobblewik 17:29, 5 October 2005 (UTC)