The wiki has begun its opening! If you wish to participate, please message Alessa on OGF. Please note that not all requests will be approved immediately.
The old wiki has been archived here.

Forum:Global and regional issues/The two systems of airport codes

From OpenGeofiction
Jump to navigation Jump to search
ForumsGlobal and regional issues → Global and regional issues/The two systems of airport codes


Since we're starting afresh with the new wiki, one of the things I would like to bring up is the two systems of airport codes that we have (WAAT and ANACA). I understand that in the real world we have IATA and ICAO that both have listings of codes (not to mention internal codes used in larger jurisdictions like France, Russia, and the US). Looking at the history of how these codes developed, my feeling is that it happened more through bureaucratic means with a small intent to create regional divisions. My feeling is that, for much of what we do, the systems are basically redundant. Yes, I recognize that their usages in the real world are slightly distinct, but this is only because organizations have kept them that way. They didn't have to evolve into distinct entities.

Do we really need to copy the real-world parallel here? I'm open to ideas as to why we could or should, but I'm wondering if a four-letter system based on regionality (as an example) might have developed naturally early on. The three-letter code grants us over 17,000 options globally; doing a four-letter code grants those 17,000 options for each region. This means we're unlikely to run out anytime soon on either system.

Thus, my proposal is two-fold: if there is a desire for a regionally-oriented airport code, then we should default to the four-letter code altogether; if there is not, then we default to the three-letter code. I personally don't care which way we go, but I don't believe it is necessary to have two systems in place.

Thanks, everyone for your feedback! If there's a consensus starting to form below, we'll proceed accordingly. — Alessa (talk) 17:35, 23 November 2021 (UTC)

I'm a little torn here. It does seem somewhat logical that the four-letter codes would be the standard if only one is chosen as it allows for a larger overall number and has fewer conflicts. On the other hand though, I've always felt like the four-letter systems, at least as we have them set up right now, don't really work nearly as well for quickly recognizable individual branding/airport identity as the three-letter ones.
Just using mine as an example, Quentinsburgh Sean Bond International Airport in 3 letter is SBD- pretty straightforward. But in 4 letters its MFSB, where it's like "region M in a country that starts with F- oh Freedemia, guessing the SB means Sean Bond". Jhuandan's even more explicitly like this because the 3-letter code effectively is the city abbreviation- JHD. But the 4 letter code would be something like MFJH or MFJD which to me means nothing.
Maybe I'm just used to the way it is in the US where the three letters are standard for everything from airports to Amtrak stations, but I don't see the current 4 letter code system being as intuitive from the passenger or branding sides, even if they work better from a logistical behind the scenes standpoint for airport administrators or OGF convenience. --Ernestpkirby (talk) 17:52, 23 November 2021 (UTC)
That's an excellent point, Ernest. This is why, if I had to choose, I'd lean toward just using three-letter codes with something else for general aviation. The original codes in our world were developed for easy identification, and this has led to branding. I also don't see why we couldn't "expand the pot" by incorporating numbers in for things even if only for general aviation (2FD). Four-letter codes are basically a regional cataloguing system and too opaque for most people, also. — Alessa (talk) 17:59, 23 November 2021 (UTC)
I agree, ANACA codes aren't really needed. We're in no immediate risk of running out of WAAT codes, even if we don't add numerals to non-commercial airports (which is something I suggested way back when for FSA GA airports). Plus I don't think we've really done an "audit" of WAAT codes, and I'm guessing there's no small numbers of airports we could purge from lost nations.
Another option to consider: we could keep ANACA codes as the "default" self-serve code system for global airports, but restrict WAAT three-letter codes to airports that are actually reasonably mapped rather than just a node. -TheMayor (talk) 18:29, 23 November 2021 (UTC)
An idea - what about making the WAAT code four letters? I'm in favor of keeping it instead of ANACA, I'm in agreement with what Ernest said, but I think that the three letter code can be limiting sometimes, especially if two airport names are really similar, one of them is going to get the short end of the stick and end up with a code that doesn't make as much sense for it. Making it four letters could also increase the ease of understanding, so that if you see a code, it's easier to know which airport it is. And it does give more combinations. Either way, 4 or 3 letter abbreviations aside, I'm all for dropping ANACA from general use (I suppose it could still be used as a placeholder as Mayor suggested) and using WAAT. --Lithium-Ion (talk) 21:48, 23 November 2021 (UTC)
I like this option. Adds more total options and reduces the "short end of the stick" phenomenon Lithium mentioned. It might be especially good for cities with multiple airports or that use their name rather than city name for the WAAT code. But some may be easier to adjust to match than others- for mine it works pretty well (QSBD and QMAT, for example) but I'd want to hear other people's thoughts on their airports/codes and how it would affect them/their naming/how easy it would be to adjust. --Ernestpkirby (talk) 01:43, 24 November 2021 (UTC)
Airports getting "the short end of the stick" in terms of abbreviations happens all the time in the real world; there's no shortage of major airports that end up with airport codes that are legacies from way back when that make little to no sense in modern context. If we go a four-character code, there should be some sort of symbolism attached to at least one of the positions (e.g., first letter denotes the country/region the airport is in); otherwise, we should stick with the more familiar three-character code, at least for major airports. -TheMayor (talk) 02:18, 24 November 2021 (UTC)
To chip in on this discussion: from a point of practicality I'd suggest just using a 4-letter-code with no region-specific codes, as Lithium and Ernestpkirby suggested. Otherwise it adds another layer of complexity that some contributors will end up overlooking. It allows mappers who like to recognize their airports' names in the code to so, while no one is barred from using a random string of letters of course if they wish to do so. Whether we call that code "WAAT", "ANACA" or "ABC-Code" in-world is pretty irrelevant I'd say, but I'd suggest going with an OGF-specific name to avoid confusion with the real world codes. More importantly though I think that once we have an informal agreement on this issue we should set up a new "List of Airports"-page. I'd suggest not copying content from the old page but instead having each mapper re-enter their airpots; this is the most effective way of purging lost countries and have everyone double check the accuracy of their data (the Kojolese data in the old list is not up-to-date, for example). Leowezy (talk) 12:05, 26 November 2021 (UTC)
I think four-letter codes are perfectly fine, but I also think there should be some symbolism, as Mayor suggested, other than just simply creating a series of acronyms for airports named after random people (not the usual default in the real world anyway). Regardless, it's not a sticking point for me—just a preference. Also, Leo, you're in luck. I've been drafting a revision of the airports list but have held off on posting it yet until there was a movement toward consensus. As a rule of thumb, however, I actively and severely discourage just copy-pasting anything from the old wiki. (In fact, I hate that.) The table that is made will necessarily be different, meaning people won't be able to copy/paste regardless. — Alessa (talk) 15:03, 26 November 2021 (UTC)
If I had to say symbolism for the first letter of a four-letter code, I'd say city's first letters is optimal since it empowers both ones where the entire 4 letters is just the city names (like HNTG for Huntington, STTN for Stanton) or ones where the first couple letters indicate city and the latter ones indicate a specific airport/name (HTRG for Huntington Regional, STFR for Stanton Fiorino). Alternatively, I'd be okay with country, but that has less flexibility and there'd still be a lot of overlap in first letter (think of how many countries start with A, B, F, etc). I don't think regions would be a reasonable option because they have no practical relevance to passengers or for quick recognition. --Ernestpkirby (talk) 16:19, 26 November 2021 (UTC)
Firstly, I'm completely in for only using one code instead of two. Choosing how that code should look like is less clear to me. But since we already had a functioning system where all major airports got a 3 letter code, I'm not sure if we really need a fourth letter? Because the argument that a 3 letter code is easier to market and remember etc. does make sense to me. Getting the short end of the stick happens, but not that much and happens in the real world too. The only issue I can see is if suddenly everyone starts giving 3 letter codes to all of their small regional airports or aerodromes that won't have any international connections too, then we might run out quickly. What if we just do it similar to the international telephone codes on the old wiki? Smaller countries were asked to take a 4 digit number, while larger ones could take a standard 3 digit one. If we apply this to airports, we could keep a 3 letter code for all major aiports, but people wanting to give their small airports codes could take 4 letter ones, perhaps even taking a 3 letter code from a nearby larger airport and just adding an additional letter. Oh, and I would also drop any symbolism if we only have one code, since a third or fourth letter unrelated to a logically sounding acronym of the city or airport can really break it from a user/passenger perspective. It's not that a single letter could give much useful information anyway, so it's not really necessary to have symbolism. Squizie3 (talk) 15:46, 29 November 2021 (UTC)

Another idea: since whatever system we choose is intended to be a global system to handle international travel, and since the OGF planet has a large amount of small nations that are often connected over land, what if we created a unified system that encompassed both airports and major train stations? Since the latter are more numerous, train stations could have the 4-character code with airports using 3-character codes, while rail stations integrated with airports can use a special leading character + the airport’s 3-letter code (for instance, LCX airport has XLCX train station, with all “X”-band codes reserved for transfer stations)? -TheMayor (talk) 15:52, 26 November 2021 (UTC)

Could it be a trailing character instead of a leading character? That way the leading characters are more recognizable at first read? I'm not a huge fan of leading letters that make the code less immediately readable. My gut would say that LCXX, WFFX, SBDX etc are more recognizable as "this serves ___ airport" and would be more able to have non-airport stations follow a similar format (ex. LCUS or LCUN for union station and LCXX for Lake City Intl.) --Ernestpkirby (talk) 16:03, 28 November 2021 (UTC)
I’d say it would depend on the format used for the railway codes. If the leading letter is used for some sort of cohesive international system (like ANACA codes are now, with a geographic-based leading letter) it’d be nice to group all the transfer stations together, plus the leading letter of the airport code would almost certainly be non-compliant with the larger system. But if there are no other special requirements for any of the characters, a trailing consistent character would work just fine. -TheMayor (talk) 17:06, 28 November 2021 (UTC)
That makes sense. A requirement that the first character or two reflect the city or metro area name could potentially work across both systems without making either noncompliant (ex. SBD would become QSB with train station QSBX, Qburgh Cardinal Station would be QCDS or something) but I'm not sure that's worth requiring --Ernestpkirby (talk) 17:24, 28 November 2021 (UTC)
I'm not sure why we would need this extra complexity, for a system that probably won't be used by many people. For airports this is a widely accepted practice and it is used to map flights on maps or the flight tracker that's being developed etc, but you don't need that for showing train lines for example. For that, you would just need the relation viewer or add the route relation to a multimap, those 'airport' codes play no practical role. And for passenger purposes, you would just use the station's name and not a code. I know that in real world some stations have airport codes, but it's only a minority of stations for when there's a specific ticket-integrated air-rail transfer.
There are also a lot more rail stations than airports, and countries probably would roll out their own coding system like in the real world if they really wanted to. I think it adds complexity without many benefits, because someone should also manage that codes keep being used correctly and are not duplicated around the world, which in a few years time might create a lot of mess. Dealing with only defunct airports alone seems to be difficult, I don't think we want to expand that problem to rail stations if it serves no practical purpose. Squizie3 (talk) 15:46, 29 November 2021 (UTC)