I've never been clear on what plus codes are for... or if anyone is adopting them.
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?
I think it can be useful for communicating emergency location... but yes it seems like you would need your GPS on in which case it's better if your phone just texts or otherwise shares the location with whomever needs it. Maybe it's good for sharing location verbally over a call.
I think, it is similar what hexadecimal is to binary. It is its human-readable nature that is useful, yet, it is not immediately apparent how so--especially to the layman.
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.
The purpose of pulse codes are explained on the very first line of the linked page. (emphasis mine)
> 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.
It won’t be adopted as a standard until it’s reasonably usable. Right now it clearly isn’t. You can’t just drop off a package or a letter somewhere within the square.
If you live in the countryside with few or none street addresses and a really low population density (like a really big part of the african population) then you can.
But then I assume the postal service doesn't deliver to you anyways, and you're the one who goes to your local post office every few days to pick up mail and packages?
Just because you have coordinates doesn't mean it's suddenly cost-effective for the post office to deliver.
As someone who lives in Manhattan, there are many buildings that have entrances on 2-3 different streets: having an address that specifies where the entrance actually is is a feature.
Buildings generally only have one address, usually considered to be wherever the "main entrance" to the building is AFAIK. Additional entrances to the same building could probably be identified by the street they're on, but they won't have been assigned a street number.
> 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?
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.
I'm always disappointed that these systems are so hard to reason about. Plus codes are better than hashing schemes, but still require base 20 math. It's not clear to me what they're for.
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.
As I understand, lat/long is continuous, plus codes are discrete.
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?
And Daimler was also bribed into becoming an investor in what3words? Maybe Daimler looked at the various options and chose the one best for marketing (best to convince end users, press, investors what it is). Easier to add celebrities and puns in ads similar to Apple Siri ads https://vimeo.com/250456705
And there is at least one known instance of such system: many car navigation systems in Japan have support for Denso Mapcode [1]. Its algorithm is almost trivial but has a private mapping which effectively makes its entirty proprietary.
According to that link he wasn't able to get it invalidated. (not a lawyer, baseless speculation follows) There is proof that that guy did it first though, so if you get permission from him and then get sued by W3W then maybe you can claim prior art that way(?)
What3Words has some strange choices / consequences:
* 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
* If you accidentally mess up the plurals or spelling, you send people all over the place:
- cosmetic.takeover.fries is in Amsterdam
- cosmetic.takeover.fires is above the Pole Circle in Russia
- cosmetic.takeovers.fries is west of Shanghai
* Lastly, locations are 'named' quite randomly, with no apparent logic or explanation behind it. So, adjacent locations have a completely different name. How can we (or a mailman) deduct/reason about the 'address' of a neighbor, or the what3words for the other side of a property?
> How can we (or a mailman) deduct/reason about the 'address' of a neighbor, or the what3words for the other side of a property?
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?
Perhaps not a hard requirement, but a handy feature. It would be nice to know that "<number> <street>" is at least in the area of "<a number close to that number> <same street>" (if the city doesn't completely mess up giving out addresses).
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.
Both of the independent claims in that are quite specific about the conversions between locations and lists of numbers and between lists of numbers and lists of words being unique.
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)
Futility Closet podcast Ep 218 had a section on plus codes this/last week, including what3words and parodies like what 2 numbers - Lat, Lon! They have the full list of links.
Slightly off-topic, but is there anything in the design of W3W that mitigates the chances that a square would have an offensive/embarrassing combination of words? Besides a blacklist of problematic words? I imagine the probability that this would happen only increases for English words that are problematic in other languages.
In the HN people always complain that geocode systems are hard to remember and/or write and praise "readable" or "memorable" systems like what3words. I'm of course a strong opponent to what3words for various grounds, but more importantly geocode systems do not necessarily have to be human-friendly.
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.)
All an address really does is act as a set of instructions for a postal worker. It is not an explicit definition of location and can change over time. And mail companies will not necessarily maintain a database of the actual location of the letter box or door. It is enough to just follow the instructions. You need these kind of geocodes where a short instruction is not possible. A lot of Africa is like this. And maybe it could work for drone deliverys where you want to target an exact location.
> All an address really does is act as a set of instructions for a postal worker.
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.
I did mention the Mongol Post as an exception, so I think you do not really disagree with me. Also, I think human-readable addresses are really transitional (that is, there may exist needs for written geocodes as a near-replacement of addresses but not indefinitely).
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 really liked this, but their current website doesn't help their cause. Their old website dropped you straight into the map to find out any place's Plus Code, as well as a box to enter a plus code and open that location in a number of mapping apps/websites (Google Maps, Apple Maps, HERE, OSM...). It looked useful at first glance.
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.
Interestingly, if I drop my plus code into Google, it shows a pin in exactly the right location. But tapping the map graphic opens up the Google Maps app, which jumps to a location ~200 miles away.
It did that for me too. I found out afterwards that plus codes have two forms, a short and long. If you enter just the short form, it won't be accurate without the ", city" part (e.g. 2A6A+1Q is short form, must be entered like "2A6A+1Q, Beijing", long form of that would have another 4-5 letters in front e.g. 7XQW2A6A+1Q)
About 5/6 years ago, a team of 2 South Africans got an idea, and called it Waytag, the # for locations. The idea was that you tag a location with whatever you want, e.g. bob.home, and anyone looking for it would use !bob.home.
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.
W3W is one of the stupidest proposals I've ever seen, because it's proprietary. We want everybody on earth to need to pay licensing fees and contact a remote API to resolve address?
To call it mad would be far too kind. I may call it evil.
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).
> Their claimed solution when I read about this the last time was that similar words are designed to be very far off in order to make them obviously wrong
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.
> Their claimed solution when I read about this the last time was that similar words are designed to be very far off in order to make them obviously wrong, and showing similar addresses as a "did you mean" when you search for one.
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).
Just make sure you don't misremember it as "seasons.sharper.scans" (notice the "s" at the end) or you end up in Russia. One of the benefits of Plus Codes is that similar codes are close to each other.
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.
Plus codes are nothing more than discrete encoding of latitude and longitude. Compared to MGRS its not more compact.
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)
First is plus code in default accuracy 14m, second is decimal degrees with 11 m precision and the third is MGRS with 10 m precision. Each of them is discrete and identifies roughly similar area uniquely. You can add or remove accuracy by adding more decimals or characters in all of them.
I like the idea of a universal addressing system but I don't think we've found the solution yet to this extremely difficult problem.
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.
Schemes for international geocoding really shouldn't shrug off this altitude problem. When you say third floor, are you using 0-indexing, or 1-indexed floors as in the US?
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....
That's basically what plus codes do, plus some tricks (choosing the alphabet to make them unlikely to spell words to avoid offensive words, different algorithm for the last character, ...)
I suppose every possible system will be imprecise to some extent. This system thus loses precision too.
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.
Base 16 is shorter than base 10 but just as memorable. That would be a bit shorter. If you get rid of/consolidate the often confused characters (O/0, I/1/l), you can encode numbers into even smaller strings.
My first question was: how does this differ from alphanumerically encoding coordinates? It has to convey the same amount of entropy after all.
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).
> I have no idea what that plus is for, other than making it longer by branding each tag
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).
I've always wanted a system that accounts for adjacent physical locations appearing to be far apart upon truncation because they happen to sit on opposite sides of the imaginary dividing line. E.g. 39.99 deg North looks very far from 40.00 deg North upon truncation
I made this but for prices: I felt like I was subconsciously biased towards products priced just below some boundary. When looking at products, you don't necessarily come across them in order, and the prices are not always round (not just decimally round but I'd also say that 501 bucks is not round). Take the series 931, 900, 942, 878: at a glance (without carefully comparing them) I find it hard to know the relative differences. To solve this, I made this which calculates the relative difference on the scale of 10 to 20: http://lucb1e.com/rp/js/scale.htm
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!
You would need to use two simultaneous coordinate systems. It could be long lat p and long lat with an offset. If the offset version does not change as many digits as the standard then use that one. station curious and so much for machines, where the calculation is cheap. But it's for when you are trying to figure out if someone is next to you on a map or not. All of the coordinate systems that are grid-based including UTM have this problem.
Last time I checked, which was a few months ago, Google Maps couldn’t understand a Plus Code and said it couldn’t find the place. Even at that point in time, this system was supposed to be working for quite sometime and supported by Google.
I just checked again by getting a Plus Code for one location from the Plus Codes site and pasting it into Google Maps on a desktop browser. Google Maps shows a totally different place for it. Something still seems to be broken.
The main reason is "because Google is behind it so it actually has a chance to become a thing".
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"...)
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?