Plus codes: addresses for everyone
plus.codes
plus.codes
Wikipedia says:
> Open Location Codes are a way of encoding location into a form that is easier to use than showing coordinates in the usual form of latitude and longitude. They are designed to be used like street addresses, and may be especially useful in places where there is no formal system to identify buildings, such as street names, house numbers, and post codes.
They don't seem all that much more useful than lat/lon for displaying/copying/pasting...
But for replacing addresses, there's no obvious 1-1 correspondance between a plus code and a building. A large building may span 20 or more plus codes, so which one would you use? Multiple homes might lie in the same one. Another house might be halfway in one and halfway in another. Even the front door can be right on the boundary.
Is there anywhere in the world where it's used for postal delivery, or anything practical at all?
OLC is also not the same as a GPS coordinate. What you get is not a point but a block, the size of which you can decide.
> A plus code is like a street address for people or places that don't have one.
Not everybody has a stable living situation at a building with a fixed address. Yet it's extremely important for people to be able to receive mail or packages, especially for people attempting to lift themselves out of poverty.
This system doesn't look like a replacement to the existing address system, they can both be used. But as you point out, it won't matter much until people start to adopt this as a standard.
Just because you have coordinates doesn't mean it's suddenly cost-effective for the post office to deliver.
If I give you my lat/long, how many decimals do I use? Will you be able to tell me from my neighbor? What if someone moves in to the same house as me, what’s they’re lat/long distinct from mine?
If I can remember my plus address it doesn't do me much good when my neighbor exactly below me has the identical plus address.
Also, I would think you'd find a lot of people have trouble remembering:
> 8GC2CMXR+X6
Though, perhaps at times all you need to remember is:
> CMXR+X6
MGRS is also based on 100x100km grid squares and it just uses easting and northing from the southwest corner. e.g.
4QFJ 1234 5678 is in square 4QFJ, at 12340m east and 56780m north with 10m accuracy.
4QFJ 12341 56789 is is in square 4QFJ, at 12341m east and 56789m north with 1m accuracy.
If there's a football field roughly half a kilometre to the north, that would be 4QFJ 123 573.
At the edge of the grid square, you may define an easting or northing that exceeds the bounds of the square. That's also fine.
MGRS is a much more complicated system for computers, but humans can create new coordinates and express the precision of their location relatively easily when working in a local region.
This same situation already exists for street numbers and doesn't present a big problem.
Redevelop a single-family house into a duplex and you may need to split an address. The usual solution is to add onto it, so that 1234 Elm Street because 1234A Elm and 1234B Elm.
Or redevelop a block of houses into a single, large apartment community and you might consolidate several parcels of land with their own street address into one. The usual solution is to just pick one arbitrarily. Maybe your property consolidates the land for 1230, 1232, 1234, 1238, and 1240 Elm, so you pick 1234 Elm because it is catchy.
In both cases, you put up a sign on your building or mailbox, and that's enough information for people to start using it.
Found an example: "The postal services of Cape Verde were the first to support plus codes for mail delivery".
Basically it splits the world into small squares, each defined by 3 common English words. Very easy to remember.
Actually, that means there's a bunch of money behind it, bribing carmakers to include it in their nav systems, etc.
It's still shit, but it'll be ubiquitous shit.
Tell that to aramex, dominos, Mercedes and united nations
https://www.futilitycloset.com/2018/09/24/podcast-episode-21...
- convert a 2D value into a single value
- divide that value up into 3 values
- there’s a 1-1 database of values that map a value to a word
Pretty much everyone on this site could come up with that concept given 15 minutes to think about the problem.
How is this patentable?
If not done more than a cursory reading of those claims, but I wonder if you could work around it by simply making some of the mappings non-unique?
I did not look at the dependent claims because generally if you infringe a dependent claim you necessarily also infringe the dependent claim upon which it depends. As the Federal Circuit noted [1]:
"It is axiomatic that dependent claims cannot be found infringed unless the claims from which they depend have been found to have been infringed."
However, a year later [2], that same court quoted that in another case, and then said:
"While this proposition is no doubt generally correct, it does not apply in the circumstances of this case"
The circumstances of that had something to do with the doctrine of equivalents being used to find infringement of the dependent claims, but the scope of the equivalents was wide enough to bring in prior art that would encompass the independent claim (but not the dependent claim), and so that prior art stopped infringement of the independent claim but not of the dependent claim--or something like that. I've not looked serious at patent law in a long time so this is getting into territory I'm now very fuzzy on.
My initial impression is that this would probably not apply if the alleged infringement of the what3words patent was a product that was pretty much the same as what3words except for not satisfying the uniqueness properties from that patent.
[1] Wahpeton Canvas Co., Inc. v. Frontier, Inc., 870 F.2d 1546, 1553 & n. 9, 10 USPQ2d 1201, 1208 & n. 9 (Fed. Cir. 1989)
[2] Wilson Sporting Goods Co., Plaintiff-appellee, v. David Geoffrey & Associates D/b/a Slazenger, and Dunlopslazenger Corporation Aka Dunlop Sportscorporation, Defendants-appellants, 904 F.2d 677 (Fed. Cir. 1990)
* If you accidentally change the word order for a location, you could send a mailman to a wrong and faraway location:
- http://map.what3words.com/help.driver.lost is in Chicago
- http://map.what3words.com/driver.lost.help is near Grand Rapids
- cosmetic.takeover.fries is in Amsterdam
- cosmetic.takeover.fires is above the Pole Circle in Russia
- cosmetic.takeovers.fries is west of Shanghai
why do we need to?
Why can't it simply be this string = this place. that string = that place ? Why does there have to be metadata indicating relative positions of things? US address on the same street have relative metadata, but ones on different streets do not. They may be around the corner from each other or they may be across town. You don't know, and yet we get along just fine. I'd also point to "Massachusetts Ave." in Boston and its suburbs which has the same damn numbers like 4 times and thus 660 Mass ave. gives you NO clue where the thing is relative to 658 which may be next door and miles away and it may be east or west, or both. Somehow we've been able to get along just fine without relative metadata on different streets or even the same one. Why should it be a requirement here?
With what3words, "///ladders.chimp.drama" is exactly next to "///thick.candle.enacts" and "///nails.spit.blaring", but you can't tell. Also, you don't know whether there are other addressable points in between. It would have been nice if there was more method in this madness.
I think geocodes should be compared to ZIP codes, not something else. They both mainly act as a machine-readable version of (approximated or more accurate) human-readable addresses. No one complain about ZIP (or ZIP+4) codes being numeral. They do not, nor can't, replace human-readable addresses---even the most accurate geocodes will require a room number or a PO box number to be the true replacement (unless you are comfortable about calculating three-dimensional WGS 84 coordinates with 10cm accuracy and forcing poor post carriers to resolve them :-). They might have to be verbally communicated for the short period of time, so shorter, verbally distinguishable, verifiable codes do help, but that's not the biggest concern.
If we already have ZIP codes, why do we need another system(s)? It certainly helps that:
- Geocodes can be automatically generated from (now universal) WGS 84 coordinates.
- Geocodes, once their algorithm is fixed, never change.
- Many geocodes offer a trade-off between the length and accuracy. Moreover, this trade-off is generally predictable.
- Some geocodes can be shortened and accurately recovered with the context (country or city).
In this regard, after having seen a lot of alternatives, I do think plus codes are close to being optimal. But it should be mentioned that their applications are always limited to what ZIP codes and human-readable addresses can't and geocodes can. (Mongol Post's adoption of what3words is special because there is no permanent human-readable addresses for many mobile settlements. But what3words is not superior to other geocodes in this particular application.)
For drone deliveries, users will simply let their smartphones determine GPS coordinates instead of typing geocodes anyway. This does not work indoors but flying drones won't get there :-)
I think you are unfamiliar with Japanese addressing. While it has been changing since 1962 the older style was basically instructionless. It was just a unique identifier for some place within the town. Maybe it'd have a number that corresponded to the plot of land being registered with the land registry, which in no way resembles a street number.
About the only thing you can say about addresses internationally is that they are pointers to a location. The definition of "location" varies wildly in specificity and there is no guarantee of instructions or relative location metadata.
The new website looks like a standard marketing page that is trying to sell me something I don't need, and they have also lost the third-party linking. I think the immediacy of its usefulness is completely lost now.
They had grand ambitions of licensing it to Google and the like. They patented it in a few countries (though there was prior art).
Suffice to say, though they got a few companies involved, the idea fizzled into dust. I think in addition to bad implementation, the idea of license fees probably put people off using the system.
I'm also aware of W3W, as there's been some discussion about it here in HN. I've seen +codes for a while on Google, but I've never needed to use them, as they look unfriendly to the mind. I personally think they're not as memorable as W3W, but if they are made/kept as an open standard, maybe they'll take off.
Part of the problem is that many people who could benefit from codes in lieu of an address (I'm thinking informal settlements where there are no formal street names), might not directly be in reach of a mechanism to generate or use these codes.
To call it mad would be far too kind. I may call it evil.
The Louvre in Plus codes:"V86P+C8, Paris" [1]
The Louvre in what3words: "seasons.sharper.scan" [2]
I'm much more likely to remember "seasons.sharper.scan" than "V86P+C8"
0: https://map.what3words.com/
On their map, you have to accept their non-GDPR-compliant cookie "consent" form in order to get access to the real interface, otherwise the cookie notice covers it.
Also, they have country-specific word lists. On one hand, that's nice because locals will be able to use it even if they're not familiar with the latin alphabet/the English language, on the other hand, it means you may be asked to search for misant.habiter.jaloux instead, at which point a plus code may become preferable.
Their algorithm also seems to be incredibly complex, requiring a 20 MB library (likely wordlists + workarounds to make offensive codes less likely). Their web site does not explain how it works, and varies between claims that the words were assigned randomly and claims that they weren't (shorter words in more populated areas, similar words far apart).
However, they've alleviated all need to discuss their technical benefits with their restrictive licensing approach, which guarantees that they will be unsuccessful while preventing anyone else from building a different approach based on words (both because it would create confusion and due to fear that they'll start costly lawsuits/claims).
I don't buy their claims. If they cared about human-friendliness and recognized the possibility of errors, the proper response would be to add an error detection scheme like barcodes. The use cases of what3words are even more diminished by requiring an app to see what's wrong.
> Also, they have country-specific word lists.
I do think the needs for localization is properly recognized (of course, one can get better geocodes by eliminating the possibility of natural languages in advance). But the resulting system is bad: they breaks down after the translation. And also as a native Korean speaker the word list is strange enough to me ;)
they also break down because systems like Siri are terrible about recognizing words in "foreign" languages (foreign being any language different from the one it speaks in, even if supported by the manufacturer).
Wow. We live in a world where people will drive off docks or down boat launches and end up in a lake because their GPS said that was the way to go.
In such a world purveyors of navigation aids really need to assume that there is no such thing as "obviously wrong".
I would think that what we would want in a system that assigns to physical locations elements of a sequence that has a natural ordering is to have the property that elements of the sequence that are near each other in that ordering correspond to physical locations that are near each other.
You can do such mappings using fractals. Here is an XKCD that shows such a mapping of the internet, associating with each internet address a place on the plane such that any group of consecutive IP addresses maps to a compact region in the plane: https://xkcd.com/195/
The same principle would work with a what3words-like mapping where the ordering is alphabetic ordering.
Besides, what3words makes you dependent on a proprietary database to map the words to coordinates, which as as far as I'm concerned is an instant deal breaker.
I think using MGRS (Military Grid Reference System) is better already existing standard if you don't want to use digital decimals. No need invent something new for no gain.
compare these three formats:
8GC2CMXR+X6 (14 m accuracy)
-33.3333 -33.3333 (11 m accuracy)
4QFJ12346789 (10 m precision)
Probably not useful, but fun to think about.
Street addressing is nice because the addresses with the same street name are on the same street organized by number. (generally at least--there are example of streets that stop/restart) And the numbering is collinear with the direction of travel. i.e. I walk along the street. And I know I'll pass 11XY to get to 12XY.
what3words was interesting but the words for the squares don't seem to be related to each other. From one square, I'd like to be able to generate the addresses of all the adjacent squares. (///jumped.spring.improving directly next to ///book.groups.hiking) and I can't generalize a larger square of w3w squares with an overarching set of words or something
playing around with the plus codes, they seem to increment in a consistent way but I haven't figured out how e.g. (a random example) W->E: _+HJV _+HJW _+HJX _+HMR N->S: _+HMJ _+HMC _+HM6 _+HM2
I also like that I can change the address reference box size based on how many letters I have after the plus sign. In case I want to reference my front door versus my entire city.
It'd be much easier filling out addresses in forms because I could type less info. But it'd be hard for me to associate a string on number letters to an area just in everyday life. Market St or Powell st carries more with it. And is streets aren't directly aligned with the boxes then that poses a difficulty.
Edit: found their doc evaluating other methods [link](https://github.com/google/open-location-code/wiki/Evaluation...)
Name +code, city apartment 3A
Like what? You can't shorten decimals without losing precision, and converting to, say, base64 is just as unusable by humans as plus codes.
How would you shorten lat/long?
If you just found lat/long to x decimal places it seems like the same thing.
However, I’m guessing plus codes allow you to express the same location more succinctly by expanding the character set from 0-9 to A-Z,0-9 and also structuring it with an area code. You can optionally drop the area code if you’re searching regionally.
On the air, I'm from EN82. That's a few counties. Enough for people to check a box and say they've contacted someone from this area, or spin their antenna to point more accurately towards my approximate location.
If I need to give more detail, that becomes EN82KM which gets to city level, or EN82KM10, which gets down to just a few blocks.
I could give two more digits and you'd be at my front door....
This[1] answer on the GIS StackExchange tells us that for a reasonably small area (small enough that it won't cover more than a small building, say 5 by 5 meters) we need 5 decimals. Since the longitude can have 360 major values, with 5 decimals each (so 360e5 possible values), we would need log(360e5)/log(10+26)=4.9 characters -- and since characters are a discrete value, we would need 5 characters. The longitude only has 180e5 values, but we still need 4.7 characters, so that makes 10 characters total in the worst case. For lower values, you need fewer characters, just like "21.491" is smaller than "121.491" (useful because the majority of the population does not live on the poles).
As an example of geographic coordinates in alphanumeric: one of the most extreme coordinates you'll ever find (very close to the maximum of common values for earth's population) is 87e13,azebi, which maps to -43.81703,-176.47678. If we are okay with including symbols, we can convey more information, though to get under 5 characters for latitude and longitude in all cases, we'd need at least 78 distinct characters (there are 96 in the basic ASCII set, so that's doable, but case sensitivity is annoying). An example of the same coordinates would be hcFx,m^^c. Only eight characters for a fairly precise location on the globe: real short, but I'd argue that it's not more useful than the case-insensitive variant.
While researching this, I realized that a good "human readable global address system" would not map 1:1 to coordinates because on the equator, one decimal (1e-5) difference is 1.1 meters on the ground, whereas in northern towns it would be much less. If you want to keep the codes as short as possible, it would be useful to leave a larger gap between each point of latitude the closer you get to the poles. This means they simply cannot be square.
Looking at plus-codes, they are case-insensitive and indeed 10 characters (when omitting the plus -- I have no idea what that plus is for, other than making it longer by branding each tag). And they claim to be rectangular pieces of land. This is no better than a blind base conversion (base 10 to base 36).
You can safely omit the first few charcters when the context is clear. Plus there essentially acts as a decimal point (to the point that less significant plus codes should be padded to `+` with zeroes, which is the only occurrence of zeroes in this scheme).
If all regions are sorta rectangular then it means exactly that it is not a blind base conversion because at the poles there would be a few triangles.
For coordinates, if you have point A at 39.99, point B at 40.00, and point C at 41.00, then this tool will show you that the relative distances are 10, 10.1 and 20. There is a huge gap between B and C, relative to between A and B.
I must say that I was surprised to see that it places B so low (only .1 from the base value), so my subconscious bias already shows!
Otherwise, they're designed to be unlikely to generate offensive terms, and the + makes it feasible to use a shortened code together with a given or implied city name. Most of the improvements in this space are small details, because turning coordinates into a string is a really simple problem (which also attracts a lot of "let's reinvent this"...)