Wikipedia talk:WikiProject Airports

I'm concerned that many destination lists are getting rather difficult to read simply because they're getting long. I was wondering what people's thoughts are of adopting a style similar to WP:WikiProject Airlines' list tables would be? This gives a dedicated row for each route, which allows notes to be better added, and a refs field for references. An example of my suggestion is below. Danners430 _{tweaks made} 11:23, 3 September 2025 (UTC)

I really like that. Much neater. 10mmsocket (talk) 13:10, 3 September 2025 (UTC)

Perhaps for tiny airports with maybe fewer than 10 airline-destination pairs... but not sure this is great for large airports - e.g. Atlanta, Beijing, Dubai, etc... you end up with a VERY long list that involved a lot of scrolling down the screen. Based on number of hits per page, I suspect that the bulk of readers are focussed more on the large airports than the tiny ones. Wibwob28 (talk) 13:28, 3 September 2025 (UTC)

If we look at the usage of the "source" table (which was originally designed for airlines), it's used extensively even for large carriers - the example I used in another discussion was United Airlines, one of the US' "Big Three" carriers. It could well be collapsed, in accordance with MOS:TABLELEFT for larger airports, provided there is an adequate summary of routes in a paragraph above the table. I've updated the sample below with an example of what I mean. Danners430 _{tweaks made} 13:34, 3 September 2025 (UTC)

I still think it's going to be a VERY long list. Not because the content is necessarily bad... but because you are implicitly having a lot of blank space. For example, if we were to look at Atlanta airport, you have a moderately wide column that contains the words "Delta Airlines" once and then blank space for many many rows. Equally for the city and airport columns, you need to allow space for the very widest of city or airport names - while other rows with shorter names are filled with a lot of blank space. As an addition, we currently show only the city name (add the airport name suffix only for a very few airports where a city has 2 or more active airports) - under the new model, we're adding the full airport name, which for most readers probably isn't that important when they want to know where an airline flies from a particular city - so we're surfacing info that currently isn't visible and possibly should be initially kept hidden for readers to view later only if they choose to do so. For most airport-destination tables, the Notes column is likely to be blank for the large major of destinations (especially on airports with more than 10 airline-destination pairs) - so again you're devoting a lot of blank space.

As an equivalent, consider reading a newspaper with articles printed two words per line, but the columnar space for articles still having the same width as they do at the moment. Yes, blank space padding is important in layout, but too much blank space can detreact from overall readability.

Perhaps try this for Istanbul airport and see what it ends up looking like ?Wibwob28 (talk) 13:54, 3 September 2025 (UTC)

I mean it's already a thing. This is an example from List of Air Canada destinations - I don't necessarily see that being a bad thing... it makes it obvious that is's all the same.

Danners430 _{tweaks made} 14:11, 3 September 2025 (UTC)

Another suggestion - if an airport, such as Instanbul, is a hub for an airline (Turkish in this case), you could perhaps have a separate table for said airline's routes. So in the case of Istanbul you'd have one table for the routes operated by Turkish, where the airline is in the table header, not every row, and another table for any other airline using the style suggested below. I'll update the sample below with that option. Danners430 _{tweaks made} 14:15, 3 September 2025 (UTC)

We used to have separate tables for scheduled and charter flights.... but decided about 10 years ago that it was too complicated having them separate. What to do for example when a vertically integrated travel company chartered flights from its own jointly owned airline and initially sold tickets only to customers also booking accommodation, and then at a later point in time agreed to sell flight-only tickets. Which table was it to go in ? Endless arguments which were resolved by combining the 2 tables together.

What to do for example at Beijing Capital airport - should we have the main table plus 3 separate tables for each of the hubbed airlines ? Maybe the main table and 6 separate tables for the airlines treating as a hub or focus city ? Wibwob28 (talk) 14:21, 3 September 2025 (UTC)

Do we really need to show "Fort Lauderdale" and "Fort Lauderdale Hollywood Airport" on the same row in the airlines-destinations table ? Seems a bit repetitive for most people - if a person really wants to know the official name of the airport in Fort Lauderdale, then looking at the page for Fort Lauderdale airport is probably the best place to provide that information. I don't think that the page for Toronto airport need have that information shown explicitly - brevity matters. 14:16, 3 September 2025 (UTC) Wibwob28 (talk) 14:16, 3 September 2025 (UTC)

My only tiny reservation with tables is they become a planespotter fancruft magnet with customer header row colours and flags. That latter bit in particular needs to be nailed down in the guidance - no flags! 10mmsocket (talk) 13:56, 3 September 2025 (UTC)

Worth bearing in mind the WikiProject style guide already uses a table - this is just changing the format slightly. But yes - absolutely... no flags. Danners430 _{tweaks made} 14:06, 3 September 2025 (UTC)

You can't collapse the tables unless you are using them to "consolidate information covered in the prose" as per Wikipedia:Manual of Style/Tables and Wikipedia:Manual of Style#Scrolling lists and collapsible content. CambridgeBayWeather (#1 deranged), Uqaqtuq (talk), Huliva 19:25, 3 September 2025 (UTC)

But isn't that dealt with by adding a paragraph before the table giving details? The text "consolidate information covered in the prose" is rather ambiguous in that sense, or maybe it's how I'm reading it. Danners430 _{tweaks made} 19:33, 3 September 2025 (UTC)

Yes but then you're looking at duplicate information and might as well dispense with the tables. CambridgeBayWeather (#1 deranged), Uqaqtuq (talk), Huliva 23:05, 3 September 2025 (UTC)

In fact, I will support a complete removal of the destination listings, as it bites with WP:NOTRAVEL and because I think it is often used for company spam (the lower cost the carrier, the less sources given). But I am fully aware that that might be a bridge too far. But I think it will be a magnet for fancruft and will become ecessively long and unreadable. How will it work out for readers on the mobile version? The Banner talk 14:19, 3 September 2025 (UTC)

Honestly, I would support the same... but I have my suspicions it wouldn't happen. When it does come to making a final decision though (ie once a format is generally decided upon) I suggest we list that as an option. Edited to add - I've viewed a few articles with the Airlines style of destination list on both the mobile app and the mobile browser, and they're fine - especially if they're collapsible. Danners430 _{tweaks made} 14:49, 3 September 2025 (UTC)

I've updated the samples as per the discussions so far.

@Wibwob28, I've combined the City and Airport columns where the airport name is simply "City Airport" or similar, but left the two columns for where a city has multiple airports (such as New York, London, Dubai etc.) I've also added a second option, showing what it could look like if you separated out hub airlines into their own table(s), which would help for airports like Istanbul, Heathrow, Atlanta etc.

Also, IMO option 3 should be to remove destination tables altogether, per @The Banner's suggestion and point regarding WP:NOTRAVEL. However we should still have some content there, perhaps a paragraph with notable routes (eg. premier routes, hub-to-hub routes etc.) and a figure for how many routes are served? Danners430 _{tweaks made} 15:06, 3 September 2025 (UTC)

I think the merged city-airport column is an interesting idea.... but the human eye tends to scan down the left hand side of the column... and when it reads something like "Hartsfield Jackson" as the first 2 words.... this is deeply misleading when the column is labelled as "City". Either we have city and airport separately, or we have just "Atlanta-Hartsfield". The existing system has done us well with almost no objections for at least 15 years - there needs to be a very strong reason to change it. Wibwob28 (talk) 15:22, 3 September 2025 (UTC)

You say “us” as though you’ve been here those 15 years yet your account was only created two months ago… that’s not to reduce any sort of input you’re entitled to, it just seems odd.

Just because something works doesn’t mean to say we shouldn’t discuss options to improve - if you look at Istanbul for example, there’s one field in the table (for Turkish) which is almost possible to decipher, because it’s one humongous list of airport names - each one in blue (because it’s linked) and with a cite (ideally). It does make understanding the list rather difficult.

While this suggestion would make the lists physically longer, it breaks them up and makes it far easier to understand and digest the information - and if you’re looking for something specific, it’s far easier to pick out the information from a tabulated list than a paragraph. It also means citations are separated out from the text ever so slightly, again aiding readability.

I have no objection to completely combining the City and Airport columns - I’m just concerned that not all airport names are obvious as to where they are actually located - for example John Wayne Airport or Harry Reid International Airport. Danners430 _{tweaks made} 15:35, 3 September 2025 (UTC)

Then stick with the current convention - namely either Atlanta or Atlanta-Hartsfield. The location of the airport is the primary piece of information when discussing an airport for most people... the official identifier of an airport e.g. JFK / Newark / La Guardia - is needed only when a city has multiple airports. However, you still have the problem of using many many rows to list out all the airline-destination pairs and wasting a lot of white space in doing so, and the scrolling up/down makes it difficult to do any sort of comparisons between airlines.

I get that a monolithic blue piece of text can make a long list - e.g. Turkish Airlines destination at Istanbul airport - difficult to read... but perhaps we could consider some kind of marker - e.g. a filled circular disc ⬤ - and use this as a separator between each city/airport destination ? Thus for Turkish Airlines at Istanbul, the start of the list might read as

"Abidjan^[153] ⬤ Abu Dhabi^[154] ⬤ Abuja^[155] ⬤ Accra^[156] ⬤ Adana/Mersin^[157] ⬤ Addis Ababa^[158] ⬤ Adıyaman^[159] ⬤ Ağrı^[160] ⬤ Aleppo^[161] ⬤ Alexandria^[162] ⬤ Algiers ⬤ Almaty^[158] ⬤ Amman–Queen Alia^[163] ⬤ Amsterdam^[164][165]"

instead of

" Abidjan,^[153] Abu Dhabi,^[154] Abuja,^[155] Accra,^[156] Adana/Mersin,^[157] Addis Ababa,^[158] Adıyaman,^[159] Ağrı,^[160] Aleppo,^[161] Alexandria,^[162] Algiers, Almaty,^[158] Amman–Queen Alia,^[163] Amsterdam,^[164][165]"

Largely keeps the same format as we already have, but makes it rather easier for the eye to scan and register separators between destinations. Of course, some might like a different character instead of a solid disc - but I give this just as a suitable example.

I'm not against making the Airline/Destination tables easier to read - but I think a minor change can fulfil this aim.

Wibwob28 (talk) 15:48, 3 September 2025 (UTC)

How can you easily compare airlines with the current format? That seems to me to be rather odd, as the only real comparison you can do is the number of destinations served - and that is maintained by the size of the table given over to each airline. Especially if you separate out hub airlines, in the example of Istanbul you’d be left with one large table for Turkish, and one table with a lot of individual routes - much as we have now, just with the routes separated out a little.

I have to say that the suggestion of separating routes with a separator doesn’t really help… and changing the colour is frowned upon by the MOS as it risks creating accessibility issues. Indeed, I’m not even sure such separators are even in the MOS! Danners430 _{tweaks made} 15:54, 3 September 2025 (UTC)

It's possible to compare airlines in 2 ways - first the number of lines of text in an airline/destination tables allows you to see the magnitude of breadth of destinations and likely the importance of each airline at an airport. Secondly, because the text is relatively compact, you can read the text of the destination list of multiple airlines on a single screen, instead of having to scroll up/down. The human eye and brain are better at comparing when they can see 2 different things together in the same glance, instead of having to look at the separately

Istanbul has just 1 hub airline.... Beijing Capital has 3 hub airline and 3 focus city airlines. I'm not sure that converting Beijing/Capital into 7 separate tables (plus of course a cargo table) is a good idea. Then of course, you end up with people arguing whether an airport is a hub or a focus city or a base for a particular airline and how these different semantic meanings should be handled - llikely to lead to serious planespottery pedantic arguments if we start having separate tables based on difficult-to-objectively-observe criteria.

My suggestion of changing the colour of references was in hindsight a bad idea - I've removed that. I still think that a filled circular disc may well be a way to separate the destinations in a long list to ensure the human eye can read and distinguish them more easily. I'm open to another symbol instead - maybe a + symbol if we prefer, but think a filled circular disc would be a high-contrast method that gives the eye a good chance to see the items in a list as separate.

Wibwob28 (talk) 16:10, 3 September 2025 (UTC)

I have to disagree - it really doesn’t help much if at all… in fact it almost makes it worse, as the list now has a third symbol or piece of text cluttering up the list. I’m sorry, but flat lists like that simply aren’t conducive to being easily read. Danners430 _{tweaks made} 16:16, 3 September 2025 (UTC)

Do people really read and take interest in the whole full list... or are they scanning the list just for a few entries of specific interest ? I wouldn't see the disc as clutter - more as something that allows the human eye to distinguish between entries in a list, just like a new line would, but still keeping relatively compact the space occupied. Think of a newspaper - you might well see horizontal and veritcal lines to separate the various articles - we generally don't see those lines as clutter but more allowing the eye to easily separate boundaries. When we see a bullet pointed list on a paper document with maybe 4 items - we generally don't see the bullets as clutter but rather as separators and introducers of new information. The problem in this case is that we sometimes have a single list with 100 or even 200 items - so 200 lines in a bullet pointed list with each line having just 1 or 2 words tends to seem a bit too much for the eye to scan.

Wibwob28 (talk) 16:29, 3 September 2025 (UTC)

You’re not proposing a bullet pointed list though - you’re proposing adding characters between phrases in a paragraph. A paragraph is not a bulleted list. If you feel like we should just remove the full list, then that’s option 3. Danners430 _{tweaks made} 16:30, 3 September 2025 (UTC)

Removing information is definitely not what I'm proposing. This is information that should be kept - it's very difficult to obtain independently and without monetary cost on the web (outside wikipedia) - airlines and airports love talking about codeshares and partnerships making it extremely difficult on airline or airport websites to see a list of where an airline itself flies from an airport, and where it involves changing aircraft to another airline. Plenty of airports will happily continue to claim airline X flies to cities airports A, B and C, even if those routes ended years ago - citing an excuse of problems with their website team because it makes the airport look more important than it really is. I suspect airlines would be very happy to see wikipedia delete this information as it would then become harder for ordinary people to see the boundary between reality and marketing-speak.

On your other point, the list of destinations flown by a single airline from airport X can't really be described as a paragraph. It's not continuous prose - it's just a list of 1-word or 2-word items, with commas as separators. I certainly wouldn't call 1 or 2 words a full phrase. Yes, commas are unobtrusive and the small size makes it difficult to discern where one item in the list ends and the next begins. The aim is to keep the list nature of this but make function that the comma feels clearer so that the individual items in a list can be distinguished more clearly.Wibwob28 (talk) 17:37, 3 September 2025 (UTC)

That's a great idea, but maybe we can figure out a way to let it show both, like clicking one button and it changes its format to the way you suggested. I already made a lot of destination maps to help and maybe users can use the Google searching text tool (Ctrl+f) to find the cities they want to check. Feather&Martin (talk) 15:28, 1 March 2026 (UTC)

• Oppose Many airports have hundreds of destinations. These are already big tables, and giving every destination for each airline its own row would make these unreasonably long. I don't see a problem with the existing lists, and if the concern is their length, this isn't a solution, it makes it worse by turning one row into dozens. 16:31, 4 September 2025 (UTC)

A number of articles have been gaining "hard-coded" image-based destination maps recently. I'm personally of the opinion that we should really stop adding these, purely due to maintenance concerns - plenty of articles have a template-based map which can easily be edited and updated by editing the article, whereas an image must be deleted and re-uploaded every time it's altered. What do others thing? Danners430 _{tweaks made} 10:37, 26 February 2026 (UTC)

Why are there airlines listed in the busiest domestic routes tables for US airports when the US DOT sourcing for these tables does not include the airlines flying the routes?

For example, at McGhee_Tyson_Airport#Top_destinations, 6 of the top 7 busiest routes mention Delta and/or American, but this is the first mention of either airline's operations at the airport outside of an unsourced list of gate assignments. The DOT statistics page cited only lists the number of passengers for each destination. Michael Greiner 03:00, 1 March 2026 (UTC)

There is a requested move discussion at Talk:Tamale International Airport#Requested move 24 February 2026 that may be of interest to members of this WikiProject. Vestrian24Bio 12:45, 3 March 2026 (UTC)

I created this list article based on information from Hartsfield–Jackson_Atlanta_International_Airport#Airlines_and_destinations#Passenger, specifically the part with Delta, and added the IATA and ICAO codes. Help in expanding it would be appreciated. (Delta has a lot of destinations!) VidanaliK (talk to me) (contributions) 01:22, 6 March 2026 (UTC)

We really shouldn’t be splitting these lists into separate list articles. They really belong as part of the main article. Danners430 _{tweaks made} 08:48, 6 March 2026 (UTC)

@Danners430 Yes, but having them as a linear list instead of a table makes things really cluttery. I think that airlines at their hub airports should get their own list, but I didn't see a place for it on the main article so I took it to the new one. VidanaliK (talk to me) (contributions) 16:06, 6 March 2026 (UTC)

If we’re going to change the format of these tables, then that’s a discussion that needs to be had at a much broader level - we can’t just make unilateral changes like this. Danners430 _{tweaks made} 18:51, 6 March 2026 (UTC)

OK, I'll move it to userspace as a sandbox that can later be put either in its own article or in the Delta article later if that is what is decided. VidanaliK (talk to me) (contributions) 21:00, 6 March 2026 (UTC)

 Done. VidanaliK (talk to me) (contributions) 23:16, 6 March 2026 (UTC)