Wikipedia talk:WikiProject Aircraft/Archive 5

From Wikipedia, the free encyclopedia

Archive This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

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


Contents

Thrust - lb vs lbf

Can we come to an agreement as to whether to specify engine thrust in lb or lbf? There's no question that lbf is the technically accurate choice; however, lb is very widely used in the aerospace industry and publications, and has the advantage of being more familiar to a greater readership. I also note that most new contributors use lb - I've seen very few use lbf.

A few examples of industry webpages using lb instead of the technically-accurate lbf:

  • Boeing - [1] [2] (Google shows 7 hits for lbf thrust on boeing.com, 115 for lb thrust)
  • Lockheed Martin - [3] [4] (1 hit for lbf thrust vs 138 for lb thrust)
  • Northrop Grumman - [5] [6] (html versions of .doc files cached by Google) (13 for lbf thrust, 8 for lb thrust)
  • Pratt & Whitney - [7] [8] (1 for lbf thrust, 45 for lb thrust)
  • General Electric - [9] [10] (0 for lbf thrust, 18 for lb thrust)
  • NASA - [11] [12] (352 for lbf thrust, 8,490 for lb thrust)
  • USAF - [13] [14] (23 for lbf thrust, 271 for lb thrust)

and a couple of examples in print:

  • Jane's Encyclopedia of Aviation uses lb
  • Gunston's World Encyclopedia of Aero Engines uses lb.

Based on the above, it would seem that lb is the norm for expressing thrust outside of a strictly engineering context. --Rlandmann 04:57, 24 Jun 2005 (UTC)

i'll go with the consensus, whether it's that of google or the project. i'm more interested in us actually speccing all the planes than in the units we use. -eric ✈ 07:25, 24 Jun 2005 (UTC)
I'd rather go for technical correctness, since using lbf rather than lb is unlikely to confuse anyone. However, if y'all would like to implement an lbf>lb conversion anyway, please do so. Ingoolemo talk 02:00, 2005 Jun 25 (UTC)
I'm not from a country that uses Imperial measurements, so I need to ask - isn't it more likely that "lb" will be more meaningful to more people than "lbf" will be? Secondly, if it's so wrong to express thrust in lb, then why is the usage so widespread, even among entities such as the organisations mentioned above who definitely know the difference? --Rlandmann 02:53, 25 Jun 2005 (UTC)
More "comfortable" or "familiar", perhaps. Not more "meaningful" by any stretch of the imagination. These pounds force are different units from the pounds Americans are used to using, when they buy a pound of butter or a bag of sugar, for example.
Part of the reasons I've discussed in my earlier reply below.
  • Distinctions are sometimes made in other ways.
  • Many people have been so poorly educated in the English units (even in the United States, almost all science education has been done in metric units for many years), that they don't even understand that there is a distinction to be made.
  • Even among those who do understand that there is a difference, there are very common misbeliefs that it is the pound mass is a recent spinoff from the pound force, and that it is the pound mass which they should distinguish rather than the pound force. That practice is followed in some textbooks, for example, but is not supported by any of the various kinds of standards agencies, national or international or professional or whatever in their usage. For example, see American Society for Testing and Materials, Standard for Metric Practice, E 380-79, ASTM 1979:
  • "3.4.1.4 The use of the same name for units of force and mass causes confusion. When the non-SI units are used, a distinction should be made between force and mass, for example, lbf to denote force in gravimetric engineering units and lb for mass."
See also the extensive list of conversion factors in NIST Special Publication 811 [15], and the consistent distinctions there between pounds (lb) and pounds-force (lbf). Gene Nygaard 30 June 2005 11:18 (UTC)
I work in metric so I could care less, but I see this as a real non-issue. The difference between lbf and lb is only important in outer space, and even then everyone assumes a 1:1 conversion. In my engineering classes, most profs use plain lb and so do most of the textbooks. In short, use whatever you like, but I'm certainly not going to expend any effort enforcing one standard over another when they're directly interchangeable. -Lommer | talk 06:08, 25 Jun 2005 (UTC)
Nobody with any sense assumes a 1:1 conversion anywhere outside Earth, and nobody requiring even moderate accuracy and precision (numbers with only 2 or 3 significant digits) assumes a 1:1 conversion even on Earth. They most certainly are not "directly interchangeable". What you are referring to is a different confusion, a failure to realize that pounds are indeed units of mass in most other applications. Gene Nygaard 30 June 2005 11:18 (UTC)
The important factor in your statistics, Rlandmann, is that most of them do in fact use lbf at least at times. As you yourself admit, it is indeed technically correct. Google searches are good for showing existence of usage, lousy for prevalence of one usage or another or for correctness of that usage.
Furthermore, this isn't an industry publication; it is a general encyclopedia. We need consistency with the usage of the rest of the encyclopedia.
Of course, those searches just for the two terms used together are misleading in several ways. There are lots of different ways in which this information can be expressed, variations in spelled out words and abbreviations, and overlap in various searches. For example,
  • Of the NASA hits for lb and thrust, 175 of them also use lbf. In most of those cases, the lbf are used for thrust and the lb are used for other quantities such as fuel consumption.
  • You found only 4 hits for 'lbf' and 'thrust' at Boeing. But a search for 'lbf' and 'thrusters' finds 49 hits. [16]
  • Of the NASA hits for 'lb' and 'thrust', 440 of them also use 'slugs'. In most of those cases, those slugs are used for units of mass, so within that particular web page, the force units are distinct from the mass units.
  • None of the Wikipedia articles use slugs for mass.
  • Virtually all of the Wikipedia articles which use lbf for thrust use lb for the mass units as well, so using lb for the force units leaves us with the same symbol for two different units.
  • Of the NASA hits for 'lb' and 'thrust', 78 of them also use 'lbm'. That is a nonstandard way of making the distinction between pounds and pounds force, one never used on NIST websites, for example, and fewer hits on nasa.gov than 'lbf' has.
  • Another significant factor is bad teaching; there are a surprisingly large number of physicists and engineers who have been falsely taught that "pounds are not units of mass" (I have an old list of hundreds of education sites and textbooks making this claim, and could point you to a quite a few websites doing so), and consequently they do not see the need to make any distinction. But you already know that this is wrong, and a look at Talk:Pound discussions, and at the separate article for pound-force, can help others how patently absurd that idea is. Gene Nygaard 30 June 2005 10:48 (UTC)
We're arguing apples and oranges here. You've gone to considerable effort to show that lbf is the technically accurate English unit in which to state force; but nobody here is saying otherwise.
My contention is that lb is colloquially acceptable, just as the pound (and the kilogram) are colloquially acceptable units for weight. I suggest that it is probably even the norm, not just in aviation/aerospace contexts, but in a large variety of contexts where forces are being expressed in English units.
As I see it, since this is a general encyclopedia, our purpose is better served by using a unit that is familiar, comfortable, and immediately comprehensible to the greater number of people using English units. To my way of thinking, the use of lbf is unnecessarily pedantic. I wonder which (if any) of the following statements you'd disagree with:
1. More people recognise "lb" than "lbf" when they see it.
2. "lb" is frequently used in English to express measures of force.
3. Everyone who understands what "lbf" means also knows what "lb" means, but the reverse is not true.
Many words and symbols mean different things in different contexts. I believe that "lb" is one of them; and that distinctions that are important in an engineering calculation are not necessarily important distinctions in more colloquial usage such as a general encyclopedia. --Rlandmann 2 July 2005 03:04 (UTC)
I strongly agree with Rlandmann above. Though I concede that the world will not come to an end if either unit is chosen. These debates are fun and enlightening, but are also terribly unproductive. I'll just use "lb", "kg" and/or "kN" when I spec aircraft, as is done in 99% of aviation literature and as is understood by 99% of those who read it. If Jane's writers spent so much time on these things as Wikipedians did, they'd never get anything done. ✈ James C. July 2, 2005 16:48 (UTC)

Parameterised templates

The info box is a superior visual way of presenting information. I have generated a parameterised version for the military jets based upon the old one - at template:aircraft-jet-mil which I have used for the Hawker P.1127, and for the poor old BAC TSR-2. Now infoboxes are good visually but hard on the eyes when editing, parameters make editing easy, and expansion easier still. For other examples look to template:tank usable for most military vehicles, Template:Doctorwhobox, template:weapon-firearm. GraemeLeggett 28 June 2005 15:52 (UTC)

Just an initial observation that "visually superior" is very much an opinion; the whole push away from an infobox to text-based specifications was initially driven by people arguing exactly the opposite. --Rlandmann 28 June 2005 16:00 (UTC)
I thought it a commonly-held belief that a tabular format was superior to a list of text, but I will see if my argument can be supported. To my mind though, the first, and a major ,effect of the infobox is that it restricts the width of the text of the article, which reduces the work the reader's eyes have to do to - a common problem with the landscape format of the computer monitor. Secondly, and less importantly it can be used to add colour to the page. GraemeLeggett 28 June 2005 16:28 (UTC)
When we switched from the old table format, the consensus in favour of the new format was quite strong. I strongly agree with Rlandmann on the topic of 'visual superiority'. I also find that the current format is far nicer than the old table format; note, however, that I would not object to readopting the table format if someone came along with a redesigned table that looked better than the old one. For now, let's stay away from the table until some consensus is reached in favour of returning to it. I believe that current WikiProject Aircraft policy is to update any articles in the old format on site.
Regarding the use of parametrised templates: they are simply too inflexible to use effectively, necessitating multiple templates with only subtle differences. I also disagree that they would necessarily be easier to use, given the huge number of parametres involved. Because the parametres appear in a horizontal list, they lack the organisation afforded by directly editing a table; instead, they are just a line of names, numbers and = signs. Furthermore, to properly use a such a template, one must:
  1. Know which template has all the proper parametres
  2. Know the names of all the parametres
  3. Fill out the value of every parametre exactly as it occurs (if you type <|Span=146 ft|>, the template won't register it, because the parametre's name is {{{span}}}.
By the way, if you want tables that are easier to edit, you might be interested in Wikipedia:Proposal for Table: namespace and intuitive table editor. Ingoolemo talk 2005 June 29 00:33 (UTC)

Tables are a standards nightmare, as well as destroying any sense of page flow on a mobile device. They make inline images within any article difficult to line up or even use - often shoving them to the bottom of the page. Attempts at using inline tables, like the orders for Airbus A380 and Boeing 787, are ruined as well, as they too are shoved to the bottom. Finally, contrary to your opinion I think they look like absolute crap from a web/print designer's perspective. Adding color to the page is something that doesn't work across all wikipedia skins - which exist, fyi, and which aren't identically colored - and is generally unattractive (puke green! hot turquoise!). In conclusion, we should avoid reverting to tables because they suck. -eric ✈ 29 June 2005 02:03 (UTC)

Wow! just in case anyone didn't know how Eric feels about tables :). But I'd forgotten about the image problem. Basically, if you try to insert an image aligned on the same side as a table, the table will force the image to the end of the table, usually causing a large and unsightly gap in the text. If you try to insert it on the opposite side, the text will be so squeezed it looks hideous. So, yet another reason table's are bad.
By the way, Graeme, if no one else objects in the next few weeks, I'm going to update your articles to the new standard. I would like to request that you create no further templates until some significant support for the concept is demonstrated. Thanks and Cheers, Ingoolemo talk 2005-06-29 02:15:29 (UTC)
Excuse me: I saw the way the template worked in the Hawker P.1227, and now recognise that a vertical list of parametres is possible with a parametrised template. Sorry for my confusion. Ingoolemo talk 2005-06-29 02:48:57 (UTC)
Hi. Though I contribute to en.wp little, let me make some comments: I don't have any strong opinion to use or not, but using parameters have an advangate, as you may know. You can change the format of the data "on all the pages at once" by just editing the corresponding template. Say, from table to list or plain text style, vice versa, etc... In this method, when changing the data format is needed, you don't have to edit all the pages as present (no need for bots, neither).
Again, I'm not saying we should use the method, instead, my intention is just giving info. Perhaps you are well familiar with these benefits. In that case, sorry to bother you.
By the way, about Ingoolemo's three points, I guess just 1 can be the problem. 2 and 3 don't seem to be serious when you use "copy-and-paste", instead of typing. (I'm afraid I might miss the point...) - Marsian // talk June 29, 2005 13:09 (UTC) -- fixed Marsian // talk June 29, 2005 13:10 (UTC)
Marsian raises an important point - Graeme is actually proposing two quite separate things here: reverting to using an infobox as a standard, and adopting a parametrised template for presenting specifications. While I am very much against the first of these ideas, I wouldn't mind revisiting the second.
My opposition to the infobox is purely a pragmatic one. Unlike others here, I don't have a strong preference for or against table vs text; I'm happy to go with community consensus. On the other hand, most of our aircraft articles now have the text-specifications, and converting them would be a very major undertaking. Additionally, changing the standard last time was difficult and, at times, acrimonious. I feel a strong disinclination to go back and start undoing changes to pages that have been updated over the past year, to start the wholesale conversion of hundreds of articles that have been created with the new format in place, or to explain to other editors why the article they created with an infobox which was subsequently updated ("But I spent ages getting that table right!") has now been changed back to an infobox.
On the other hand, most people here will know that standardising the way that we present content is a priority for me, and therefore I find a parametrised template very appealing! Last time we discussed this, the perceived problems included:
  • ease of editing: a plain text specifications section is easy for new editors to use, rather than being hit with a face full of code when they hit the edit button. This problem was exacerbated by the sheer size of our infobox, meaning that a lot of scrolling was needed before reaching any real content.
  • questions about the stability of the software: were parametrised templates here to stay? (WikiProject Aircraft had been recently badly affected by a previous system-wide change when the new [still current] skin was adopted for the 'pedia).
The second of these objections is easily dismissed now - parametrised templates don't seem to be going anywhere - we may as well agonise over whether ''' will always bold text. As to the first: if were were to parametrise the current text section, it would still be a fair way down the article - the edit button will still bring up intelligible text first. Furthermore, speaking pragmatically again, relatively few articles on aircraft are contributed with the project's standard specifications. To me, it seems that adapting or replacing the data that's contributed to make it match a new parametrised template is no more work for the project than adapting or replacing the data to make it match the convention that we have now. Finally, believe that the change to using a parametrised template to express our current text-specifications wouldn't lead to many ruffled feathers - if someone were to contribute a plain text section that then got parametrised by a project member, since the result looks the same, I doubt there would be too many complaints. --Rlandmann 2 July 2005 03:40 (UTC)
Well, I don't think colors should be used on any tables. While we can't remove the page flow issues, I think plain tables (no borders, no color fills, only bold text for headings) integrate nicely with any page's visual design. Something like this, though with row rather than column headings, nicer spacing and no wikilinks. ✈ James C. July 2, 2005 17:00 (UTC)
I have to agree with those arguing against reintroduction of infoboxes. Without a doubt parameterised templates would make the whole process easier and more accessible to new users but the downsides are already well documented (though me pet hate was the wide variation in infobox styles). Parameterised plain text specs. would be very easy to edit but then generating them within an article as plain text is not complicated. However the arguments here make me believe the best option is a parmaterised, plain text specification. Mark 17:14, 19 July 2005 (UTC)

Thrust in kilograms-force

In a great many of the Wikipedia articles, the measurements of thrust not originally made in either newtons nor in pounds force, but rather in kilograms-force. That includes most everything made outside the U.S., Canada, and the U.K. before about the 1990s. It includes measurements made in China and some other places even today.

The original measurements always give us the best sense of the precision of those measurements, and the best guide for rounding off the conversion to the other two units we use all the time.

Yet, for example, User:Ericg has recently removed those measurements from Mikoyan-Gurevich MiG-23. That isn't right. When the original was in kilograms-force, it should still be converted to newtons, as well as to pounds-force, but the original measurement should remain or be restored from cases where it does not already appear.

Just in case you have any difficulty with the MiG-23 example in which the kilograms-force had disappeared before the first placement of text in the Wikipedia article, perhaps discarded by the original source of this information rather than a Wikipedia editor, there are also other examples in which those kilograms force appeared in the first thrust figures given in Wikipedia, including some in which the only measurement of thrust originally given in the Wikipedia article were kilograms-force, with neither newtons nor pounds-force given. For example, look at the specific data on five different versions of Nakajima Kikka, some of them including engine alternatives. In this case, the infobox still there still contains the 9.4 kN and 2,094 lbf (originally 2x2,094 lb) from the 19 Feb 2004 original, with the 2,094 lbf a fairly obvious conversion from 950 kgf (You don't get from 9.4 kN to 2,094 lbf in any other logical way with any conversion factor anybody would use, so the 9.4 kN is not the original; but 950 kgf does convert to 2,094 lbf if carried to too much precision, so that must be the original. The undue precision, with figures in this range usually not expressed to the nearest pound-force when originally measured in pounds force, and the fact that this was made in Japan, make it quite clear that the pounds-force themselves are a conversion, and not the original measurement.) BTW, the infobox thrust figure is significantly higher than any of the information given for specific engines used in the various versions. Gene Nygaard 30 June 2005 12:49 (UTC)

I removed the kgf values in an attempt to simplify the already confusing powerplant information listed for the MiG-23. My assumption, which seems to be in error, was that kgf was an outdated, irrelevant measurement, and that a double conversion in an article seemed excessive. Hopefully you've since fixed this. -eric ✈ 30 June 2005 17:10 (UTC)
I agree with you that two supplementary measures is worse than one. I also agree that kgf is not as desirable as kN. However, if the kgf value is the raw data, then I think we must pay the price. But there are some conversions that I do think are excessive. For example having two versions of common non-metric units such knots and mph. Bobblewik  (talk) 30 June 2005 17:30 (UTC)
Those kilograms-force are outdated (though somewhat strangely, many younger people mistakenly think that they are instead a recent bastardization). I don't think they should ever be added in cases where it isn't possible for them to have been the original measurement. There only relevance today is as a check on the conversions which have been made and as an indication of the original precision of those measurements. But the problem is that the aviation and astronautics are among the fields slow to pick up on new standards. For example, those kilograms-force remained the standard units in the Soviet space program, with hardly any encroachment by newtons until nearly the time of the breakup of the Soviet Union. Of course, the fact that in much of the world, including many places that have long been metric, altitudes are still measured in English feet is further evidence of how hopelessly slow this industry is to pick up on international standards, as is the units mixup of the Mars Climate Orbiter. Gene Nygaard 30 June 2005 18:07 (UTC)
I believe that ericg was entirely correct in removing the kgf figures from the specifications, and I would always do the same myself. For the purposes of writing an article for a general encyclopedia, I don't think it matters in the slightest whether the measurements were originally taken in kgf or N; we very seldom are obtaining figures from primary sources in any case. We might be able to deduce what those units were (as you seem to have done with the MiG-23), but when you consider that our specifications (at best) represent an ideal set of figures typical for the aircraft that we're describing, any loss of precision (or, creation of false precision) arising from conversion of these figures (whether by us or by a source that we are relying on) is purely immaterial. --Rlandmann 2 July 2005 14:36 (UTC)
When I have used the kgf figures, it has almost always been either because they are the numbers originally given or to explain my removal of the false precision of the converted values presented without giving the original numbers. That's something that will almost never be noticed, if these figures are not given. So it isn't loss of precision that is the most important factor; what is almost always lost by not including them is the sense of how precise (or usually, how imprecise) they actually are. Gene Nygaard 2 July 2005 15:28 (UTC)
In which case, since this is really meta-information, perhaps it would be better to include it on the article talk page? (and/or in the article itself, commented out)? Rlandmann 2 July 2005 16:16 (UTC)
Not "meta-information", just "missing information" if it is not included. It is the readers, not just editors, who get that information about the actual precision by seeing it included in the article. No matter how they are done, conversions never convey exactly the same information. Gene Nygaard 3 July 2005 16:37 (UTC)
Every article is full of missing information; if John Smith from Anytown, USA once owned a Cessna 172 and we don't report it, then that's also missing information. But it's not information that's relevant or important in a general encyclopedia article. I submit that the precision of a nominal engine thrust measurement isn't either. --Rlandmann 3 July 2005 19:33 (UTC)
But is this case, kilograms-force are still very much in use. They are the units whick will give some people the indication of thrust which they can understand best. While the Russian space program has, at least to a fair extent, converted to SI units for the measurement of thrust, the Russian aviation community, and the aviation community in many other parts of the world, lags far behind in adopting international standards.
For example, the specs at http://airtoaircombat.com/ use only kilograms-force and pounds-force (calling them "lb." and "Kg"). Nary a newton to be found at that site, the way it looks to me.
Even more to the point, the Russian Aircraft Corporation, in its specs for various MiG aircraft, gives the thrust only in kilograms-force, identifying them with the symbol kgf in the English version, and using the Cyrillic abbreviation кгс in the Russian version rather than the international symbol (which is, of course, also distinct from кг, the symbol for kilograms). No pounds-force, no newtons—strictly those non-SI kilograms-force, that's all they use. Gene Nygaard 4 July 2005 22:08 (UTC)
So we really have two separate issues here: The first is to do with the precision of converted figures, or more specifically, the information about the original precision of those figures that is lost in conversion (and especially when converted without regard to issues of precision). The second is to do with unit is going to be most meaningful/familiar/recognisable to a specific readership group.
I still don't understand why you see the first of those issues as being important to an article in a general encyclopedia - could you please address this specifically?
As to the second issue: you posit a readership group for whom kgf will be the measure of thrust that they best understand. I concur that this group must exist, but since this is English Wikipedia, I question whether it is a significant enough readership for us to be specifically concerned about in a general encyclopedia? Secondly, I find this argument surprising from you, since elsewhere you're arguing against using the colloquial "lb" as a unit for thrust, which for a large English-speaking readership is surely going to be the measure that they best understand. Finally, the group you posit will find kgf to be most understandable regardless of what units the measurements were originally taken in (or we originally sourced them in). Are you advocating including a conversion to kgf for all measurements of thrust? --Rlandmann 7 July 2005 00:24 (UTC)

value(x) and value(y) and value(x/y)

I have previously stated my opposition to the inclusion of values (e.g. thrust/weight) that are merely the division of two other values. These add little value to the article. They add clutter and are not of interest to the casual reader. The expert reader will be able to do the simple division by themselves. In the case of thrust/weight, there is the added complication that there are as many values of thrust/weight as there are values of 'weight'.

Occasionally, I have checked thrust to weight values and found errors. For example, the value for Mikoyan-Gurevich MiG-23 was quoted as 0.83:1 but it is actually 5.3 N/kg (0.54 lbf/lb). The value for Antonov An-124 was quoted as 0.901:1 but it is actually 4.0 N/kg (0.41 lbf/lb). The errors are so common that I regard Wikipedia as unreliable as a source for this information.

I propose that where we provide value(x) and value(y), we do not provide value(x/y). Bobblewik  (talk) 30 June 2005 16:48 (UTC)

Thrust weight ratio is a rough guide to performance, more so for similar types of aircraft - just as with power/weight ratios in vehicles like AFVs. I say keep it. GraemeLeggett 30 June 2005 18:15 (UTC)
In case you are wondering where the An-124 numbers came from, (4x51,600 lbf)/(229,000 kg) = 0.901 lbf/kg, strange units to use for this purpose. That's one reason why carrying the units along while doing the calculations helps. That's equal to 0.409 kgf/kg or 0.409 lbf/lb or 4.01 N/kg. Gene Nygaard 30 June 2005 20:19 (UTC)

Distance and speed specifications

I recently altered Template:Airspec-imp and Template:Airspec-met to include specifications in both nautical miles and statute miles. At the time, I believed that I was following consensus (see previous discussion), but Rlandmann disputes this, and recommended that I discuss my changes first. The diff between the standard version and my proposed version is here. For the record, it seems that only Rlandmann disagreed with nautical miles as primary English units, though he didn't oppose including them. Ingoolemo talk 2005 July 4 06:13 (UTC)

I didn't think that any consensus was reached; it seemed to me that discussion just petered out. Sorry if I failed to assume good faith. I also note that the Ingoolemo's new template attempted to add a new specification (Cruise speed) which has never been part of the standard (even from the lime green days), to revert Range to a standard that was dropped a year ago, and to introduce lbf and kgf while discussion is still continuing. --Rlandmann 4 July 2005 06:25 (UTC)
Just for the record, my template's differences with the standard (cruise speed and range) were added months ago when I created it; I just never bothered to remove the specs. I never introduced into the template; lbf was copied from the existing standard months ago when I created the template. Ingoolemo talk 2005 July 5 18:19 (UTC)
Just for the record again, the template is now the same as the standard. I would also like to note that the current specs section on /page content still recommends the lbf measurement, so the template (both as I created it and as it is now) is still in line with the official standard. Ingoolemo talk 2005 July 5 22:21 (UTC)
There was no consensus reached in the earlier discussion. There was no agreement on which of the three units should be included, when.
There was not even any discussion whatsoever of time-dependent changes in usage in the field of aviation.
There certainly was no consensus reached on the details of your templates.
Your templates confict with the standards on the page content page. Any changes to either should be coordinated.
Symbols for miles:
The symbol "sm" is almost totally unknown. I know of one instance when "SM" is used, of limited geographical application, and only to measure one particular quantity.
The symbol "mi" is in common use. There is no good reason for a lack of parallelness, in spelling out one unit and not the others.
  • The symbol "mi" is unambiguous; it is never used standing alone for nautical miles'. This abbreviation is much, much less ambiguous than the spelled out word "miles", which is often used without specific qualification for nautical miles as well as for statute miles. (The symbols n mi and nmi are sometimes used for nautical miles, but never mi standing alone. But this is even more true when the "mi" alwasys appears alongside nautical miles that are identified unambiguously as nm.
This is, of course, a topic still open for discussion, since no definite agreement on many of these points have been reached in the past. This discussion is part of the process of trying to reach an agreement.
There's no reason not to have a standard which includes a basic framework, included whether we have numbers for them or not, and allows additional items such as "cruise speed" without entering them without numbers if they are not used in a particular article. Or, more generally, material that is supplementary to the basic framework should be permitted when it is relevant.
As far as distances in general, a reasonable solution would be to include both kilometers and one or the other of the miles in all instances, with both miles optional. Gene Nygaard 4 July 2005 21:55 (UTC)
sm is generally accepted in the us and canadian aviation communities as 'statute miles', an important distinction when some aircraft measure speed in miles and some in knots. i'm of the opinion that if an aircraft uses knots on its airspeed indicator, then our article should reflect its performance in knots + km, with miles perhaps included. i understand that statute miles are what more ordinary readers will understand, but if we're arguing over the inclusion of kgf, then we need to certainly do the same with nm and sm/mi -eric ✈ 4 July 2005 23:24 (UTC)
  • addendum - the 'nautical' unit of speed is not nm/h - it is kts or knots. i have seen it incorrectly before. -eric ✈ 4 July 2005 23:28 (UTC)
No, it is SM, capitalized, that is used in two countries in the world, for one purpose only, in METAR: visibility. That isn't even "sm" and it isn't by any stretch of the imagination a widespread usage. Before the U.S./Canada were allowed to call the bastardized version they use by that METAR name, there were no units for visibility stated in those reports. The units were unnecessary, because everybody else in the world measures that visibility in meters.
Even in the aviation community, and even limiting it to that community the United States and Canada, using "sm" rather than "mi" for statute miles is an aberration, and a symbol little recognized. But this isn't the United States and Canada aviation community in any case. It is a worldwide English encyclopedia, and it is almost certainly much more read by people outside the aviation community than those within it. There is not now, and likely never has been, any mention of "sm" as an abbreviation for statute miles in the Wikipedia articles for either statute mile or mile.
Granted, there are a few other people who do occasionally use "sm" for statute miles. It is, however, something that you are more likely to find in one of the zillion lists of conversion factors and conversion calculators you can find on the web, rather than something that is used in any actual publication. Especially when you get to anything giving areas; books and websites using "mi²" for area are abundant, as are those using "sq mi"; I've never in my life seen anybody ever use sm² for square miles. Just look at Wikipedia, and see if you can find even one page (other than a talk page) using sm², or for that matter any symbol other than "sq mi" or "mi²", as a symbol for square miles, or any web page other than some which might have used Ingoolemo's templates using "sm" for statute miles.
In any case, like I said before, "miles" is an ambiguous term in the aviation community, and needs identification; "mi" is as unambiguous in the aviation community as it is anywhere else, and it is recognized and understood immediately even by those who do not use it often themselves.
Back in the days of the 1911 Encyclopædia Britannica, and even the next several editions of it as an American encyclopedia, the abbrevation "m." was fairly common for statute miles, but that often results in confusion with the "m" for meters/metres. That abbreviation for miles may still be used to some extent in the U.K., but its use has dropped off sharply there and it has almost completely disappeared as a symbol for miles in the United States and Canada.
As far as knots go, their symbol should be "kt"; all units of measure should remain unchanged in the plural, something that the Wikipedia:Manual of Style (dates and numbers) has said for a long time, since before I started editing on Wikipedia, I'm fairly sure. There have been some changes made to that article today (or yesterday, at least for some people), but that likely still remains one of the general rules given there. IMHO, using "kts" is more incorrect than using "nm/h"; but nobody has proposed using "nm/h" in the first place, have they? Gene Nygaard 5 July 2005 05:19 (UTC)
Gene, you've certainly got a chip on your shoulder about this, but it's not like I'm talking out of my ass. I'm an experienced private pilot, who recently scored 97% on the instrument pilot written, and I'm in a flight program tracking me towards commercial flight, so please do give me a little credit when it comes to aviation. The FAA, whether you accept their terminology as acceptable or not, uses kts. to indicate knots. (Searching for 'kt' turns up a bunch of entries without any actual mention of airspeeds at all, so please do not attempt to use this to counter their use of kts.)
The US military also abbreviates knots as kts in their list of acronyms. More official sources than your humble opinion, however valid, have already spoken on the 'correct' plural abbreviation of knots. Finally - sm (or SM, if you feel the need to be retentive) is used and recognized by the FAA (it's also in the AIM's appendix 3 abbreviations list) for more than just METAR reports - it's on any E6B flight computer for conversions, and it's also on most chart plotters.
Gene, half the general aviation aircraft in the world measure their airspeed in miles per hour - statute miles per hour. If charts and plotters only recognized nm, then they would be doing conversions constantly, creating a hazard. Tens of thousands of pilots regularly plan their flights using scales that read 'sm'. Speaking of units that make no sense, and your apparent hatred for the US/CA METAR standard, the international METAR measures wind speed in meters per second, yet airspeeds are in km/h. If this makes sense to you, then I'd be happy to hear why, because using different units for wind speed and airspeed sure seems unnecessarily awkward to me. - eric ✈ 5 July 2005 08:23 (UTC)
To my mind, as a non flyer, "SM" means nothing. The text should use "miles" or perhaps "mi." MOst readers being non-sailers as well they won't get confused between NM and oridnary road-type miles. GraemeLeggett 5 July 2005 08:43 (UTC)
I was surprised at the assertion:
half the general aviation aircraft in the world measure their airspeed in ... statute miles per hour.
So I looked online
What is the number of active general aviation aircraft in the United States? Worldwide? In 2003, there were 211,190 total active aircraft in the U.S. and approximately 312,000 worldwide.
I could find no statistics on the airspeed indicators but if both the assertion and that quote are true, then 156,000 GA aircraft worldwide use statute miles per hour. Almost all of those could be in North America. I have occasionally encountered aircraft outside North America that use it, but they have always been 'historical' aircraft usually from America. I certainly don't believe that 50% of GA aircraft outside North America use statute miles per hour.
As far as the abbreviations 'sm' and 'SM' are concerned, they seem obscure to me. At first glance, I would think it was a mispelling of 'cm'. My preference is always to write out mile and nautical mile in full, I have yet to come across an article where that is a problem. I don't particularly like 'mi' and 'nmi' but I tolerate them. The argument that 'SM' is seen by some American aviators carries some weight with me, but 'sm' (or 'SM') would be a poor third for me. I would be surprised if non-aviation readers in any country would prefer that abbreviation in Wikipedia articles. Bobblewik  (talk) 5 July 2005 11:25 (UTC)
It should come as no surprise to anyone that symbols for units of measure are generally case-sensitive. But I should also point out, especially for Bobblewik's benefit, that the coded transmission METAR format for aviation weather is still set up for use on the old 55-baud teletype machines, a numerals and capital letters only code (see Baudot code). That also results in nonstandard symbols for metric units, and isn't an indication that sm is not also used.
The METAR (an all-caps format) symbol for knots is KT.
The FAA also uses "mi" (and "MI" in all caps text) for miles. Some of them, as well as false positives, can be see in this Google search.
The "US military" site you mentioned includes several of acronyms including some from outside sources, I'm not sure which one that K section with the 15 February 1994 date belongs to. The page with the in-house Joint Acronyms and Abbreviations "as amended through 09 May 2005" doesn't list kts; under kt it has
kt
kiloton(s); knot (nautical miles per hour)
JP 1-02
I was under the impression that air speed indicators, even in general, personal aviation in small craft in the United States, were changed from statute miles to knots at some time in the 1970s, and a few years earlier for most commercial and military aviation. Therefore, I join Bobblewik in questioning the claim that "half the general aviation aircraft in the world measure their airspeed in ... statute miles per hour". Can you back that claim up from some reliable auhority? Gene Nygaard 5 July 2005 15:09 (UTC)
I was estimating and could certainly have been high, as I don't have access to raw stats, but if you consider the average age of general aviation aircraft (according to the AOPA: "average age of aircraft in the GA fleet is 27 years...16 years for multiengine jets, 19 years for turboprops, 29.5 years for multiengine piston, and 31 years for single-engine piston.") If the average piston engine aircraft is 29 to 31 years old, that puts it right around the mid-'70s. Piston entine aircraft are also the most numerous type in GA. The same source mentions that while in 1978 the industry shipped 17,811 aircraft, recently it ranges from a few thousand down to several hundred. As the airspeeds were switched in the '70s, as you point out (in the late '70s, as i've flown a '76 Cessna 152 with a mph airspeed indicator), a massive portion of the general aviation aircraft fleet use statute miles rather than nautical. As America comprises two thirds of the worldwide general aviation fleet, if one half to three quarters of the American GA fleet still uses MPH and has not been updated avionics-wise, then a third to half of the world's fleet does as well.
I'm not going to argue about SM vs sm - that I could care less about. I do, however, believe that far more aircraft than you are willing to admit are using some capitalization of that measurement to determine their airspeed. -eric ✈ 5 July 2005 16:47 (UTC) also: this is the wikipedia. why can't we link these to their respective articles and educate the reader, rather than sit here worrying about confusing them? we have hundreds of thousands of articles at our fingertips, waiting for brackets. teach them something new, if they're curious. if i was a reader and i saw the attempts to avoid confusing me, i would personally be offended that the wikipedia was being dumbed down or oversimplified. -eric ✈ 5 July 2005 16:53 (UTC)

Regarding the linking of units: when I nominated the B-29 for featured status a few months ago, one of the objections raised was that the units in the data table should link to their respective articles. I know it would be a headache to do this, but it is certainly worth considering. (I personally don't care much either way.) Ingoolemo talk

i attempted this in some recent edits (i don't remember which) and seem to recall they were reverted. -eric ✈ 6 July 2005 05:36 (UTC)

Apologies

Hi all - I'd just like to say sorry for my uncivil remarks yesterday; and in particular, sorry to you Ingoolemo. I'll admit that I'm finding this all extremely stressful and frustrating. Hopefully, something can be sorted out before this turns into one of Wikipedia's lamest edit wars. Maybe we need mediation? --Rlandmann 6 July 2005 09:55 (UTC)

What edit war? There's been nothing remotely resembling one so far, though there is certainly a possibility that one could develop. Gene Nygaard 6 July 2005 10:50 (UTC)
If you call that incivility... :) But I don't blame you for being frustrated; sometimes I feel like I'm trapped in a China Shop. Ingoolemo talk 2005 July 6 15:22 (UTC)

Survey

Please comment on this proposed survey. Are there any other questions that need asking? Are there any other options that need to be provided for? --Rlandmann 6 July 2005 12:23 (UTC)

My commments are there. Great idea. -Lommer | talk 7 July 2005 02:05 (UTC)

OK - polls open in 20 minutes. --Rlandmann 09:41, 17 July 2005 (UTC)

Oh man, I hope its not too late. I just thought of something we should throw in - When is the earliest date at which we should revisit the consensus achieved by this survey. (with options of bi-weekly, monthly, 6 months, 1 year, 2 years, >2 years, never). By setting up something like that we can more authoritatively stick to a standard, though we can still evolve (i.e. if the template system gets improved). Can we throw this in now? -Lommer | talk 00:20, 18 July 2005 (UTC)
I just removed the extra question, if only to comply with Wikipedia:Survey guidelines (see #6). In any case, after the survey is complete we will still have to reach consensus on a revised standard to actually adopt; we could try and reach consensus on a "sunset clause" at that time. BTW - I strongly agree that such an agreement would be a Good Thing. Rlandmann 01:15, 18 July 2005 (UTC)
Ok. -Lommer | talk 01:28, 18 July 2005 (UTC)

kW/kg vs W/kg

While there can be little question that the integer values produced by W/kg are far more aesthetically pleasing than the fractions produced by kW/kg, in my experience, the fractions are far more commonly published (not only for aircrfat, but for cars and bikes as well). Why? I don't know - most likely to keep the calculation as simple as possible, but also possibly because many people are used to seeing the fractions produced by hp/lb calculations. Rlandmann 23:51, 17 July 2005 (UTC)

Your analysis seems reasonable to me. With the old units, there are several different units for each quantity. The choice of unit size becomes almost as important as what it is measuring. So people brought up with non-metric units learn that units are matched very strongly with context. That hardly applies in the metric system. For example, we might think we are saying something interesting to tell somebody that a quote of 30,000 feet is about 6 miles, but we would be unlikely to remark that 10,000 m is 10 km.
Fractions such as 0.26 hp/lb as in Bell 206 are inevitable. Because of the nature of non-metric units, we cannot turn it into a non-metric integer without changing the unit into something like 41 BTU·h·oz-1. As you suggest, that may lead to a false believe that kW/kg is also inevitable and is somehow the 'correct' unit. Ironically, my very own argument can be used against me. Because it does not matter so much to get the metric unit 'correct', then I should not worry about it. However, I just thought I would remark that W/kg does seem to be a better default.
As for how common W/kg is, I got the following results from a google survey:
  • 229 w/kg helicopter -wikipedia (47 %)
  • 263 kw/kg helicopter -wikipedia
  • 8,830 w/kg engine -wikipedia (68 %)
  • 4,130 kw/kg engine -wikipedia
  • 4,680 w/kg aircraft -wikipedia (88 %)
  • 612 kw/kg aircraft -wikipedia
  • 25,600 w/kg car -wikipedia (82 %)
  • 5,440 kw/kg car -wikipedia
  • 219 w/kg motorcycle -wikipedia (29 %)
  • 539 kw/kg motorcycle -wikipedia
  • 1,010 w/kg motorbike -wikipedia (54 %)
  • 858 kw/kg motorbike -wikipedia
Read those results how you will. The choice of W/kg or kW/kg is a nuance that we can all work out. Thanks for your good efforts on this survey. Bobblewik 16:48, 19 July 2005 (UTC)

Procedural objections

(moved from survey itself Rlandmann 03:28, 18 July 2005 (UTC))

I strongly object to limiting voting to exclude "Anonymous votes or votes from users with fewer than 250 edits". This is not supported by Wikipedia:Survey guidelines. Gene Nygaard 03:19, 18 July 2005 (UTC)

I object to not having an "either" option or an "other" option for rate of climb. Gene Nygaard 03:19, 18 July 2005 (UTC)

Comment: You had over a week to object to either of those items in the survey, and did not. There is nothing in the survey guidelines that says that voting may not be restricted. I actually took the concept from a couple of other current surveys (here and here). --Rlandmann 03:35, 18 July 2005 (UTC)
As a procedural issue, it is still properly raised. No discussion of placing this restriction was ever held. It doesn't matter if a couple of other votes have placed objectionable restrictions. The guidelines provide specific guidance on limitation of voting:
  • "9. Where there is a sign of activities intended to frustrate the intent of the survey, those who can opine may be restricted. A lack of restrictions is usually best, so this may be invoked after the polling has started."
We have none of those signs here. Gene Nygaard 13:11, 18 July 2005 (UTC)
The restrictions, along with everything else on the survey, were offered up for comment and discussion. Most of the survey (including the two items you're objecting to) were available for comment for a whole week. In almost every case, I accommodated and incorporated the changes that people here put forward. If you had raised your objection concerning rate of climb at that time, I would certainly have built in an "other" option. If you had raised your objection to restricting voting, I would have considered it, but probably not have relaxed it.
Wikipedia surveys (including VfDs) take such measures to head off any potential problems from ballot-stuffing and sock-puppetry. I believe that the discussions here have been sufficiently acrimonious at times to make that a concern. The discussions leading up to the survey, the discussions of the survey, and the course of taking the survey itself have all featured disruptive behaviour (some of it, I regret to say, my own).
Is there some particular reason why you feel that excluding anonymous votes and votes from editors with fewer than 250 edits is a problem? If not, what is the purpose of this objection? --Rlandmann 02:13, 19 July 2005 (UTC)
It smacks of elitism.
I'm not particularly concerned about anonymous votes.
Anyone may vote on Wikipedia:Votes for deletion (see Wikipedia:Guide to Votes for deletion, including anonymous voters.
The rules are more vague on Wikipedia:Categories for deletion (Anonymous users may nominate and comment on proceedings, just as in VfD. Votes from anonymous or new users may be discounted if they lack edit history.) I doubt very much, however, that an interpretation that new users means fewer than 250 edits would fly. It is rare for any votes from logged in voters not to be counted there, at least I have not seen it done, though anonymous votes are sometimes skipped in tallying the results.
There is also that explicit "lack of restrictions is usually best" in the survey guidelines. Gene Nygaard 18:42, 19 July 2005 (UTC)
Even on VfD "Anonymous and new users are welcome to contribute to the discussion, but their votes may be discounted" (right there, on the main VfD page.
I fully agree that a lack of restrictions is usually best, and I have already given my reasons why I felt that they were appropriate in this particular survey. The inclusion of restrictions of this kind is permitted (though advised against) by the guidelines, and in a whole week of being offered up for comment, not a single objection was raised. --Rlandmann 02:21, 21 July 2005 (UTC)
And on Wikipedia:Guide to Votes for deletion it specifically says:
  • "Anyone can contribute to the discussion and vote, anonymous users as well as pseudonymous users."
There are several other procedural issues involved in your attempt to limit voting as well:
  1. Are you going to be the "bad guy" telling people their votes don't count?
  2. Or is there going to be arbitrary and capricious enforcement, with no attempt to determine qualification to vote?
  3. Should attempted votes by ineligible voters be stricken immediately, so as not to influence the votes of "legitimate" voters?
  4. There may in some cases be some room for argument as to whether or not the qualifications are met. Who determines this?
It's a messy can of worms. It never should have been included in the first place. Gene Nygaard 15:02, 21 July 2005 (UTC)

Template didn't work?

Gene - you've voted against using a template because you say it didn't work as Graeme said it would. But the template works exactly as he said it would, for each of the five possibilities you asked about; you can see the sample output here.

You go on to say that you also have a problem with "infexibility in choosing an appropriate prefix". What does this mean? --Rlandmann 03:56, 18 July 2005 (UTC)

I'd like to note that while Gene seems to have a very vocal disagreement with a number of things, they'd be better placed outside of the survey itself on a talk page where they can be discussed. As the statements are not necessarily fact, they could alter survey results artificially. -eric ✈ 04:03, 18 July 2005 (UTC)
Everyone's comments could alter survey results, and Gene is as entitled to his as anyone else is to theirs. "Brief" comments were permitted, and I don't think any of his are overly long. --Rlandmann 04:11, 18 July 2005 (UTC)

Mach maximum speed

(moved from survey development page by Rlandmann 02:50, 19 July 2005 (UTC))

It's been my understanding for some time that virtually all "max speeds" are taken for advertising purposes under ideal conditions (no external loadings, minimum fuel etc.). They're hardly suited to realistic analysis and usually lack flight condition info. Adding mach number worsens the situation, since variable acoustic velocity adds another layer of ambiguity. Using plain old ground-referenced airspeed is good enough, "fun" mach numbers don't help at all. ✈ James C. 02:10, July 19, 2005 (UTC)

P.S. Note that engine thrusts have a similar altitude-variable problem. Quoted max thrust is always ASL, and is much lower than at 40,000'. Giving the max performance value at the ideal altitude is the convention, which should be understood with aircraft speed and engine thrust.

Specification changes

I've made a few suggestions in the survey about changes to the specifications that we report. I thought I'd just offer a few thoughts about each and share my reasoning. In each case, I'm attempting to make what we report more explicit and less ambiguous; and trying to match our standard to what we're doing in practice anyway.

Adding Cruise speed - simply because it's very widely reported, and often available even when maximum speed isn't. This seems to be a pretty uncontentious suggestion, the way voting's going so far.

Specifying Range as Maximum range - in practically every case, the figure we're reporting as "Range" is actually "Maximum range". I'd like us to state that explicitly. Furthermore, if any range figure is available for an aircraft, it's going to be this one.

Specifying Rate of climb as Maximum rate of climb - same reasoning as for range; it's making our common practice explicit. Unless expressed as time-to-altitude, published rate-of-climb is always going to be qualified as "Maximum" or "Initial", which are in every case I can think of going to be the same; and if the published figure is unqualified, you can bet it's still the same figure, for the same "advertising" reason that James is pointing out about speeds in Mach numbers.

Revising weights - Bear with me, this is a little long! The two figures that are almost always available for any aircraft are an Empty weight and a Maximum Take-Off Weight. In published sources, the latter of these may or may not be the "Maximum gross take-off weight" in the strict sense, and often may represent a military aircraft in an overloaded condition [1]. Our "Loaded weight" (aka "Normal" or "Typical" in other sources) is mainly a carry-over from the fact that this infrequently-published specification is mostly found in detailing historic military aircraft; and Wikipedia has had a strong systemic bias towards those types. As our aircraft coverage has expanded and broadened, this statistic is relevant in fewer and fewer instances, suggesting to me that we should part company with it, or, at the very least make it optional. I'm also suggesting that when we have access to a weight figure that is explicitly qualified as an overloaded weight, we make provision for including this. Following on from this is the suggestion that we make our wing loading, power/mass, and thrust-to-weight specifications follow convention by using "Maximum gross take off" weights, and in the case of wing loading, making this explicit by re-labelling it "Maximum wing loading". --Rlandmann 04:16, 19 July 2005 (UTC)

[1] hence my suggestion to make the label for this specification more explicit as "Maximum gross take-off weight" - I'm suggesting this not because I think it's a distinction of the slightest use or interest to our readers, but as an aid to other editors, to help ensure that we're all on the same page when supplying figures.


Contrary to your claims above, the loaded (normal, typical) weight remains as relevant to as many Wikipedia articles as it ever did. Adding more articles which do not include this information doesn't change that fact. There is no reason to throw this information away.
Are the rate of climb figures normally based on time to reach a certain altitude (it seems that it is often either 5,000 m or 10,000 ft)? In what other circumstances are they sometimes measured?
I don't see that "gross" adds anything of value to "maximum takeoff weight"; it might even make it less clear.
Add cruise speed.
Another suggestion: replace Capacity with context-specific descriptions of the quantiy being given there.
If, as you now claim, there are no standards for the calculated measurements such as wing loading and power or thrust to weight, and we could just willy-nilly change our standard for calculating this from "loaded weight" to "maximum takeoff weight", then I'm changing my vote to not include those calculated measurements. Gene Nygaard 15:04, 19 July 2005 (UTC)
1. Perhaps my choice of words was not the best regarding "loaded weight". While a loaded/typical/normal weight may be available for "as many Wikipedia articles as it ever did", these represent a smaller and smaller proportion of our coverage. Just because a piece of data is available does not make it relevant (let alone valuable) to a particular article, let alone to our aircraft coverage as a whole.
2. Where rate of climb is given as a time-to-altitude, it is because the measurement was specifically taken that way; because this altitude was relevant to the aircraft's mission and/or to provide a standard basis of comparison with other aircraft. Many different altitudes have been used by many different organisations in different places and different times.
3. What's the problem was with using capacity to refer to different things for different aircraft, as long as what's being carried is clearly spelled out?
4. Where did I claim that there are or are not standards for calculated measurements? I merely observe that the long-standing Wikipedia standard for these things (based on "loaded weight") is unconventional. Most other publications will give values based on maximum (gross) take-off weight (or sometimes for military aircraft a notional "combat weight" - no doubt the origin of our standard). Changes must never be made willy-nilly, but in a concerted, consensual, and explicit fashion. --Rlandmann 16:42, 19 July 2005 (UTC)
My concern with a "Capacity" line isn't so much difficulty of readers in understanding what is there, when something is there, "as long as what's being carried is clearly spelled out" except that we don't have any guidance for doing the latter.
But what about all those cases where we don't have anything there, at least yet? And, why don't we?
The bigger concern is that we don't have any guidance for editors as to what "capacity" means here, no guidelines for what is to be included. Sometimes we don't get anything, because it isn't clear what we want to get.
One type of "capacity" that all aircraft share is the number of crew to operate them (zero in the case of drones). Is that what we want here? It is what we get, at times. How about the capacity for fuel of the aircraft? We sometimes get that, too, in terms of mass or volume of fuel. Is that what we want? What about fuel as cargo, in the case of tankers?
There is also passenger carrying capacity for many aircraft, probably the easiest to understand and enter. Then there is cargo capacity--which in itself takes a myriad of forms: the capacity of the cargo area in volume units, the cargo capacity in mass units, the cargo capacity in standard containers for particular types of cargoes. In military aircraft, it might be mentioned as specific large items such as tanks.
Beyond that, there are lots of other capacities depending on the specialized function of various aircraft. Gene Nygaard 23:53, 20 July 2005 (UTC)
Whether these discussions lead to small changes in the standard or large changes, the instructions at page content should be overhauled, and this is certainly one area that could do with some attention.
Of course, new editors don't generally read the instructions before making a contribution (neither should they!), but copy formatting from some other article (or use their own, in which case the point is moot). This is one of the main reasons I'm wary of too many optional fields as part of a standard, as well as making unit conversions "permitted" [1]. As long as they're copying from another article that has a "Capacity" section, they should be able to see what's being asked for.
The alternative would be to create a number of optional fields to replace "Capacity". "Passengers", "Cargo", "Troops", "Stretchers", and "Tankage" would cover most but by no means all the possibilities. One of the problems with this is that a large number of aircraft carry a combination of these things. At the moment, this is very easily dealt with as "Capacity: 12 passengers, 4 stretchers, or 900 kg (2,000 lb) of cargo". I think that itemising them separately probably makes it less clear that these items are alternative loads. And, as you point out, aircraft carry a huge variety of things, and an itemised approach removes the flexibility that this area demands. Our "Armament" section is similarly broad, for similar reasons.
We can't become overly concerned with what some editors may do. You've already noted that sometimes crew are noted as "Capacity", even though already has its own field. Even if provided with a large variety of optional fields to choose from, someone will no doubt still enter something somewhere where it's not what's being asked for. Most people attempting to use the standard layout for the first time still seem to understand what "Capacity" asks for, most of the time. That may be the best we can hope for. --Rlandmann 02:09, 21 July 2005 (UTC)
[1] Then what happens is someone makes changes to the specifications section of one article, which is copied by someone else who changes it again...
All these problems are tied in with trying to shoehorn this into a "one-size-fits-all" box. Among other things, this leads to a failure to use the advantages a list has over an infobox. A bulleted listing at the second level would take care of many problems such as that, or variations among different models of the same aircraft, but we've had little or no discussion of doing so and of how to best take advantage of those options. Gene Nygaard 15:10, 21 July 2005 (UTC)

Rate of climb

Even despite the fact that the vote page claims that m/min has been the standard metric units for rate of climb, there are at least 20 Wikipedia articles which now express this in m/s (and not more than a couple of them at the most added by me). Several, in fact, express this only in meters per second.

One of the main reasons for this is that the technical guidelines for the use of the International System of Units in particular applications, as the basic SI framework is fleshed out by various international and professional standards organizations, attempt to reduce complexity and geographical variations in usage by discouraging the use of minutes (which are not SI but are listed as acceptable for use with SI) in the denominator of various time-dependent measurements, and recommend that only seconds (the SI units) or hours (also acceptable for use with SI) be used in this context. You see the same thing in irrigation, for example, with rates expressed in the Wikipedia article as in the real world in U.S. gallons per minute, but in liters per second in metric units. Gene Nygaard 15:04, 19 July 2005 (UTC)

Just in case anyone else was similarly confused, options noted as the "current standard" in the survey are those that are currently called for in the project's page content guidelines. --Rlandmann 16:51, 19 July 2005 (UTC)
I think it is a bit late to be complaining about the options available. I forgot about the W/kg issue until after the survey started but I was lucky in that there was an Other option. Similarly I forgot about the m/s rate of climb issue but that is my failure. I think if I were more aware about it, I might ask politely if I could add the extra option. I would welcome what Gene might have to say on the subject, particularly if tactfully expressed. Bobblewik 17:23, 19 July 2005 (UTC)
Agreed, that's what current standard meant. The point I was making was that despite this "standard", we still have many Wikipedia articles using m/s, and we'd probably have many more without that.
1. For example, Russian Aircraft Corporation doesn't list rates of climb for the MiG's, but it does have this for the [Aviatika-MAI-890]:
  • Maximum rate of climb "Aviatika-MAI-890/890U/890SKh", m/s 4,8/3,5/4,75
2. http://www.noaa.inel.gov/capabilities/bat/pdf/SkyArrow.PDF
TECHNICAL SPECIFICATION OF THE ... SKY ARROW 650 TCN or 650 TCNS
                                   650 TCN           650 TCNS
     Rate of climb, sea level   3.6 m/s (700fpm)  4.3 m/s (850fpm)
3. http://www.pnl.gov/atmospheric/programs/raf_g1.stm
Gulfstream-1 Research Aircraft
  • Nominal rate of climb: 500-1000 ft min-1 (2.5-5 m sec-1)
4. Sloop, John L., Liquid hydrogen as a propulsion fuel, 1945-1959. (The NASA history series) (NASA SP; 4404), Part II : 1950-1957, chapter 7. New Initiatives in High-Altitude Aircraft http://www.hq.nasa.gov/office/pao/History/SP-4404/ch7-10.htm
  • Rate of climb at sea-level, m/s     8.9
Of course, m/min are also used. But as I said above, the conventional way of reducing variations and achieving more consistency in metric usage is to eliminate minutes in the denominator. Gene Nygaard 18:17, 19 July 2005 (UTC)
I don't know the whole story but I have seen m/s used for glider and helicopter specifications. It may even be the default for European glider variometers. If we can define circumstances where m/s is common, then that would help the debate. Bobblewik 20:00, 19 July 2005 (UTC)
Here are results of a google test:
  • 6,750 helicopter climb m/s (92 %)
  • 566 helicopter climb m/min
  • 3,590 helicopter descent m/s (96 %)
  • 159 helicopter descent m/min
  • 22,300 m/s take-off aircraft -wikipedia (83 %)
  • 4,690 m/min take-off aircraft -wikipedia
Bobblewik 20:55, 20 July 2005 (UTC)
Ironically, I added a lot of the 'm/min' values into Wikipedia articles. Bobblewik 21:24, 20 July 2005 (UTC)

← back to margin Of course, many of those hits are from wikipedia, and many of them are "empty". In other words, just the specifications list has been added, with units included, but no numbers entered for many of these "rate of climb" entries. However, here is a quite interesting variation on your Google search. Pay attention to the difference in the ratios when those containing the word "Wikipedia" (which will include what is at Wikipedia plus many sites that copied the information from here and properly attributed it) are excluded.

Google hits
helicopter climb ft/min m/min 1210
helicopter climb ft/min m/s 641
helicopter climb ft/min m/min -wikipedia 558
helicopter climb ft/min m/s -wikipedia 628

See the difference? Of course, there are other variations such as ft/s as well, and many pages which only have m/min or m/s, the difficulty being that searching for just "m/s" itself will get more false hits. (Note that Google doesn't search for the slash or other punctuation marks, but when they are entered it uses them to make it like a search for "m s" as an exact phrase, and when it is individual letters, they also consider it a hit without a space between them, I think). Gene Nygaard 00:16, 21 July 2005 (UTC)

Abbreviation of knots as kt

Discussion moved from User talk:Bobblewik

Response to request to vote for kt
nope. the FAA uses kts, and i'm an American pilot who has only ever seen kts or kias in practical use. -eric ✈ 14:49, 20 July 2005 (UTC)

Neither form is 100%. Google special search 'US government' results:
  • 14,800 weather.gov kt -kts (98 %)
  • 325 weather.gov kts -kt
  • 121,000 noaa.gov kt -kts (75 %)
  • 39,700 noaa.gov kts -kt
  • 366 faa.gov kt -kts (59 %)
  • 253 faa.gov kts -kt
  • 39,500 kt -kts speed (62 %)
  • 24,600 kts -kt speed
  • 459 kt -kts airspeed (42 %)
  • 636 kts -kt airspeed
  • 11,400 kt -kts windspeed (46 %)
  • 13,500 kts -kt windspeed
  • 98,000 kt -kts wind (73 %)
  • 36,000 kts -kt wind
  • 43,200 aircraft kt -kts (82 %)
  • 9,680 aircraft kts -kt
The current METAR for Seattle uses the internationally agreed (ICAO) form 'KT':
  • KSEA 201456Z 22004KT 10SM SCT012 14/13 A3004 RMK AO2 SLP177 T01390128 51014
The current TAF for Seattle uses the internationally agreed (ICAO) form 'KT':
  • KSEA 201138Z 201212 VRB03KT P6SM FEW006
    • FM1800 26006KT P6SM SKC
    • FM2100 34008KT P6SM SKC
    • FM0400 03006KT P6SM SKC
Do you not use METAR's or TAF's? It would also be reasonable for Wikipedia to consider the abbreviation in use outside the US. Bobblewik 15:40, 20 July 2005 (UTC)
I agree with you on this, Bobblewik. However, the METAR format as a supposedly compact coded format using a really crippled character set, and it isn't that reliable an indicator of the proper symbols. Though many contries do use knots (all who do using the KT identifier), the actual international standard for wind speed is metres per second—and I don't think Bobblewik would recommend that the Wikipedia use the METAR standard for identifying those units: MPS. Some countries also use KMH (i.e., km/h in normal symbols) for wind speed in METAR reports (don't know who, but it is logical to conclude that the symbol is defined for a reason).
The Wikipedia:Manual of Style (dates and numbers) has said that symbols for units of measure should not be changed by adding an "s" in the plural since long before I started editing on Wikipedia. Thanks, Bobblewik. But even though you put that there back in April 2004, the fact that it has remained there continuously for the past 15 months is a good indication that there is general consensus for this rule, and I don't remember ever even seeing any discussions about changing that so far. There is no good reason for this project to go against the MoS guidelines, either.
Of course, knots are also among the units listed as acceptable for use with SI, and as such should follow the general rules such as those in NIST's Guide for the Use of the International System of Units (SI), §6.1.3:
  • "Unit symbols are unaltered in the plural."
Note that NIST, in listing the knot as acceptable for use with SI, does not list an official symbol for these units. One thing we can be sure of, however, is that the reason does not hinge on whether or not to add an "s" to "kt". Rather, the other options are "kn" (less common than kt but still used to a significant extent), "knot" as a symbol (unchanged in plural; compare the nons-SI erg as the normal symbol for ergs, or Torr as the symbol for torrs and Gal as the symbol for gals), and always spelling out "knot" as a word, which does add an s in the plural. Maybe even "knt" at times. Gene Nygaard 18:10, 20 July 2005 (UTC)

I do use both METARs and TAFs, but I don't use them as sources for my units. What I do use are FAA documents relating to airspeeds and other reference texts. Regardless, rather than reverting to a ridiculous abbreviation like kn or knt, we could take the extra two letters and simply spell out 'knots' in full form, as knots itself is an abbreviation of nautical miles per hour. This would not only end the debate, but it wouldn't go against SI 'policy'.

Also, since we're on a METAR kick here, if anyone can explain how m/s is useful for wind speed (when the ICAO airspeed is measured in km/h) I'd really appreciate the enlightenment. Just to point out that ICAO isn't flawless. -eric ✈ 02:35, 21 July 2005 (UTC)

  • addition: in response to lommer's decision which was based on the canadian meteorological ministry - their own Transport Canada lists kts as well as kt quite often in the CARs and elsewhere. With the world's lack of standards (this is not an america-only issue) I feel this increases the need to skip an abbreviation altogether and am changing my vote from kts to knots, spelled out. -eric ✈ 02:55, 21 July 2005 (UTC)
I agree with Ericg that the full form of 'knot' is better. I have always written it in full in my edits. I have also modified the inconsistent forms (kt, kts, kn, knt, knts) to consistently use the full form. My vote for kt was a second preference but I thought that a vote for the full form might be 'wasted' and the 'kts' option would succeed. I am opposed to 'kts' on the principle that unit abbreviations should be unchanged in plural in all languages (note that 's' is not the plural in other languages). I am willing to reconsider my vote and would accept either 'knot' or 'kt'. I like to see more discussion. Bobblewik 10:25, 21 July 2005 (UTC)

Infobox or list

Ericg, who for some reason not clear to me despite his repeated discussion of it, detests infoboxes, has asked if I'd explain my reasoning for supporting them here. Basically, it boils down to this.

  1. I don't see why he thinks there'd be any more difficulty in expanding an infobox than in expanding a list.
  2. We don't use the advantages lists might have.
  3. I like my information in columns. I don't care if it is an infobox covering part of the right of the page at the top, one at the bottom whose width expands as necessary, with lines or without lines, with colors or without colors. I mostly just like the columns. I like all the meaurements in a column, for example, specially when we express many of our measurements in dual units. If we use templates, we can even get the appropriate left/right/center justification in each cell. Gene Nygaard 13:45, 23 July 2005 (UTC)
I thought I'd been fairly clear on why infoboxes are an unacceptable option, including in the survey discussion. Since I haven't, I'll put it in a numbered list for you.
  1. They break page layouts. This is fairly important considering many articles have photos or other information tables like our standard footers.
  2. They screw with editing flow. The first thing a new user sees is a giant mess of wiki table code.
  3. They look unprofessional. Every major aircraft reference I've ever seen uses a format similar to the list-based one we use.
  4. They don't work on mobile devices, a growing portion of internet users.
  5. They don't work on small screens, a major portion of existing internet users.
  6. Data often splits up into two or more lines in a ridiculously small space. This affects readability as well as attractiveness of flow.
If I come up with more, I'll add them. Also, I didn't ask why Gene supported infoboxes. I specifically asked, what is your concern with our current implementation of the list format, and why have you not actually raised any of them with the project? Gene, you say that we "don't use the advantages lists might have" — you've never, here included, explained what these advantages might be. So, because you didn't answer last time, or the time before, what are these advantages? If you're keeping them secret because you like columns... -eric ✈ 15:52, 23 July 2005 (UTC)
7. They don't work well with screen readers. Bobblewik 18:14, 23 July 2005 (UTC)

On not using the advantages of a list: The biggest advantage of a list is flexibility, not having to fit the information into columns in a way that keepps a reasonable column width, for example). Yet those advocating this format are the same ones pushing for parameterized templates which would throw out much of that flexibility even in the rare cases where it is already used.

For example, when the old "standard" list was copied and pasted from its page, it was a simple matter for editors to change "Capacity;" to a more appropriate description for the particular context.

With a cut and past list, it was easy to add additional specifications relevant to that particular aircraft. With parameterized templates, that will be nearly impossible.

It might be possible with parameterized templates to add multiple types of capacities, or engine alternatives, etc. But even if it can be done, the learning curve for using templates with the proficiency to accomplish that is steep, and might involve tricks and workaround methods of using the templates.

What we are likely to end up with is a situation where no non-regular contributor and very few regulars will ever add information in the format we want, and it will be one or two or three people doing all of the adding of these parameterized-template lists. That is somewhat problematic even for something like the chemical elements, where there are a limited number of Wikipedia articles and much more uniformity in the available information. Gene Nygaard 13:51, 27 July 2005 (UTC)

Gene, as far as the inline list-based non-parameter format, we've already switched. We're already using the advantages you cite. Specifications in new or converted articles are not limited to small spaces. Finally, if someone is able to add a line to the existing non-parameter format, they can do it to the templates. All that's necessary is to close the "alt=" field in the parameters with a ), create a new line leading with a *whatever: x mph (x km/h - and leave the closing ) off. Voila (note "Bogus figure"). It's even possible to add instructions to the template explaining this sort of thing. -eric ✈ 17:44, 27 July 2005 (UTC)