[1] https://archive.fosdem.org/2019/schedule/event/geo_3geonames...
At QA Locate we've been working on a solution to this that we call GeohashPhrase. It encodes a geohash as a sentence.
There are some light docs you can reference here: https://www.qalocate.com/resources/
And we have a video on the tech here: https://www.youtube.com/watch?v=nlscJ8MOPjM
I'm working on some better preliminary docs, but working code takes priority ;-)
Btw, the GeohashPhrase will be open source and free to use.
Adding another standard makes the problem worse, not better.
The task of representing a pair of numbers is trivial, solvable in countless different ways, and none of the solution is clearly superior to the others. It matters much more to have a commonly agreed solution, than what the solution is.
The task of representing a pair of numbers is also not what any of these systems do.
"Two numbers" work because they're taken from an infinite set. Longitude lines are not parallel. Near the poles, moving a degree is only a few inches, while near the equator it is miles. This works for latitude and longitude, because these numbers are taken from the infinite set of real numbers between 0 and 180--if you want to represent more precision near the equator, you just add more digits on after the decimal point, and if you want to represent less precision near the poles, you just ignore the excess digits. In practice, on computers, they're represented as doubles, which have enough precision that we don't need to care that they aren't reals.
However, if you're mapping into a finite set, this falls apart quickly. The finite set for W3W is the set of permutations of 3 words taken with replacement from a set of 40,000 words. This gives them 40,000^3 combinations, which means they can represent points about 9 feet apart all over the world if they distribute these points fairly uniformly. But if they just trivially convert them from latitude and longitude, they won't be uniformly distributed--they'll be distributed tightly packed at the poles, and distributed loosely packed near the equator. This means your locations won't give much precision near the equator (where more people live) and will be more precise than GPS can measure near the poles (where almost nobody lives).
You can add more precision at the equator by adding more words to your word list, but it's already 40,000 words, which is more than humans can reasonably check, which is why there are a lot of homophones and sound-alikes in the list. You could also add more precision at the equator by adding more words, but it's obviously more desirable to say, "elephant.cheese.traffic" than "elephant.cheese.traffic.indigo.query.crenelation.trample". It would be much better if we could take some of the points we mapped to the poles, where we've got way more precision than we need, and put those points near the equator, where we don't have enough precision.
So now you're looking at the mathematical problem of packing points on a sphere[1]. It's not a solved problem, but there are good enough approximations (and "representing a pair of numbers" is not one of them).
[1] https://stackoverflow.com/questions/9600801/evenly-distribut...
With the GeohashPhrase we intentionally telescope exactly like you've described. This is because all we do is encode a geohash, and it already has this property.
GeohashPhrase is an improvement, but still, the phrases in sample docs are just 3-4 words too long.
For example, it is really easy to mis-remember and accidentally pluralize or re-order words. Our memories just don't maintain that kind of precision. Yet w3w will happily accept your mis-pluralized word, or re-ordered words, and spit out a location, with no indication that maybe you made a mistake.
w3w forces you to remember and use exactly the 3 words they gave and nothing else, without risking a garbage-in-garbage-out scenario.
In fairness, they do try to put similar words very far from each other, but unfortunately this only mitigates the risk and doesn't eliminate it.
Our design is resilient to these issues in human memory with the geohashphrase. If you re-order words in the phrase, pluralize (or singularize) a word, or even go so far as to change part-of-speech (e.g. noun a verb) then you'll still get back the same geohash.
Btw we hope to offer 4-base-word phrases for well populated locations. Those phrases should be easy enough to use in everday situations. Outside of that you can get complete coverage with a 5-base word phrase.
btw, search.qalocate.com (as advertized in a video) does not work, and also has an incorrect certificate. Please fix, would be nice to toy with it.
The cert is "wrong" because I redirect back to qalocate.com and that cert only covers the base domain. We have another for all the sub domains but that isn't used by our main site.
My hope is that we'll have something in the next few weeks but its only me (fulltime) and another guy (spare free time), so things move slowly.
Btw, thank you so much for watching the video! I hope it was useful.
Right now the problem is that we don't have anything more than a description of our idea to release...
In Python, the base32 to bytes exists in the standard library, and with an import[2] you can get the code to convert bytes to PGP word list. Literally 2 lines of code.
Partly, that means choosing words that are short, aurally clear, unambiguous, in common usage, etc.
It also means we need words that together form a sentence. Initially that means choosing a good sentence structure. Our is [1-Adjective 2-Noun 3-Verb 4-Adjective 5-Noun (6-Adjective) (7-Noun)]. Next, we have to choose words that are most often the part of speech for the dictionary they need to live in, since we'll never re-use a word.
Getting this dictionary together and having it good is a huge task. Of course we have a naive dictionary, but that's barely suitable for testing purposes.
I may choose to make the "docs" I've written available today in their rough state. That will explain things slightly more.
PGP word list already did the "short, aurally clear, unambiguous, in common usage, etc." pretty well. But the way they're structured doesn't create sentences, and I can see how creating sentences would be helpful.
[1] https://3geonames.org/ [2] https://3geonames.org/riga.html#slide=1