Hacker News Reader

Comment by reactordev | Hacker News Reader

So they forgot to "geographically disparate" fence their queries. Having built a flight navigation system before, I know this bug. I've seen this bug. I've followed the spec to include a geofence to avoid this bug.

View on HN

Why on earth do they not have GUIDs for these navigation points if the names are not globally unique and inter-region routes are commonplace?

1. Pilots occasionally have to fat finger them into ruggedized I/O devices and read them off to ATC over radios.

2. These are defined by the various regional aviation authorities. The US FAA will define one list, (and they'll be unique in the US) the EU will have one, (EASA?) etc.

The AA965 crash (1995-12-20) was due to an aliased waypoint name. Colombia had two waypoints with the same name within 150 nautical miles of each other. (the name was 'R') This was in violation of ICAO regulations from like the '70s.

https://en.wikipedia.org/wiki/American_Airlines_Flight_965

> Pilots occasionally have to fat finger them into ruggedized I/O devices

you're saying what-3-words (W3W) is unsuitable for safety critical applications ? /s

I'm trying to imagine someone ensuring differentiation between minimums.unsettled.depends (Idaho), minimums.unsettled.depend (Alaska), minimums.unsettles.depend (Spain), and minimum.unsettles.depend (Russia) while typing them in on a t-9 style keypad with a 7 figure display in turbulence.

That's easily fixed – just spell them out using the ICAO spelling alphabet!

I can't believe the What3Words person or people didn't normalize all words to be singular before canonizing the list.

That's ridiculous.

The word list is 40,000 long, so without plurals probably there aren't enough words that people could spell or even pronounce. A better fix would be making it "what four words" - I wonder if they'd already committed too much to the "three" concept before discovering the flaw? Either way, using phony statistics to make unwarrantable claims of accuracy is a poor workaround.

That seems like a huge flaw in their system, has it never been addressed?

No, and by my understanding it can't be, as the algorithm is now permanent.

But it's worse than that, there are confusables within small distances of each other:

https://cybergibbons.com/security-2/why-what3words-is-not-su...

https://w3w.me.ss/

Since the app gives you the words to say, and translates those back to coordinates on the receiving end, in theory they could alter the word list, at the cost of making any written-down version obsolete.

Maybe they should release a new service called What4ActuallyVettedWordsAndWordCombinations ;)

Aren't they trying to turn their word list into a subscription service? Obsoleting paper copies might be a feature.

Something like what3words might be useful, but what3words itself doesn't have enough "auditory distance" between words. (i.e. - there are some/many words used by what3words that sound similar enough to be indistinguishable over an audio channel with noise.)

Something like FixPhrase seems better for use over radio.

There are a number of word lists whose words were picked due to their beneficial properties given the use-case of possibly needing to be understood verbally over unclear connections. The NATO phonetic alphabet, and PGP word lists come to mind: https://en.wikipedia.org/wiki/PGP_word_list

I'm particularly a fan of the PGP word list (it would definitely require more than 3 words for this purpose, though) because it has built-in error detection (of transposition, insertion or deletion): Separate word lists are used for "even" and "odd" hex digits. This makes it, IMHO, fairly ideal for use over verbal channels. From the wiki: "The words were carefully chosen for their phonetic distinctiveness, using genetic algorithms to select lists of words that had optimum separations in phoneme space"

It sounds like the w3w folks did not do any such thing

EDIT: According to my napkin math, 6 PGP words should be enough to cover the 64 trillion coordinates that "what3words" covers, but with way better properties such as error detection and phonetic incongruity (and not only that, it is just over 4 times larger, which means it can achieve a resolution of 5 feet instead of 10)

> I'm particularly a fan of the PGP word list

As a New Zealander, the PGP list is unfriendly because there are plenty of words that are hard to spell, or are too US centric.

dogsled (contains silent d, and sleigh might be a British spelling)

Galveston (I've never heard of the place)

Geiger (easy to type i before e - unobvious)

Wichita (I would have guessed the spelling began with which or witch)

And why did the designers not make the words have some connection to the numbers e.g. there are 12 even and 12 odd words beginning with E - add 16 more E words and you could use E words for E0 to EF. Redundant encoding like that helps humans (and would help when scanning for errors or matches too)

I imagine it is even harder for ESOL people from other countries! I am sure the UI has completion to help - but I wouldn't recommend using that list for anything except a pure US audience.

I have been to Galveston and I can assure you that you have not missed anything. There is no good reason to visit or know anything about it.

Making a word list that could work well for speakers different English dialects and for speakers of English as a second language sounds really hard. Has such a list as been made?

Probably it is too hard so we will continue to ignore the problem.

Great ideas all!

It should be discussed like this! It's clear that the w3w people didn't even do the bare minimum here!

The thing is, once you agree that some words are subpar or need translations, you can do a 1-to-1 mapping.

The problem with What3Words is that supporting the original word set will always be a pain even if they release a v2 word set with a 1-to-1 mapping (I believe they've already released versions for other languages?)

re: Geiger- parsing it could trivially accept misspellings of words

I never knew there was a “sleigh” in “dogsled,” I’ve only ever heard “sled,” like “slid” or “skid.”

> It sounds like the w3w folks did not do any such thing

They were too busy spending money on marketing, it's not like every news organisation ran a story about it by accident

I mean there is the ICAO phonetic alphabet already known and used by every single licensed pilot the world over, regardless of their native language.

or, or... hang with me here for a minute...

We could instead use one of these cool new hash algorithms that require a computer and use about fifteen thousand English words! I understand they are all the rage in the third world countries that lack a postal system.

These are all lovely technical solutions. The problem I imagine isn't coming up with unique words. The problem is organizing a switchover for dozens if not hundreds of systems and agencies around the world. The chaos of change is probably out weighing the benefits.

what3words is not useful at all. 1) FAA (and thus the world) have a hard character limit of 8, this is to support old mainframes running (Delta, I'm looking at you) old unix dispatch software. 2) The cockpit computers have limited characters on screen. A FMC can display 28 characters x 16 rows at best. Most are 8 rows. Military aircraft have some that are 2 rows. The FMC or Flight Management Computer is really just an old embedded chip. 3) The entire airline, flight, tourism, booking, and ticketing systems of the world would need to change. Including all legacy systems, all paper charts, all maps, all BMS's, all AirBoss's, all ATC software, all radio beacons. There is no chance that any of this will change simply because someone came up with a way to associate words with landmarks you can't see from the air.

Many authorities on the subject warn against using W3W for safety-critical applications.[0][1][2]

Personally I could imagine that Maidenhead Locator System[3] may be more useful. It's just 4-12 chars (depending on what degree of accuracy you need)

[0] https://www.summerlandreview.com/news/bc-search-and-rescue-g...

[1] https://globalnews.ca/news/8258671/north-shore-rescue-what3w...

[2] https://www.squamishchief.com/local-news/squamish-search-and...

[3] https://en.wikipedia.org/wiki/Maidenhead_Locator_System

You could maybe make them globally unique by adding the country where appropriate like we do with Paris, France vs Paris, Texas? And not using the same name twice in the same country.

The names have to be entered manually by pilots, if e.g. they change the route. They have to be transmitted over the air by humans. So they must be short ans simple.

Clippy: It looks like you are trying to enter a non unique navigation point, did you mean the one in France or the one in Australia?

if only it were as simple as that - what about unique but easily confusable "human-friendly" identifiers?

As a layman, I'd argue that such efforts would be band-aid and better spent on robust standardization

Yes but shouldn’t one step of the code be to translate these non-unique human-readable identifiers into completely unique machine-readable identifiers?

How exactly would you do that? It’s impossible to map from a dataset of non-unique identifiers to unique identifiers without additional data and heuristics. The mapping is ambiguous by definition.

The underlying flight plan standard were all created in an era of low memory machines, and when humans were expected to directly interpret data exactly as the programs represented it internally (because serialisation and deserialisation is expensive when you need every CPU cycle just run your core algorithms)

Couldn’t you use the surrounding points? Each point is surrounded by a set of nearby points. You can prepare a map of pairs of points into unique ids beforehand, then have a step that takes (before, current, after) for each point in the flight plan and finds the ID of current.

That sort of thing happens already; for instance, the MCDU of an Airbus aircraft will present various options in the case of ambiguous input, with a distance in nautical miles for each option. Usually, the closest option is the most appropriate.

Yes you can, but that would be using

> additional data and heuristics

Directly mapping is impossible, so you cant just do a dumb ID-at-time pre-processing step (which is what your comment seems to suggest). You need a more complex pre-processing step that’s capable of understanding the surrounding context the identifier is being used in. A major issue with the flight planing system (as highlighted in the article) is that they attempted to do this heuristic mapping as part of their core processing step, and just assumed the ID wouldn’t be too ambiguous, and certainly wouldn’t repeat.

If two waypoints have the same name assume its the closest one to the adjacent ones in the route-chain rather than the one 4000 km away

Sounds like a helpful idea with considerable implementation complexity, including the potential for new disastrous failure modes.

But its how the waypoint codes work in practice - they are contextual. If Air Traffic Control tell a plane to head for waypoint RESIA, they mean the one nearby, not the one 4000 km away.

Have to admit, I read the article in full detail only after commenting and I see your point.

Especially since the implenting company is called out explicitly for failing to achieve this, and the risks of changing the well-established identifiers are also illustrated.

Perfect might be the enemy of the good then, or the standardization thing at least is a separate topic.

Not really because each point is only adjacent to a small neighborhood of other points, so if you want to test every possibility then your search space only grows by a constant factor proportional to the maximum degree of the graph.

As for implementation complexity, you would hope they would use formal verification for something like this.

Sounds like we should have globally unique human-enterable identifiers governed by an ISO..

Long story: because changing identifiers is a considerable refactoring, and it takes coordination with multiple worldwide distributed partners to transition safely from the old to the new system, all to avoid a hypothetical issue some software engineer came up with

Short story: money. It costs money to do things well.

> Long story: because changing identifiers is a considerable refactoring

is this what refactoring means

Yes. It would cascade into:

Changes in how ATCs operate

Changes in how pilots operate

Changes in how airplanes receive these instructions (including the flight software itself, safety systems, etc.)

Changes in how airplanes are tested

Changes in how pilots are trained

Etc. In this case, the refactoring requires changes to hardware, software, training, manufacturing, and humans.

Pretty sure that is still not the meaning of refactoring. As I understand it refactoring should mean no changes to the external interface but changes to how it is implemented internally.

You could see it as the whole international flight system being refactored, consumers will still use planes like before

We can pontificate on how to define the scope of a system here. I will only state that, from the perspective of a consumer, you could consider this a Service on which the interface of find flight, book flight, etc. would appear to be the same while the connections internal to each of the above modules would have to account for the change.

Functionally, I suppose it's the equivalent of upgrading an ID field that was originally declared as an unsigned 32 bit integer to a wider 64 bit representation. We may not be changing anything fundametal in the functionality, but every boundary interface, protocol, and storage mechanism must now suffer through a potentially painful modification.

does refactoring mean literally any non-local change even just like changing a variable name, or does it usually mean some kind of structural or architectural non-local change

Aviation protocols are extremely backwards compatible and low-tech compatible.

You need to be able to read, write, hear, and speak the identifier. (And receive/transmit in morse code)

Would it be okay to have an "area code prefix" in the identifier? Plausible (but practically speaking too late for that)

FAA regulations state that fixes, navs, and waypoints must be phonetically transmittable over radio.

I.E. Yankee = YANKY. The pilot and ATC must be location aware. Apparently their software does not.

I would guess because humans have to read this and ascertain meaning from it. Not everyone is a technical resource.

They do and use lat/lon in some cases. Reviewing and inputting that (when being done manual) is another story - but it's technically possible.

It sounds like for actual processing they replace them with GPS coordinates (or at least augment them with such). But this is the system that is responsible for actually doing that...

Because they need to be short, that's why they are 5 letters long. And need to be understood phonetically very quickly by pilots.

What three words would be a better solution than a guid, as transmittable over radio.

W3W contains homonyms and words that are easily confused by non-native english speakers. Often within just a few KM. The latter is why ATC uses "niner", to avoid confusing "nine" and "nein".

Talk to someone deep in the GIS rabbit hole and you'll get a rant about how bad W3W is: https://cybergibbons.com/security-2/why-what3words-is-not-su...

Wernher von Braun polled his reports for whether the rocket was reliable or not. Each engineer replied "nein".

Von Braun reported that the rocket had six nines probability of success.

Also, "tree" for 3 and "fife" for 5.

I always love it when someone helicopters in to a complex, long-established system and, without even attempting to understand the requirements, constraints or history, knows this thing they read on a blog one time would fix all the problems thousands of work-years have failed to address.

As software developers, we are often living in our own bubble. As a pilot and developer working on an aviation solution, I quite often run into this issue when discussing solutions with my colleagues.

Well, it would be hard for them to helicopter in with their navigation system. ATC would have a field day. ;)

WTW is a proprietary system that should never be used:

https://www.walklakes.co.uk/opus64534.html

The biggest fault (besides being proprietary) is that you must be online in order to use WTW. The times that you might need WTW are ALSO the times you are most likely to be unable to be online.

> The biggest fault (besides being proprietary) is that you must be online in order to use WTW.

That doesn't seem to be the case anymore.

It's still not a great system – many included words are ambiguous (e.g. English singular and plural forms are both possible, and an "s" is notoriously difficult to hear over a bad phone line), and it's proprietary, as you already mentioned.

It's definitely not the case, as the word list and algorithm are not secret (notwithstanding that they're proprietary) and have been re-implemented and ported into at least a couple of languages that allow for offline use. I have a Rust implementation that started life as a transliteration from Javascript. I wouldn't recommend using it, still -- I wrote it in the hope of finding more problems with collisions, not because I like it.

That would actually be pretty bad. As mentioned, W3W is propritary, requires an online connection, and has homonyms. On top of that, you need to enter these waypoints into your aircraft's navigation system - sometimes one letter at a time using a rotary dial. These navigation systems will stay in service for decades.

Aviation already uses phonetically pronounceable waypoint names. Typically 5 characters long for RNAV (GPS) waypoints, for example "ALTAM" or "COLLI". Easy to pronounce, easy to spell phonetically if needed, and easy to enter.

The problem is the list of waypoints are independently defined by each country, so duplicates are possible between countries.

Rather than replacing a system that mostly works (and mandating changes to aircraft navigation systems, ATC systems, and human training for marginal benefit)... an easier fix would just be to have ICAO mandate that these waypoints are globally unique.

If only there was a globally unique set of short two-letter names for every country that could be used as prefixes to enforce uniqueness while still allowing every country to manage their own internal waypoint list.

If only.

I'm sure they thought about this at some point. Airports already have a country-code prefix. (For example, airports in the Continental US always start with K.)

For whatever reason, by convention navaids never use a country prefix. Even when it would make sense - the code for San Francisco International Airport is "KSFO", but the identifier for the colocated VOR-DME is just "SFO". (Sometimes this does make a big difference, when navaids are located off site - KCCR vs CCR for Concord Airport vs the off-site Concord VOR-DME, for example.)

It's even worse for NDB navaids, which are often just two letters.

Either way, we're stuck with it because it's baked into aircraft avionics and would be incredibly expensive to change at this point.

Yes, but country-prefixes are something you could migrate gradually in a backwards-compatible way.

"Waypoint Charlie Alpha Dash ALKOG, over."

"This is an old machine, so just ALKOG then, over."

That's "What3Words" -- https://en.m.wikipedia.org/wiki/What3words -- a system for representing geographic location using globally-unique word triads.

Just curios, what language was used to develop?

ICAO standard effective from 1978 to only duplicate identifiers if more than 600 nmi (690 mi; 1,100 km) apart

Reply on news.ycombinator.com