People keep talking here about free (libre) alternatives like Open Location Codes or geohashes, but these aren't alternatives, because they aren't human readable in the same way. The closest thing I've found is the now-defunct 3Geonames[1] project which exists only in presentation archives as far as I can see, and that's only partly human readable.
The main issue in this space is that we need a standard, not a "better" standard.
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 trivial
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).
I always wondered, could this w3w geocoding method be done not completely random, but in such a way, that each subsequent word would narrow down the area? So one can easily understand that places like lake.cotton.juice and lake.cotton.horse are really near each other, and if their first word is there same they are at least on the same continent?
I don't think you could easily do that with 3 words. They already have a dictionary 40000 deep and then end up repeating words, just to get to get enough combinations.
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.
the genius of w3w is that address phrases are really short and easy to read and remember and input into any kind of device, over voice or via text. And 40k dictionary never seemed a problem with w3w, cause it is easier to remember 3 words, even the ones which meaning you don't even know than to remember a 8-char long string filled with random characters.
GeohashPhrase is an improvement, but still, the phrases in sample docs are just 3-4 words too long.
I think that w3w is over optimized and suffers from a large number of failure modes that interact poorly with a typical human's memory.
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.
We're working on the implementation (as time permits). Once we have that it will be published and accessible from search.qalocate.com.
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.
GeohashPhrase looks quite brilliant. Will there be an open source implementation? I hope so -- it's hard to see it gaining traction against w3w without it, and it is undeniably better.
Yes! The geohashphrase will be free to use and open source. Right now we're working on an implementation and docs and once we have that we'll release all that under a permissive license.
Right now the problem is that we don't have anything more than a description of our idea to release...
I don't mean to be snarky here, but what are you working on exactly? Geohashes are just base32, so can't you just decode that to bytes and then encode it as PGP word list?
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.
The goal here is to be more clever than just encoding to a list of random words. We want to encode to a good choice of words.
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.
I find plus codes to be a much better alternative. w3w gives you no information about proximity as the three words to locate your next door neighbor will be completely different. Plus codes however can be extremely short when in a confined context and they will even give you an idea of how far north/south/east/west and distance away. Plus codes are far better for those reasons imo
[1] https://archive.fosdem.org/2019/schedule/event/geo_3geonames...