Wikipedia talk:WikiProject Aircraft/Archive 7

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 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
:

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 &#9992; 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 &#9992; 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 &#9992; 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 &aelig;sthetic r&aelig;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 &#9992; 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 &#9992; 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 &#9992; 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.
 * 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 one fell swoop.  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 &#9992; 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: We chose to give the user editing the article full control over the units used. [#endnote_units&parametres]  We had a number of reasons for this: 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  and the order is reversed so that metric units come first.
 * 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
 * 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. [#endnote_newlines]

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, , , , , and .) 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  ^ The difference in coding: when the template controls the units, the soure of the template looks like this:. When the user control the units, the source of the template looks like this:. In the first example, the user types: In the second example, the user types:
 * empty weight imp=25,000
 * empty weight alt=11,000
 * empty weight main=25,000 lb
 * empty weight alt=11,000 kg

^ 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&sup2;
 * area alt=840 m&sup2;)
 * Wing area: 1,745 ft&sup2; (162.1 m&sup2;)

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&sup2; (840 m&sup2;)
 * Wing area: 1,745 ft&sup2; (162.1 m&sup2;)

discussion

 * Suggestion
 * 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 &#9992; 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)