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.
The |statn-data= fields are formatted with formatnum: magic word. This causes the references to bork and expose the strip markers that you are seeing; example: [1]. The only way to fix this is to:
Not include <ref> tags
Update the template to not use formatnum:
Update the template to add parameters for references
There are several formatted fields, so a ref parameter would need to be added to all of them. This template would be a lot easier to maintain if it were updated to {{Infobox}}. ---— Gadget850 (Ed)talk12:16, 16 October 2011 (UTC)
The general response to this issue has been to use the "footnotes" section. I don't think {{infobox}} is going to fix that. Especially if you consider this template uses four columns. Thanks! Plastikspork―Œ(talk)16:04, 16 October 2011 (UTC)
I agree. Currently only military airports are afforded this using the |built= and |used= fields. __meco (talk) 13:30, 25 February 2012 (UTC)
Distance to city
Why not include a |dist-to-city_mile and a |dist-to-city_km parameter into the template? Maybe merge it with the |city-served field? Pizza1016 (talk) 10:44, 2 February 2012 (UTC)
If you do that, there should also be a |dist-to-city_nmi= parameter, because of our dear friend GCM, which enables us to get that information too, and because a lot of AIP references list distance in nmi. - Jorgath (talk) 05:35, 15 February 2012 (UTC)
You don't need three just two. If it is thought to be a good idea then |dist-to-city and |dist-to-city_unit with nautical miles the default that converts to km and mi. With the option of km that converts to nmi/mi or mi that converts to nmi/km. CambridgeBayWeather (talk) 00:37, 16 February 2012 (UTC)
Focus city airlines listed in the hub section of an infobox
Copied from discussion at WP Airports talk page
Should airlines like Southwest that do not operate on a traditional hub-and-spoke system, but rather have a larger decentralized focus-city network, up in the "Hub" section of the infobox of an airport that is listed as a focus city? Someone just recently edited the Oakland International Airport article to include Southwest Airlines as a hub tenant. Just wanted to build some kind of consensus here before I went and edited it. nf utvol (talk) 20:01, 13 February 2012 (UTC)
From the airport's perspective, if a single airline has a lot of flights to and fro, maybe several aircraft (and crew &c) based there, then it's reasonable to call it a hub (even better if a reliable source calls it a hub) even if it's not the sole focus of that airline. bobrayner (talk) 15:48, 14 February 2012 (UTC)
My thought is that we should only list actual stated hubs there. That is, airlines that operate on a true hub and spoke system that fly a substantial number of flights to non-hub airports from the city in question. For instance, even though American Airlines has a lot of flights out of Nashville, almost all of their flights are to hub airports. With airlines like Southwest that operate on a Focus City system, probably a quarter of the airports they fly to would be considered hubs, which would just clutter the infobox. Also, many airlines have crew and maintenance bases at small airports, such as Dayton or Knoxville, that are definitely not a hub. Perhaps the addition of a "Crew Base" or "Focus City" entry into the infobox could be useful? Of course, then we run the risk of including too much in the infobox. nf utvol (talk) 16:16, 14 February 2012 (UTC)
How about a compromise? If a reliable source lists a destination as a hub of an airline, it's listed as a hub in the infobox. This is regardless of whether or not the airline uses a hub-and-spoke system. Airline webpages count as a reliable source if they declare the destination a hub, but not if they use the term "focus city" or something similar. - Jorgath (talk) 21:07, 14 February 2012 (UTC)
If the definition at Airline hub is to be trusted (and that article surely needs some TLC), a hub is:
An airline hub is an airport that an airline uses as a transfer point to get passengers to their intended destination.[citation needed] It is part of a hub and spoke model, where travelers moving between airports not served by direct flights change planes en route to their destinations.[citation needed] Many hubs of the airlines are also situated at airports in the cities of the respective head offices.[citation needed] Some airlines may use only a single hub, while other airlines use multiple hubs. Hubs are used for both passenger flights as well as cargo flights.[citation needed]
Which requires transfer traffic, not flights to non-hub airports. Whether Southwest's presence at Oakland qualifies, or whether that definition is correct, I leave for others to haggle over! bobrayner (talk) 22:03, 14 February 2012 (UTC)
I don't want to get drawn into (i) what the formal definition of a "hub" is or (ii) what the difference between hubs and focus cities is, but I do want to point out the following:
The examples and perspective in this discussion deal primarily with the United States and may not represent a worldwide view of the subject.
Good point. Another compromise suggestion, then: have the infobox template display "hub/focus city for" rather than "hub for," and include all declared hubs and/or focus cities. - Jorgath (talk) 00:35, 15 February 2012 (UTC)
Alas, I must disagree again (don't take it personally; I'm very disagreeable). "Hub/focus city for" is slightly stilted wording, and if we want a global perspective, "focus city" is something we should be moving away from. Can't we just use the word "hub" more carefully? bobrayner (talk) 02:21, 15 February 2012 (UTC)
I'm not taking it personally, don't worry. And I agree with the wording issue. The problem is that by only using official "hubs," we're on the verge of systemic bias against airlines that don't use a hub-and-spoke system, so what we need to do is actually use "hub" less narrowly even if we use it more carefully. Maybe the solution (though I dislike it) is to entirely remove the "hub" parameter from the airport infobox, leaving that information for the airline pages alone. I don't have a better idea, but we've got to either do that or find a way to include an equivalent mention of non-hub-and-spoke airlines in the infobox (and by equivalent I mean listing airlines that make major use of that airport). Hmm...maybe try to figure out a number of airports (3? 5?) that should be considered "hubs" for this purpose, even if they are officially listed as "focus cities" or some such thing? - Jorgath (talk) 04:21, 15 February 2012 (UTC)
I'm not entirely opposed to removing it, as I fall under the flag of less-is-more in infoboxes. Does including the hub in the infobox really add anything of status to it that isn't better explained in the prose of the lead in and body? As an alternative, it could be useful to reword it and change it to "Major Airline Presence" or something along those lines. That would allow for the inclusion of smaller feeder airlines like PSA or Republic in the infoboxes of airports that they use as crew bases.nf utvol (talk) 15:53, 15 February 2012 (UTC)
Edit request on 13 May 2012: different than
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Please change the two occurrences of "if different than ICAO or IATA codes" to "if other than ICAO or IATA codes" and please change "if different than the owner" to "if not the owner". —Anomalocaris (talk) 18:31, 13 May 2012 (UTC)
Anomalocaris (talk) 18:31, 13 May 2012 (UTC)
Not done:{{edit protected}} is usually not required for edits to the documentation, categories, or interlanguage links of templates using a documentation subpage. Use the 'edit' link at the top of the green "Template documentation" box to edit the documentation subpage. --Redrose64 (talk) 23:11, 13 May 2012 (UTC)
G'day, I have just noticed a problem with the Infobox in the Sydney Airport article. There is a year given in brackets for the freight tonnage total; when I view it, it says "(2,009)" instead of "(2009)" but it has been typed correctly. YSSYguy (talk) 08:02, 20 May 2012 (UTC)
This is because |stat3-data= (like |stat1-data=, |stat2-data= and |stat4-data=) is pushed through the {{formatnum:}}parser function, which expects a pure integer with no other information. The information in these four parameters should be for the same year as is given in |stat-year=; no variation is provided for. --Redrose64 (talk) 20:51, 20 May 2012 (UTC)
Edit request - enable parameter to display pushpin relief map
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
I propose allowing the infobox to pass a value to the relief parameter used by {{Location map}}. This would be accomplished via the addition of a pushpin_relief parameter to {{Infobox airport}}.
I don't understand why the word Coordinates is linked in the box - [[Geographic coordinate system|Coordinates]]. It looks bizarre to me, and I think it should be unlinked. John of Cromer in China (talk) mytime= Wed 08:12, wikitime= 00:12, 21 November 2012 (UTC)
Additional fields?
I suggest following additional fields:
f(n)-runway-width-f
f(n)-runway-width-m
largest-handling-capacity
airport-manager
Further, there are a number of parameters described in runway which it may be useful to consider here. These include Declared distances, flare path, and an extended description of runway surface. There are other more technical parameters whose inclusion could be discussed here.
Before line 323 start a new heading 'Other information", then also add processing for further parameters 'largest-handling-capacity' which refers to aircraft size, and 'fuel-availability' which can be Yes or No.
There are quite a lot of changes here. Could you add them to the template sandbox? It will be a lot less likely for me to make a mistake that way. Also, you can view the changes against the main template at the test cases page. If you have any difficulty with the coding, just let me know, and I can try and add what I think you are getting at to the sandbox. :) Best — Mr. Stradivarius(have a chat)11:57, 27 November 2012 (UTC)
Curious about the "largest handling capacity" line. Is that to be for the largest possible aircraft or the largest and most commonly used aircraft at an airport? For example Cambridge Bay Airport has had a Boeing 727 on several occasions but the aircraft can't use the airport when it is fully loaded. However, the largest most common aircraft is the Boeing 737. CambridgeBayWeather (talk) 12:37, 27 November 2012 (UTC)
Administrator note I have disabled the request. Please reactivate when the required changes have been made to /sandbox and it is fully tested. — Martin (MSGJ · talk) 14:04, 27 November 2012 (UTC)
I think we need to be careful that the infobox doesn't start getting too large with additional information that might be better placed in the body of the article. Here are my comments on the suggestions above:
Runway widths: I have experimented with adding these manually to the infobox in the past. I found that it made the infobox appear cluttered and more difficult to read (Example 2), but that can be resolved by including additional white space (Example 3). Also, the "Length" header text should only include " × Width" if width parameters are displayed. These changes increase the infobox width (Example 1 vs. Example 3), but please do not hardcode anything wider than the current default so as not to affect all the existing infoboxes.
Coordinates: No problem with removing the link from the word (it is the same link you'll find with coordinates displayed in the upper right title area on many pages). We should also consider removing the link for "Runway", since the blue text on blue background isn't easily readable (as seen in examples to right).
Manager: Is the name of the individual who manages an airport notable enough to even be added to the article, much less the infobox? I read and edit a lot of airport articles and I rarely see the manager mentioned.
Other information: Again I think most of these are better placed into the article instead of the infobox. If this new section is added, please try to keep the added parameters to a minimum. "Largest handling capacity" I can see since it is of general interest, "fuel availability" perhaps less so.
All those curly braces are making my eyes go funny! It's a very laborious process, because I have to save the sandbox changes each time I make a change, before I can cycle the testcase. What I intend is have × actual-width (if present) on the line below length, so that box is longer rather than wider. Problem now is that somewhere in the meta-parsing process that part gets wrapped in <p> </p> which means it doesn't align with the others.
All info is optional, so if it is not of consequence it doesn't get included. Part-time grass feeder airfields are different from international ones. I don't see how the name of an AFB commander is actually different from that of a manager.
There are several pointless wikilinks. Runway would be white otherwise, ditto Helipad. Others: tonnes. And have you ever clicked on the actual coordinates or the globe next to them? One page I'm familiar with, they lead to two different maps, one of which includes sunken World War II warships (clickable). John of Cromer in China (talk) mytime= Sun 22:05, wikitime= 14:05, 2 December 2012 (UTC)
I often click the actual coordinates link and use the resulting "GeoHack" page to view Google Maps (hybrid satellite view), Bing Maps (for its unique Bird's Eye view), Wikimapia (shows places not labelled on other maps including details within some airports), MapQuest (at a certain zoom level it has nice view showing U.S. county borders), and SkyVector (aeronautical charts for articles missing a direct SkyVector link). Very rarely use the globe link, but it is automatically added to coordinate links in infoboxes and in the page's title area at top right (for more on that see Template talk:Coord#Globe icon, Template talk:Coord#Globe icon not showing, Template talk:Coord/Archive 10#Make icon display optional, and meta:Talk:WikiMiniAtlas). -- Zyxw (talk) 19:20, 2 December 2012 (UTC)
I'm still not sure that "largest handling capacity" is workable. There is too much of a difference between the largest possible and the normal largest. The Antonov An-225 Mriya has landed at Paris–Le Bourget Airport which means that it could be listed at any airport with an elevation of 220 ft (67 m) or less and a runway 3,000 metres (9,800 ft)* or longer. Of course that would also depend on the type of runway surface and its load capacity. It would be better in the body where it could be explained properly or make the line something like common aircraft. In that case Iqaluit Airport which has seen the Airbus A380 would actually have Boeing 737. CambridgeBayWeather (talk) 12:06, 3 December 2012 (UTC)
OK I have now made the changes in the sandbox. I can usually spot spelling mistakes and punctuation errors at 1000 feet, but this typographical language, those curly brackets, just make my eyes go funny!
Basically I have set it up so no change = no change, i.e. box width hasn't changed but obviously length will. If a runway width is added, it will appear after the length, as × width. Depending on the length, it might all fit on the same line, or wrap to the next. HTML seemed to have a mind of its own regarding column widths, so ft and m may not always be balanced, I couldn't figure out why not, but that's always happened. See for instance Wright-Patterson AFB.
I have applied this change to helipads as well as runways.
Specify runway widths as R[n]-width-[d] where n = 1 to 8 and d = m or f
Specify helipad widths as H[n]-width-[d] where n = 1 to 12 and d = m or f
As regards the info such as airport manager, handling capability, etc., rather than introduce specific items, I have introduced 10 other fields similar to current for stats, specified as other[n]-header and other[n]-data. n=1 to 10; if you specify other[n>1] without other[1] then you won't see it. Data is passed through unchanged. (i.e. text)
There is a subpage /dim currently sitting below sandbox. That needs to be copied to be a subpage of the main infobox. This also entails editing the changed code so it points to infobox airport/dim and not infobox airport/sandbox/dim
I removed wikilinking of coordinates, runway and helipad.
I made the following updates to the sandbox template:
fixed placement of <includeonly> – its purpose is to display header text and parameter names when viewing the template page, which is useful for documentation and to allow previewing of changes while editing the template
replaced {{!}} with | where former not required since not inside #if
removed the empty row above airport name and moved widths back to runway/helipad headers – the empty row created extra white space above the airport name when viewed in the current version of Mozilla Firefox
updated runway and helipad "m" and "ft" headers to replace {{pad|2.7em}} with "text-align:right" – it has same effect & matches alignment of data in Template:Infobox airport/sandbox/dim
Other issues that should be fixed before going live (not changed pending additional discussion):
The live template centers data in all four runway/helipad columns (number, length/width in m & ft, surface) but the sandbox displays left-aligned for number/surface and right-aligned for length/width. I would suggest keeping this data centered.
Wrapping of runway/helipad data when the template displays widths: as shown in Template:Infobox airport/testcases#Test case 1: Public airport it can wrap differently on different lines within the same infobox, which looks somewhat ugly. Possible solutions include preventing it from wrapping with style="white-space:nowrap" (which will slightly increase the infobox width, but only when needed) or forcing it to wrap by including <br/> before "× (width)".
The reason for the {{pad|2.7em}} was to try to get the width columns approximately equal. I really don't understand why they vary, and sometimes they're unbalanced too - look at Wright-Paterson AFB, look at Helsinki. I couldn't see any reason for the imbalance, and it's always the first one narrower than second - particularly silly if feet come first, as that's a wider field than m. As regards alignment, the length needs to be left-aligned and the width right-aligned. John of Cromer in China (talk) mytime= Tue 19:39, wikitime= 11:39, 11 December 2012 (UTC)
Also, I made the headings so that the name of the unit (ft or m) lined up with the unit position of the value. Not easy if the value wanders about because centred (which incidentally looks pretty ghastly when you have a case such as DFW where the digit length of the runways differs, so they're not aligned at all). John of Cromer in China (talk) mytime= Fri 20:51, wikitime= 12:51, 14 December 2012 (UTC)
Edit request: Update to fix centering of location maps
Lua error in Module:Location_map at line 425: No value was provided for longitude.
The map created by {{Location map}} is no longer centered when displayed in this infobox. I reviewed both templates but could not find the exact cause. In any case, it can easily be resolved by changing line # 131 from |float = none to |float = center. To the right, Example 1 uses the current template and Example 2 uses an updated version implemented in {{Infobox airport/sandbox2}} (diff). I created the new sandbox so as not to disrupt ongoing edits in the usual sandbox. -- Zyxw (talk) 22:25, 2 December 2012 (UTC)
Edit request on 5 March 2013: Frameless as default image size
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Please change the template to use frameless as default image size instead of hard coding 220px. This won't force images smaller than 220px to be blown up, and also allows users to set their preferred image size.
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Add a parameter to the infobox for the airport's opening date. There is a "built" parameter that is similar but only for military airports. Similarly, we would need a parameter for the closing date for the airport or date when passenger services ceased in cases where the airport has been converted for some other use. Thank you.
BigJolly9 (talk) 19:09, 5 May 2013 (UTC)
Since Infobox Military Structure is currently being transformed into Template:Infobox military installation/sandbox (with the addition of runway information) and a lot of military airports will be changed to this "new" infobox. Why cannot the wording which says "<!-- military airports -->" next to built and used be removed? Gavbadger (talk) 23:29, 10 May 2013 (UTC)
I've added 3 parameters - opened, closed, and passenger_services_ceased. We could also use Gavbadger's idea. Instead of the "opened" parameter, extend "built" to cover all airports, not just military. That would save us one parameter. BigJolly9 (talk) 17:32, 13 May 2013 (UTC)
In light of many airports in SE Asia not having relevant safety equipment, among other locations, and the recent crash of airliner Lion Air flight 904, I would like to include a section for ILS, LLWAS 1,2&3, etc. I think its important often overlooked info. Doseiai2 (talk) 22:25, 10 May 2013 (UTC)
These additional types will help to add more clarification instead of just using Public, Private, Military, and Military/Public by themselves.
--Arima (talk) 07:01, 18 August 2013 (UTC)
Bantayan Airport is currently using some hacks to wedge in additional fields (airport manager, fuel availability, Largest handling capability, and runway width). should any of these be added here? should these fields be in the infobox at all? Frietjes (talk) 16:41, 6 September 2013 (UTC)
@Mxn: I think this change will usually be good, but I see that the "closed" parameter says it can be used to describe a temporary closure. In that case "Serves" may still be appropriate - "Airport X serves London, but is temporarily closed for repairs". What do you think? -- John of Reading (talk) 15:12, 26 March 2014 (UTC)
Not done: please make your requested changes to the template's sandbox first; see WP:TESTCASES. If it is just closed for repairs, then the airport is still open to the repairers and therefor is not closed. I would think in such cases the "closed" parameter would not be set although a note may be added to the article saying it is currently "closed to the public due to repairs" or some such. Either way, this should be thrown in the sandbox with a full set of testcases to see how it would play out in various instances. — {{U|Technical 13}}(t • e • c)15:24, 26 March 2014 (UTC)
Ah, I didn't notice that it should be used for temporary repairs. Thanks, I'll consider implementing a more explicit way to indicate permanent closure on the sandbox. – Minh Nguyễn (talk, contribs) 19:40, 26 March 2014 (UTC)
Template-protected edit request on 8 November 2014
Please copy from the current sandbox[1]. I adjusted the {{location map}} template call to invoke the {{{default_width}}} parameter instead of absolute {{{width}}}. This allows automatic scaling of the map for narrow countries.
Paul_012 (talk) 04:44, 8 November 2014 (UTC)
Template-protected edit request on 30 November 2014
Hey @Frietjes: and all others: Template:Infobox airport/sandbox seems to be quite ready for prime time, see Template:Infobox airport/testcases. I fixed the remaining problems regarding the Owner/Operator variables and the column widths. What remains are some minor style differences. The more compact Runways and Helipads tables are even an improvement. The all-white captions just as well. All further optimizations should be done in incrementally followups IMHO. So I'd propose to launch the new template now. Regards, --PanchoS (talk) 22:28, 30 November 2014 (UTC)
The link to Direction is no longer valid. Not sure if a section should be re-added on the Runway page or the link here should be changed, just calling attention to it Phil (talk) 06:35, 28 March 2016 (UTC)
It looks like the section previously called Orientation and direction is now called Naming, so possibly it is appropriate to just change the existing link on this template to that? Phil (talk) 06:54, 28 March 2016 (UTC)
I updated the sandbox with a proposal for keeping the background color explicit even when it should cascade from elsewhere. The change should not be visible to most users (see testcases), but ensures the content visible for everyone. —LLarson (said & done) 19:22, 24 April 2016 (UTC)
I'd rather we used a paler header background and didn't overwrite link colours. Alternatively, we could unlink 'helipads' and 'runways'; they're edging on WP:OLINK. Izkala (talk) 01:04, 27 April 2016 (UTC)
Please update to my last sandbox version (diff) to track the numerous cases of location maps being embedded within the |ICAO= parameter rather than the proper |pushpin_*= parameters.
@PanchoS: Could you point me to a page where this is being done? I'm wondering if there is a better way of finding this error than checking for closing </center> tags, but it's difficult to say without seeing an example. Best — Mr. Stradivarius♪ talk ♪00:43, 16 June 2016 (UTC)
I was in the middle of syncing this in when I saw this response - it didn't look like it would cause any harm - but if there is a better way then I'm all for it; I undid my sync in. — xaosfluxTalk03:18, 16 June 2016 (UTC)
@Xaosflux and PanchoS: Ok, I see the problem. If the goal here is to just check for that specific error and then remove the tracking-category code once all the articles are cleaned up, then I think this solution is fine. If this is going to be a permanent thing, however, I would check that the value of the |ICAO= parameter is actually a valid ICAO code, and add a tracking category for all other input. Something like {{#if: {{#invoke:String|match|s={{{ICAO|}}}|pattern=^%w%w%w%w%w?%w?$|plain=false|nomatch=}} || [[Category:Some tracking category]] }} should do the trick - that would add the tracking category unless |ICAO= contains only 4-6 letters or numbers. (Or to be exact, 4-6 characters in the Unicode categories of "letter" or "decimal number".) This check could be made more rigorous as well, if you don't want to accept codes starting with a number, etc. — Mr. Stradivarius♪ talk ♪10:40, 16 June 2016 (UTC)
@Mr. Stradivarius: Where are there codes with more than 4 alphanumerics? The current constraint on Wikidata for airport code is 4 alphanumerics, and I want to verify your claim. --Izno (talk) 11:34, 16 June 2016 (UTC)
@Xaosflux: Thanks for syncing! @Mr. Stradivarius: This is of course only to fix the 170 articles (possibly more, let's see once all pages are recached), and immediately remove the tracking code. Your proposal may still be a good permanent solution to follow up with. Cheers, PanchoS (talk) 11:27, 16 June 2016 (UTC)
Wow, the number is steadily growing. Might be a good use case for a bot. Do you have an idea which bot could do that task? --PanchoS (talk) 11:30, 16 June 2016 (UTC)
Can someone add more fields to the statistics section? Wilmington International Airport has 6 statistics fields and this template can only currently display 4 of them. Always possible that ILM just has too many statistics but I didn't add them...
I was going to clean up the code for the template a little by eliminating the display of params on the template page. So, for example, I would replace:
Please change the color of the text from white to black on Template:Infobox airport, becasue the current color scheme violates WP:COLOR. [4]Grapesoda22 03:58, 16 February 2017 (UTC)
We could also do a separate parameter check for these parameters and categorize them under a non-alphanumeric symbol. This is commonly done for tracking, though I don't have an example at my fingertips at the moment. If nobody here knows how to do it, I'll dig up an example. – Jonesey95 (talk) 03:49, 9 March 2017 (UTC)
Even better: in a dedicated subcategory? Would be good. Maybe module:Check for unknown parameters/doc can help. As it happens, today they are sorted under "L" because of "latd", but that may become polluted. To be clear, I have no aim to clean this further. -DePiep (talk) 08:06, 9 March 2017 (UTC)
I would like add to the template a field for official Twitter handle of the airport, titled "twitter", similar to official websites in the "website" field. This would help users quickly identify an airport's official social media presence in which airports officially reply to travelers' requests and post updates, similar to an official website page. Please let me know your thoughts. Thanks for your consideration. Subbupedia95 (talk) 04:21, 13 February 2018 (UTC)
I'm not sure if I've understood correctly - but isn't this the place to discuss and to establish consensus? If not, where can I do so? Thanks for the help.Subbupedia95 (talk) 18:03, 13 February 2018 (UTC)
Need to replace "Military airport" wording with "Military aerodrome"
There is no military "airports" by the "airport" definition in aviation terminology and particularly here Airport (for the military case only "aerodromes", "air bases", "airfields", etc.). Best solution is to introduce separate {{Infobox aerodrome}}. At least, within this template all wording "Military airport" can be easily replaced with "Military aerodrome" (I'm not authorised to do this) Apetrov09703 (talk) 05:36, 15 February 2019 (UTC)
I'm sympathetic to the concern raised, however. Don't stress over the suggested solution to the problem. --Izno (talk) 16:02, 15 February 2019 (UTC)
Thanks for comments, folks. After additional consideration I feel there may be no need at all for that part of the template where "military airport" wording exists because other template - "Infobox military installation" - has two dedicated optional sections: "airfield information" and "test site information". For example you may wish to have a look at this stub Salka Aerodrome. Apetrov09703 (talk) 18:00, 16 February 2019 (UTC)
ASL elevation display error
This template has |elevation-f= and |elevation-m= for elevation in feet and meters. |metric-elev= forces the metric value to be displayed first. If only one elevation is provided, the template does an automatic conversion to get the other. If converted value is displayed last, there is no problem. However, if the converted value is displayed first, you just see the unit (m or ft) without the number (e.g. Elevation AMSL m / 411 ft). Example here. Frietjes? MB18:01, 21 February 2020 (UTC)
I highly recommend the addition of a frequency field in the airport infobox as it is really helpful for people who like aviation and have a tuner for airports.YashPratap1912(CONT.)17:18, 31 July 2020 (UTC)
Issue with runway conversions
If only the imperial/US customary values are given for runway lengths, but the metric-rwy option is enabled, then conversions do not happen and the metric column is blank. This needs to be fixed. This issue seems like it's related to the elevation AMSL issue above, but with runway lengths instead. Getsnoopy (talk) 00:58, 18 November 2020 (UTC)
