Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The maddening mess of airport codes [video]

youtube.com

Post reply on HN
Print view View original

151–159 of 159 posts

Re: The maddening mess of airport codes [video]

#151

Post by ncpa-cpl »

makeitdouble wrote: post #111
SilverBirch wrote: post #88

This type of thing clearly just doesn't tweak me the way that it tweaks some people. I'm not convinced you could end up with a great way of assigning airport codes today, even if we completely started fresh and we assumed no new airports are ever created. In fact, in a lot of cases the weird corner cases are often situations where you can ask "Would it have been better to stringently apply the rule, or to bend the ru…

I’d argue if it was to be redone from scratch, we’d settle for hierarchical codes with country namespaces. Probably something like us.lax, fr.cdg, ko.inc, or a combination of country + number HK02, GB231 etc. Simple system get approved when there’s low friction in the ruling comitee, as it was the case when few countries were involved in the first place. Once more that 50 members need to agree on something restrictin…

> Probably something like us.lax, fr.cdg, ko.inc, or a combination of country + number HK02, GB231 etc.

This naming system has been for such a long time that I woud'nt be surprised if any minor change breaks something somewhere. Probably some old school database that can only handle three letters, uppercase and no punctuation characters. Or perhaps a modern app that depends on json generated by parsing txt output from a terminal. Or even a barcode format that can't handle any more characters.

Re: The maddening mess of airport codes [video]

#152

Post by taeric »

ratg13 wrote: post #143
taeric wrote: post #135

Earlier quoted context omitted.

If you are from the US, I have bad news for you about SSNs. :D

No, but I would assume that SSNs are not re-used. Is this not the case?

Well, I was certainly told that was the what happened once. Quickly trying to verify that now, I am finding the opposite on their site.

So, maybe I have good news about SSN values! :D

Re: The maddening mess of airport codes [video]

#153

Post by raverbashing »

selectodude wrote: post #128
makeitdouble wrote: post #111

Earlier quoted context omitted.

I’d argue if it was to be redone from scratch, we’d settle for hierarchical codes with country namespaces. Probably something like us.lax, fr.cdg, ko.inc, or a combination of country + number HK02, GB231 etc. Simple system get approved when there’s low friction in the ruling comitee, as it was the case when few countries were involved in the first place. Once more that 50 members need to agree on something restrictin…

ICAO code for Amsterdam Schipol is EHAM E - Europe H - Holland AM - AMsterdam

E is not Europe, it's "Northern Europe" and EH is Netherlands. LHR is EGLL for example

Southern airports in Europe use the L prefix like LFPG (CDG)

Re: The maddening mess of airport codes [video]

#154

Post by extraduder_ire »

allarm wrote: post #74
TazeTSchnitzel wrote: post #69

Earlier quoted context omitted.

There's many places where you can skip the area code or similar when dialling, but I think the original poster was thinking of systems where the actual numbering has variable-length components.

Variable length is solved by inter-digit timeout - pbx is waiting for a couple of seconds, then decides that the caller has finished entering the number and processes the collected digits according to the existing rules. Simple as that.

Always been disappointed that nowhere went with arbitrary length numbers for phone numbers, with the excess/end forwarded on to wherever the prefix is. I suppose that's not possible with the amount of time needed to actually do the switching, and would tie up a lot of switches before a call ever connects.

Or, assuming every number ends with many 0s that are omitted when dialling. Mainly to make extending the numbers easier, though you would lose 10% of the available ones.

Re: The maddening mess of airport codes [video]

#155

Post by travisjungroth »

2143 wrote: post #29
SoftTalker wrote: post #23

Earlier quoted context omitted.

I've also wondered why cryptically abbrevated things like NOTAMS are still the way they are. It made sense in a teletype/telegraph world where brevity was worth time and money. From wikipedia, this is a typical NOTAM: A1234/06 NOTAMR A1212/06 Q)EGTT/QMXLC/IV/NBO/A/000/999/5129N00028W005 A)EGLL B)0609050500 C)0704300500 E)DUE WIP TWY B SOUTH CLSD BTN 'F' AND 'R'. TWY 'R' CLSD BTN 'A' AND 'B' AND DIVERTED VIA NEW GREEN…

> Pilots have to know how to read and understand this stuff. Only justification I can think of is that like mathematical notation, this shorthand, once learned, is unambiguous and conveys meaning better than prose. I don't know if that's really true though. You're correct. It's straightforward for pilots. They can quickly read a NOTAM and understand everything. Also, it's pretty standard and unambiguous worldwide. As…

> They can quickly read a NOTAM and understand everything.

lol no. I was a pilot. I think you'd be shocked by how much pilots don't understand in METARs and NOTAMs.

Re: The maddening mess of airport codes [video]

#156

Post by krick »

Orthanc wrote: post #138
krick wrote: post #48

Maddening mess? Come on, this is silly nitpicking. Airport codes are as clean an logical as it gets with century-old international standards. In fact, most of "maddening mess" in the video can be essentially ignored, which author basically admits by stating closer to the end that these are used by different organizations for different purposes. It is just that story is being told backwards and in a snarky voice for d…

>It is just that story is being told backwards and in a snarky voice for dramatic effect, otherwise it would become clear that IATA codes are pretty much the most natural and logical thing in the world, which would rob author of a passable video topic. I think most travelers, including myself until I started working on this project, have never heard of IATA and only know the ICAO codes -- which do seem like a real me…

First off, you are obviously confusing IATA and ICAO airport codes: ICAO are the 4-letter ones. Second, I do not know why anybody would consider IATA codes a mess. These are just some arbitrary IDs that appeared one by one since some pre-historic times, are insanely informationally dense (just 3 letters, and I cannot remember from the top of my head the exact number, but there are definitely more than 3000 of IATA airport codes) and are very hard to re-assign or organize because of how global and distributed the system is. If anything you should be happy and astonished they resemble city-names in any way at all. Personally, I always found this pretty incredible, that hundreds of small cities with long (and often similar) names manage to have pronounceable and kinda "intuitive" 3-letter codes assigned. They could've been just numbers for that matter (it's not like you have to know them if you don't work in travel — any ticket has city names printed on it nowadays).

Re: The maddening mess of airport codes [video]

#157

Post by allarm »

extraduder_ire wrote: post #154
allarm wrote: post #74

Earlier quoted context omitted.

Variable length is solved by inter-digit timeout - pbx is waiting for a couple of seconds, then decides that the caller has finished entering the number and processes the collected digits according to the existing rules. Simple as that.

Always been disappointed that nowhere went with arbitrary length numbers for phone numbers, with the excess/end forwarded on to wherever the prefix is. I suppose that's not possible with the amount of time needed to actually do the switching, and would tie up a lot of switches before a call ever connects. Or, assuming every number ends with many 0s that are omitted when dialling. Mainly to make extending the numbers…

It is technically possible to use a pound key (#) as an end of input indicator. It is almost impossible to change the users habits though, not mentioning the need to reprogram thousands of telephony switches. Another (better) option here is packet sending of DTMF string - digits are collected on a smart user's device (i.e. iphone) and the complete number is sent as a digit string, not one by one. Problem here is that there are still lots of dumb phones that don’t do that. Analog lines (copper fxo/fxs interfaces) are also present even nowadays. So as usual, legacy and backwards compatibility are holding back progress.

Re: The maddening mess of airport codes [video]

#158

Post by Symbiote »

tow21 wrote: post #81
agurk wrote: post #78

Earlier quoted context omitted.

> Occasionally people put the space in the wrong place, like 0207 77777777 for a London number To expand on this, the codes have changed a lot over time. London used to have separate codes for inner and outer London, which at their last iteration were 0171 and 0181. These were replaced in 2000 with (020)7 and (020)8 respectively. At this point it still made sense, if inaccurately, to group the first four numbers. The…

Actually, London used to have one area code, "01". Then at some point it was split into inner & outer, and there was endless one-up-manship about whether you had an inner or outer London code. (obviously, inner London was posher)

I believe you -- in the large village where I grew up there was some daft division between having a 5-digit area code for a nearby town rather than the (nearer) large city's 4-digit code, and (along roughly the same lines) having as your official address rather than .

But it seems odd for London, when there are plenty of posh areas in outer London, and run-down areas of inner London. Maybe it was more for businesses to appear 'central'?

Re: The maddening mess of airport codes [video]

#159

Post by glaucon »

xattt wrote: post #90
lostlogin wrote: post #68

Earlier quoted context omitted.

Or just the date. The dumb game of dd/mm/yy versus mm/dd/yy when you live in a dd/mm/yy country is infuriating.

Write the month as a three letter code and your ambiguity is solved.

I'm not sure about the lack of ambiguity.... Christmas day is on 25-Dec-2022 or is it 25-Dic-2022 (German), or is it 25-Dez-2022 (Spanish) ?

At least ISO-8601 works for everyone who uses the Gregorian calendar, which is certainly not everyone, but it's a reasonable coverage.

Post reply on HN