This is an archive of past discussions about Template:Infobox airport. 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.
This uses the new {{coord}} template, which has three options for display:
display=inline – display the coordinates inline (default) (replaces {{coor dms}})
display=title – display the coordinates by the article title (replaces {{coor title dms}})
display=inline,title – display the coordinates both inline and at title (replaces {{coor at dms}})
In December it was announced that Wikipedia articles would show up in the Google Earth Geographic Web Layer if they contained "{{coor title d[ms]}}" or "{{coor at d[ms]}}" templates. Additionally, Google supported references to those two templates as well as "{{coor d[ms]}}" if used in an Infobox and assigned to a parameter named either coordinates or coords.
In June it was reported that Wikipedia articles using {{coord}} would also appear, but only if the title keyword is used. The reason given was it "indicates that the coordinates explicitly refer to the location of the title article, rather than another geographic location that may appear in the article text". It also stated that Google Earth would not pick up articles using {{coord}} with "display=inline". Unfortunately, no mention was made whether "display=inline" would work if used in an Infobox, as was the case for "{{coor d[ms]}}" (users later discovered that it did not work). That update stated "at the present time, Google recognizes other Wikipedia templates. However, Wikipedia has deprecated these older templates. You should use {{coord}} instead."
Using {{coord}} with title in {{Infobox Airport}} causes one of the following results:
display=inline,title – displays coordinates on right side of article's title area directly above infobox AND again inside the infobox.
display=title – displays coordinates above the infobox, but leaves an empty cell inside the infobox (see this example).
Both options also cause the coordinates to use the small font size of the infobox text (which is made even smaller because the title area text uses font-size:85%):
I believe the best solution is to use display=title, since the coordinates will appear directly above the infobox and displaying them again inside the infobox is redundant. However, this should be done in conjunction with moving the {{coord}} template out of the infobox, to eliminate the problems of an empty cell in the infobox and tiny coordinates in the title.
Even ignoring the Google Earth issue, I would still recommend these changes, because they give the airport article a neater look with the new globe icon (which caused the coordinates to occupy two lines in the infobox).
What follows is an abbreviated version of the suggested template code. The results can be seen at Paris Beauvais Tillé Airport.
{{coord|49|27|16|N|002|06|46|E|type:airport|display=title}}
{{Infobox Airport
| name = Paris Beauvais Tillé Airport
| IATA = BVA
| ICAO = LFOB
| type = Public
| city-served = [[Paris]]
| coordinates = <!--listed in title-->
... etc.
Of course, the coordinates parameter could also be left blank or omitted entirely.
Is it wrong to have the information listed in the Infobox and the title area when using {{coord}} with display=inline,title? I think it looks fine. Keep the coordinates within the infobox. If the text size is an issue, perhaps it can be taken up with as a discussion in the {{coord}} page. papageno01:58, 6 November 2007 (UTC)
I'm just seeking some clarification after some edits of mine were reverted. I was under the impression that we were only attempting to have one set of coordinates per airport article... ie in the infobox not at the top of the page as well?? Or am I following old news? I was informed that the mapitaus template is relevant to all Australian Airport articles?? However from my work on the Australian Airport pages I've only seen it attached to one airport article Perth Airport so I have to ask that if it's only on one Aussie airport why that statement?? Opinions?? MEBpilot (talk) 09:58, 23 December 2007 (UTC)
The Perth Airport article you mentioned used Template:Mapit-AUS-suburbscale, one of the Geolinks templates which display the coordinates at the top of the article (and until recently also displayed direct external links to a select group of mapping web sites). There was a move at one time to remove all the Geolinks templates from the airport articles, since the coordinates could be found in the infobox. For more information, see the comments above in the section titled Moving coordinates out of the infobox. -- Zyxw (talk) 10:24, 22 January 2008 (UTC)
To expand on my comment that the Geolinks templates "until recently also displayed direct external links", the following shows how {{Mapit-AUS-suburbscale|long=115.956071|lat=-31.94335}} previously displayed:
In November 2007, that template (and others) were changed to remove the list of map links. {{Mapit-AUS-suburbscale}} currently generates the following:
The template currently allows for a maximum of four lines under the "Statistics" heading. That was based on articles using the old {{Airport infobox}} templates where editors had manually added the current statistics. However, the user can specify both the header name and the data, allowing for other possibilities as seen in your example at Tallinn Airport. My personal preference is to show only the current statistics in the infobox and place the historical statistics in the body of the article, as can be found in Singapore Changi Airport, Perth Airport and others. -- Zyxw (talk) 10:24, 22 January 2008 (UTC)
I wanted to have the zip and area codes in to be consistent with the infoboxes for cities. I guess they aren't needed for airport infoboxes. Socal gal at heart (talk) 06:08, 7 March 2008 (UTC)
If the postal and area codes are the same as for the city, that information should be just one click away. If it is different, then it is better displayed within the article itself, probably in the form of listing the airport's full address and/or telephone number. -- Zyxw (talk) 06:26, 7 March 2008 (UTC)
20 April 2008 template changes
This template was originally designed as a replacement for the multi-template {{Airport infobox}} and therefore designed to have the same appearance as the old-style template. A recent edit on 20 April 2008 made a few minor changes that caused a noticeable change in the infobox.
The table class "infobox bordered vcard" was changed to "infobox vcard". This eliminated the border previously displayed between the rows and columns of the table (see the prior version with borders) and also increased the spacing between table rows due to the elimination of border-collapse: collapse; (defined in MediaWiki:Common.css under .infobox.bordered).
The base font size was changed from 80% to 90%. The effect of the larger font was even more apparent in the section headers, which still used font-size:120%.
The edit also removed {{Template sandbox notice}}. That was originally included to allow the entire template to be copied to or from Template:Infobox Airport/sandbox without editing.
I have made the following changes:
The table remains in the borderless mode since it has been that way for almost a month now without any complaints. However, line-height:160% has been removed from the table style, since it is was there to increase the line-spacing in bordered mode.
The base font size was decreased slightly to 88% (also used by Template:Infobox) to provide a more consistent appearance across different browsers (90% was causing larger text in Internet Explorer than in Firefox). The section headers now use font-size:115% and the footnotes use 90% (previously tried font-size:larger and smaller but this also caused inconsistencies, specifically larger section headers in Firefox than in IE).
The {{Template sandbox notice}} has been restored, along with a comment explaining why it is there.
Prior to the recent change, I didn't see a need for a mass-conversion of the old infoboxes because the appearance was the same. However, if this template retains the borderless design, it might be a good idea to convert the old templates. -- Zyxw (talk) 06:55, 18 May 2008 (UTC)
I noticed that several infoboxes have automatic conversions for m/ft. Would it be possible to do that with this box? Either without breaking the way it's set now or having a bot run through and update the 5,000+ articles that are using the template. CambridgeBayWeatherHave a gorilla16:47, 29 June 2008 (UTC)
I'm working on it. The default is currently to display feet first for both length and elevation. Are we going with this? JIMptalk·cont08:34, 8 August 2008 (UTC)
If possible it should default to feet first for elevation and meters first for length. The US and Canada are the only countries that that still use feet for runways. For elevations there are only a few Asian and a couple of east European contries that use metres first. CambridgeBayWeatherHave a gorilla09:56, 8 August 2008 (UTC)
It's certainly possible. I'd want to do it by replacing the parameters metric-elev and metric-rwy with a different parameter, e.g. system or units. The new parameter would be set to a specific value for feet first always and a different one for metres always first. This would, however, require a bot's going through and adding the new parameter wherever necessary. JIMptalk·cont16:02, 9 August 2008 (UTC)
Just want ot be clear. The template would be broken on a temporary basis until the bot updated it? Also when the bot makes the change over would the article still show the same order as it does now? In other words if a French airport currently shows the elevation in metres first would it still show that after the bot is finished? CambridgeBayWeatherHave a gorilla22:30, 9 August 2008 (UTC)
It wouldn't be necessary to let the template go broken: a transitionary version, which would be able to handle either input, would be put in place whilst the bot is running. JIMptalk·cont13:54, 10 August 2008 (UTC)
What about the second part? If the airport is currently showing an elevation in metres now, would it still be that way after the bot has finished? The thing is, with the way bots/bot owners have been treated in the last few months, I really don't want to be making things worse for them. CambridgeBayWeatherHave a gorilla16:39, 10 August 2008 (UTC)
It would be done in such a way that there'd never be any visible difference on any article (except, of course, where the article was wrong in the first place—this would probably have to be done by hand). The bot would run in three (or two) phases looking for metric-elev and metric-rwy and swapping them for the new parameter. In the first phase it would add the new parameter (set to feet, imp, us) to those feet-feet (the Canadian & US) articles—which ones these are shouldn't be hard to determine automatically: those with neither metric-elev nor metric-rwy. Then the transitionary version would be put in place. In phase two it would deal with the metre-metre articles, replacing metric-elev and metric-rwy with the new parameter (set to metres, meters, metric); again these would be easy to determine automatically: those with metric-elev (and metric-rwy). After this the new version of the template could be put in place. In the third stage all the remaining occurances of metric-elev and metric-rwy would be removed (from the metres-feet articles). Stages two and three could be done simultaneously (thus the "(or two)" above). JIMptalk·cont08:34, 11 August 2008 (UTC)
The template links to the the articles Metre & Foot (length) up to three times. Should it even link to such common English words once? WP:OVERLINK would suggest not. JIMptalk·cont08:31, 8 August 2008 (UTC)
Should the infobox be excluded from print? I understand nav or stub templates, but as far as I know, generally infoboxes are being included, as they contain valid summary info on the article. - TrevorMacInnis (Contribs) 16:09, 27 March 2009 (UTC)
It doesn't appear to, and I believe that support needs to be added, otherwise it may be difficult or even impossible for any article using this infobox to pass an FA review. Unfortunately, I don't know how to do this myself; if someone with better knowledge of template syntax than I can add it, it would be much appreciated. Ron2K (talk) 10:51, 23 December 2009 (UTC)
I've added it to the sandbox and tested on the test cases page; it appears to work. Could someone else confirm that it works, and maybe perform a sync if it does? Ron2K (talk) 11:01, 23 December 2009 (UTC)
Hi, I have drafted a version of this which adds a parameter to list what airlines the airport is a hub or focus city for. Personally, I think this would be a useful addition. The draft is located at User:Ishwasafish/Sndbx 4 Infobox Airport. Thanks,
Have you tested this thoroughly? It doesn't seem to allow both hub and focus to be used ("=yes" I presume?) at the same time, and a third parameter "airline" must be used to list the airlines, which isn't an easy way to do this. I'd also ask for some input from the Airports Project before implementing this.- TrevorMacInniscontribs23:22, 16 August 2009 (UTC)
Both hub and focus city could be used, it would be similar to in Airline articles, where you would list the individual airport that was a focus city or hub for the airline. Here is an example for SFO:
Done. I saw the mixed reactions to the focus-city but decided to add that as well. If there turns out to be a problem with that parameter it can easily be removed. Would you please update the documentation page now? — Martin (MSGJ · talk) 18:31, 17 August 2009 (UTC)
Good question. I'm not too familiar with how this version came about, but I'll try a sandbox version without the junk and see if it still works. If it does then they should be removed. - TrevorMacInniscontribs23:25, 2 December 2009 (UTC)
Hi, just a small request to change the hub parameter from hub for to Hub/Base for, as there are quite a number of airlines which have -hub-like- operations, yet dont refer them to hubs, but they refer to them as bases. A few examples are Ryanair, Spirit Airlines, JetBlue Airways, V Australia and Regional Express Airlines, just to mention a few.
I think Spirit, JetBlue, and Ryanair]] is already listed in the hub parameter that their bases. I think I would go for changing it to "Hub/Base for". Snoozlepet (talk) 16:22, 28 December 2009 (UTC)
This is a continuing concern. Many airlines do not use a hub system. Home base and focus city are just as important as hubs due to the increase of airlines using the alternative model. The percentage of traffic on these is huge now. The only argument I have seen against including additional parameters is that editors are worried that it will cause edit wars since some people get all bent out of shape when an airline isn't noted. A simple fix to that is making sure we stay make sure there is verifiability from reliable sources (kind of a big part of Wikipeida :) ) In regards to confusion, a Wikilink can take care of that. Cptnono (talk) 00:41, 29 December 2009 (UTC)
Bases and focus cities are just as important as hubs and generate a good amount of traffic as the industry has changed and airlines have not used the hub system. Maybe no parameter at all would be appropriate if the length is a concern.Cptnono (talk) 08:42, 29 December 2009 (UTC)
Again the encyclopedic nature of the information needs to be established. Hubs are definable. Bases is ambiguous. If we expand to what is being requested, I can see major confusing problems with helicopter airlines. Vegaswikian (talk) 18:54, 29 December 2009 (UTC)
If a source calls it a focus city or home base than it is definable. If a source doesn't say it then it can't be included per Wikipedia's standards. Hubs are still important but their prominence in the industry has diminished.Cptnono (talk) 21:52, 29 December 2009 (UTC)
One suggestion is Airline hub/base for, as to make it clear the infobox is for Airlines only, and to prevent listing General Aviation/Helicopter companies in the infobox. Sb617 (contribs) 02:20, 30 December 2009 (UTC)
I don't see why airlines like Air Transat and Skyservice can be counted in the hub parameter of Canadian airports but WestJet is not. Although WestJet doesn't technically use the term "hub" it transfers passengers at these airports and base all their crews and planes out of them. Whereas Air Transat has no connecting passengers, just point-to-point service, how is that a hub? Thankyoubaby (talk) 22:46, 9 January 2010 (UTC)
Adding parameters to infoboxes is often considered controversial, so I would ask you to leave this request for a few days to see if anyone has any comments. — Martin (MSGJ · talk) 07:40, 17 March 2010 (UTC)
Sorry about the delay. If possible, could "GPS: {{{GPS}}} –" be added. Most airports have a GPS identifier as they are now becomming more popular on newer planes. Thanks. Kevin Rutherford (talk) 18:49, 4 April 2010 (UTC)
Wikipedia is an encyclopaedia and not a catalogue, and so it seems strange not to have any historical information in the infobox apart from the parameters built and used which are, according to the documentation, only for military airports. Many public and private airport articles include the date or year the airport was opened, and most defunct public and private airport articles include the date or year it was closed. These two parameters (opened and closed) are included in the template Infobox station, and the information is just as valid and important for airports as it is for stations. Coyets (talk) 11:12, 18 May 2010 (UTC)
I checked the archives, and discovered that the parameter 'opened' was added and deleted again twice in 2005, and was proposed again in 2007 but rejected because the year that an airport was opened is not always clear. However, when I look at airport articles, the fact that no historical information is included in the infobox makes the articles, especially the shorter ones, seem like catalogue entries which sometimes have a 'History' section tacked on. Reading through the history sections, it seems that the year the airport was opened is very often clear, and the articles are often included in an establishments by year category. The fact that many airports do not have a clear year of opening does not make this information any less important. Coyets (talk) 11:37, 18 May 2010 (UTC)
The parameter would be optional, so the fact that it's available for all airports shouldn't stop it being used for those where the date is unambiguously known. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits11:42, 18 May 2010 (UTC)
It should be available and it should be done in the same style as {{Infobox settlement}} in that there is the option for multiple dates along with the title. Then you could have things like the following;
| operational_title = Construction started
| operational_date = 2000
| operational1_title = First flight
| operational1_date = 1 January 2005
| operational2_title = Official opening
| operational2_date = 1 February 2005
| operational3_title = Construction complete
| operational3_date = 2006
As Andy Mabbett points out these would all be optional so if some/all dates are not known then they won't appear. It should be clear though that these are for the airport and not for the construction of a new terminal at an existing airport. Enter CBW, waits for audience applause, not a sausage. 15:02, 19 May 2010 (UTC)
I had a look at the source of {{Infobox settlement}}, but I do not consider that I have sufficient experience in editing infobox templates to be able to add anything like that. So, would it be possible for someone who is more familiar with the syntax to add such optional parameters? Coyets (talk) 12:01, 6 July 2011 (UTC)
{{editprotected}}
The recent addition of a line break before the recently added GPS and WMO airport codes creates a blank line in the infobox on some airport pages. This can be fixed by replacing:
all instances of [[Foot (length)|ft]] be changed to ft
in accordance with WP:OVERLINK. These well known units of measurement, especially in terms of the context, are never likely to be unfamiliar nor ambiguous, and should be removed. Ohconfucius¡digame!08:50, 4 July 2010 (UTC)
{{edit protected}}
Is it possible to add the following fields:
owner-contact (displaying the contact's name)
owner-telephone (displaying the contact's telephone number)
operator-contact (displaying the contact's name)
operator-telephone (displaying the contact's telephone number)
These would be sub-fields of the current owner & operator fields, and data should display only if those fields are occupied, and then without a field label.
Example (current operator field with additional data)
Airport Flying Service John Smith - Manager 555-555-5555
Or, can you suggest a work-around to display this information beneath the existing owner and/or operator fields?
I really don't think that we should be providing the phone number for airports. I'm sure that the owner of Essex/Billing Airstrip would not really want his phone number published in Wikipedia. Also I'm not convinced that there is any encyclopaedic value in providing the numbers. I checked a few and while some numbers may lead you directly to the airport authority others do not. For the most part there is a link to the airport website and contact information can usually be found there. I looked at Edmonton International Airport, their contact page and Canada Flight Supplement (CFS). The phone number for Edmonton Airports in the CFS is different from any listed on the contact page. Enter CBW, waits for audience applause, not a sausage. 13:17, 29 September 2010 (UTC)
I don't agree that owners would not want a number published, but I can understand its lack of encyclopedic value, somewhat. I do see it as an 'Information Box', which probably should provide some information rather than make the viewer search for it. Regarding an airport, often the owner is a government entity, and there probably is a pertinent contact person that has a number. In the case of smaller, public airports, the owner and operator may be one and the same, also having a specific contact person. My request was only to offer these options in the template for the wide variety of situations found. Yunchie (talk) 13:51, 29 September 2010 (UTC)
OK, I can see the point of the 'no phone number' in the reference that you provided. As it doesn't specifically prohibit a 'Contact Name', I can change my request to just that. I can offer support for this with the example that a school might list the name of its principal. Perhaps, instead of the phone number, a separate field for the title would be more appropriate instead of the method that I used as an example above. Yunchie (talk) 01:36, 30 September 2010 (UTC)
I was going to do this but I was unsure about something. What is the purpose of the <code>, </code> as the don't seem to appear on the page? Also I noticed that the other sections below this one also use the first style. Do they need updating as well? Enter CBW, waits for audience applause, not a sausage. 15:49, 29 December 2010 (UTC)
A lot of airport article infoboxes have a {{Location map}} included via the rather hacky method of putting it in one of the airport code fields - see for example the Heathrow or JFK articles. I suggest that we add code to the template to do it properly, as it is done in {{Infobox settlement}}. This would mean having separate parameters for longitude and latitude which would generate the {{coord}} template, rather than putting the {{coord}} template in a single coordinates parameter. (Although the code would be set up so that the coordinates parameter continues to work as it does now, so nothing would break.) I am willing to do the wikicode for this if we agree that it is a good idea - we would also need to decide where in the template the map would be most suitably placed. - htonl (talk) 11:33, 8 January 2011 (UTC)
Sounds like a good idea. I would say either right above the summary section would be a good place for it. Or, right before the the runways section. Plastikspork―Œ(talk)15:59, 8 January 2011 (UTC)
Sounds fine. Would it be possible to do in such a way that the two lines in the {{Infobox settlement}}, "coordinates_type = airport" and "coordinates_display = inline,title", would not be required but would be the automatic default? Enter CBW, waits for audience applause, not a sausage. 18:39, 8 January 2011 (UTC)
Sure, we could make "title" display the default, unless it is specified otherwise. As far as the type goes, we could use "coordinates_region", and have "type:airport" appended by default. Plastikspork―Œ(talk)18:42, 8 January 2011 (UTC)
OK, so I've got an initial attempt sorted out in the sandbox. It allows for a {{Location map}} as well as a map that is just a plain image. I've updated the test cases accordingly, and there are some other examples in my sandbox.
The new parameters are as follows:
Coordinates
latd, latm, lats, latNS: latitude - degrees, minutes, seconds, and north/south. You can also use just latd with decimal degrees.
longd, longm, longs, longEW: longitude - degrees, minutes, seconds, and east/west. You can also use just longd with decimal degrees.
coordinates_type: type coordinate parameter. Defaults to airport. (You shouldn't need to set this.)
coordinates_notitle: By default the coordinates are displayed in the infobox and in the title. If this parameter is set to a non-null value then they are displayed only in the infobox.
Pushpin map
pushpin_map: Name of a map definition template used by {{Location map}}. If, for example, you set this to Spain it will use the map defined by {{Location map Spain}}. The coordinate fields (eg. latd and longd) position a pushpin coordinate marker and label on the map automatically.
pushpin_label_position: The position of the label on the pushpin map relative to the pushpin coordinate marker. Valid options are {left, right, top, bottom, none}.
pushpin_label: The label to use on the pushpin map. Defaults to the name parameter.
Great! I hope the documentation is satisfactory. In the examples I removed the stuff about using {{coord}} inside the infobox creating too-small coordinates in the title, since that doesn't seem to happen any more as far as I can see. I didn't add a map to the Beijing example since there isn't a suitable {{Location map}} (other than the whole-of-China map), and it can also serve as an example of using the old-style coordinates parameter. - htonl (talk) 19:18, 11 January 2011 (UTC)
Additional military parameter
Hi, just comparing this template to the military unit infobox, it'd be nice to borrow the "notable commanders" parameter from the unit one for air bases. The existing "commander" parameter is fine for the current commander, and the unit infobox has that as well, but for past commanders the "notable commanders" one works well. There are other parameters from military units that would also be of value, such as "aircraft flown", but that's not particluarly vital when the "occupants" parameter can point you to units, which will generally include the aircraft. Really like to see "notable commanders" though... ;-) Cheers, Ian Rose (talk) 08:34, 13 January 2011 (UTC)
Do you have examples of air bases where "notable commanders" in an infobox (presumably duplicating info in the article) would help readers of an airport article ? Listing previous commander(s) in infobox might be useful for military units, but I think we should draw the line at air bases. DexDor (talk) 20:46, 18 April 2011 (UTC)
Past notable commanders (which, in WP terms, effectively means past commanders who have their own article) are just as worthwhile for air bases as they are for any other military unit. This may be where we hit a bit of an impasse, aviation people see them simply as airfields whereas military people see them also as (static) units. There has been discussion elsewhere of simply creating a new and separate template for military airbases, and perhaps that will be the better course. I just felt it was a bit a shame to have something separate when there are military air bases that share facilities (at least a runway) with civilian airports, and one infobox could make things tidier. Cheers, Ian Rose (talk) 21:57, 18 April 2011 (UTC)
Text alignment in statistics data area
The statX-data items are numbers and should be aligned to the right to flush with the right side of the table. It always looks odd looking at passenger statistics when they are flushed left as they are today, especially when there are multiple stat numbers - they don't line up right one below the other. Thanks, Wikiliki (talk) 16:51, 10 February 2011 (UTC).
{{Edit protected}} Please sync with the current revision of the template sandbox. Somewhere in the recent series of layout edits, something was changed so that the pushpin map is no longer centered in the template. My edit to the sandbox fixes that. You can see the difference in the testcases. - htonl (talk) 15:05, 13 March 2011 (UTC)
I just noticed that the Infobox on the Wright-Patterson Air Force Base page is different than the example given in Example 4. Is this intentional due to guidelines or does one need to be updated? It would probably be beneficial if the Example and the page matched. Evan.oltmanns (talk) 00:17, 20 March 2011 (UTC)
Feel free to update the documentation and/or the article. I don't think anyone bothers to keep them in sync. Frequently examples are made more generic to avoid this issue. Thanks! Plastikspork―Œ(talk)02:44, 28 March 2011 (UTC)
Italics for foreign Native Names?
Forgive me if this has been raised before, but I would have thought that when the 'nativename' in the infobox is in a foreign language, then this should be in italics. Overall guidance on the use of italics is at MOS:Ety, and articles do seem to use italics in the body of the article (see Gran Canaria Airport). However this style is not carried forward into the infobox.
Previous discussion at archives in 2006 raised the point, but it was not addressed. I've tried italics in the infobox at Lanzarote Airport - to me it looks clearer and more consistent with Wikipedia atyle. What do people think? Carbonix (talk) 18:16, 29 July 2011 (UTC)
This would suggest that italics for a non-English 'nativename' should not be a standard requirement, embedded in the template, but used only on a case by case basis, that is, for foreign language alternate names. Indeed, the use of italics helps distinguish that the 'nativename' is the local language version, not an alternative English-language appellation. A reminder about italics could be included in the Parameters section on the Template page.
Also, there are inconsistencies in how the "native_name=" field is used; to me, it is intended for materially different names, not just where there are shortened versions of the full name; thus, London Heathrow and Toronto airports have alternative names in the article but don't need a 'nativename', but Hong Kong and Region of Waterloo do because they have alternative names not simply derived from the full name. Again, a consistent solution needs clarification in the Parameters section rather than a change in the template.
Agreed?! If these points are valid, how do we agree and amend the Parameters notes for them? Many thanks for people's guidance on this process! Carbonix (talk) 22:00, 19 August 2011 (UTC)
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Would it be possible to add {{formatnum: }} magic word to runway length, elevation and statistical data fields to automatically add thousand separators etc.? And would it be possible to use {{Convert}} to automatically convert elevations and runway lengths from metres to feet and vice versa? ––Apalsolat • c18:31, 30 July 2011 (UTC)
For elevation, runway length and helipad information: if only the primary value (i.e. metric, if "metric-rwy/elev=y", otherwise feet) is given, it is autoconverted to the secondary value with {{convert}}. If only the secondary value (i.e. feet, if "metric-rwy/elev=y", otherwise metric) is given, it is not autoconverted.
If both the metric- and feet-values are given, no autoconvert is done.
Elevation, runway length, helipad length and statistical data are automatically formatted with {{formatnum: }}. So, no thousand separator commas needed anymore (but they don't do any harm, either).
Fixed the problems pointed out at test cases 8 and 9. About the test case 10, the reference is in a wrong place. I think we just have to fix them manually article by article. For example {{Infobox settlement}} – a very widely used template – behaves exactly the same way if you put the reference in the wrong place. (See the demo here.) The footnotes parameter is the right place for references. Or we could also have parameters such as elevation_footnotes, coordinates_footnotes, runway_footnotes, stat1_footnotes etc. (similar to the Infobox settlement template) for placing inline references. ––Apalsolat • c22:30, 5 August 2011 (UTC)
Edit request - enable parameters to specify pushpin map marker image and size
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
The pushpin maps as enabled in {{Infobox airport}} use a default image and size for the marker (). I propose allowing a non-default image and size for instances where a location map image is too dark to allow easy viewing of the black airplane marker. This would be accomplished via the addition of two parameters: pushpin_mark and pushpin_marksize (passed through to {{Location map}} via its parameters mark and marksize). This will not affect any existing airport infobox, because the template will use the current defaults if the new parameters are not included or are blank.
The Location map template includes a parameter outside=1 that can be used to suppress an error if the mark location is outside of the map. I would like to use this in Chkalovsky Airport. That article uses a map of Moscow to illustrate the location of the airport. A error category is created because the mark is outside the Moscow map, but I think this is fine because the mark is still visible on this map. I don't want to change the map to all of Russia. Can the outside=1 parameter be added to the airport infobox to support this? MB22:41, 29 June 2017 (UTC)
Done. I saw the mixed reactions to the focus-city but decided to add that as well. If there turns out to be a problem with that parameter it can easily be removed. Would you please update the documentation page now? — Martin (MSGJ · talk) 18:31, 17 August 2009 (UTC)
Done something lame from CBW 15:38, 5 April 2010 (UTC)
). I propose allowing a non-default image and size for instances where a location map image is too dark to allow easy viewing of the black airplane marker. This would be accomplished via the addition of two parameters: