That's only a partial plus-code, though, which relies on external positioning of Honolulu. The full plus-code is 4 digits longer, and with the plus itself, it's 11 chars vs. 12 for MGRS at 10m precision (14 for 1m, which is more than plus-codes can do).
If MGRS was too long, it could simply get a new encoding and be done with, or add the abbreviation system.
Also, that particular plus-code you used as example is not recommended. Reference points should be small features that will have low geocoding variance. Larger points like cities, or here whole islands, as there can be very large variance to the exact location derived from the name (i.e. the pinpoint location Google Maps finds you when you just search for Honolulu).
From the README:
> Rather than a large city size feature to generate the reference location, it is better to use smaller, neighbourhood features, that will not have as much variation in their geocode results.
> That's only a partial plus-code, though, which relies on external positioning of Honolulu.
Yes, a concept that is very human-friendly.
> Also, that particular plus-code you used as example is not recommended. Reference points should be small features that will have low geocoding variance. Larger points like cities, or here whole islands, as there can be very large variance to the exact location derived from the name (i.e. the pinpoint location Google Maps finds you when you just search for Honolulu).
You should take that up with the google devs I guess. The code I gave was generated by google maps.
The problem I have is that the reference points do not respect natural or human boundaries. Around where I live, the reference points Google Maps give are variously an adjacent town (the other side of a major river!) and a small housing estate which no-one living outside that estate will be aware of.
If Google want people to use this system, they need to give a choice of reference points.
It's also entirely broken, rendering the system unusable if you expect sub-kilometer positioning across different geocoding providers.
Whether something entirely defective is "human friendly" doesn't really matter.
> You should take that up with the google devs I guess. The code I gave was generated by google maps.
Not my responsibility. That they cannot even use it correctly as per their own docs themselves doesn't make for a good sales pitch. In fact, Google Maps cannot process plus codes using arbitrary reference locations, making use per the plus-code documentation impossible with it.
To give an idea of why that plus code is borked:
Honolulu @ Google Maps: 21.3069444,-157.8583333
Honolulu @ Bing Maps: 21.30493,-157.85788
The difference is around 300 meters, which results in an absolutely awful error margin, and I'd argue that this is very much one of the best-case scenarios. That's worse than if they had added 2 more characters to the plus code, and just removed the Honolulu part.
I think you misunderstood the way these reference locations work. Both google maps and bing will resolve the given plus code to the exact same location – a margin of error of 0cm.
It's only important that the reference point doesn't leave the 40km square that it's supposed to be in. Google Maps might actually have a smarter implementation than the docs suggest. If the whole city is in the relevant 40km square, using it as a reference point is fine.
Yes, I misinterpreted the problem slightly. Rather than always being a problem, it is only a problem if there is uncertainty to which lat/long degree the location resides in.
It appears to search for smaller and smaller features until it finds something that does not span multiple areas, while still being within the same area as the final location. For example, for a random address on Hawaii, the plus-code becomes "74FF+W7 Ocean View, Hawaii, USA", as Island of Hawai'i spands multiple lattitude degrees.
However, this results in increasingly complex reference points, and I am not sure whether this can be done in a generic fashion. Of course, it may simply bail out to full codes at that point.
It would be nice for the code to have some kind of 'check digit', so that the code cannot resolve if the geocoding returns the wrong square, or if any letters are off-by-one or transposed.
Check digits don't work well with truncatable codes though :-(
I realize now I meant some kind of error correcting code, combination. Like this:
1
1 can be followed by either odd numbers or even numbers. If followed by an even number, the next number must be odd.
127
Now if you truncate that to 12, crucially 12 has the same meaning as 11. 1 and 2 to have the same symbol meaning, but are using "sign" to hint at the next number.
This will greatly reduce the chance that a random number will pass for a position. This can be made more elaborate, with more or less advanced encodings. The problem is of course that you waste bits on redundancy and so addresses everything else being equal, will have more characters in them.
I'd argue that this would never be done by hand anyway. The average user will not understand the encoding, and I doubt many will think "Hmm, I have this plus code, but I'd like to only have 1/20th of the precision."
Programmatic truncation would still be very easy, as it would just require a new checksum to be calculated post-truncation.
Ah, of course, a mistake on my end. I mixed up Honolulu, the city, and O'ahu, the island while looking up the plus-code due to misinterpreting Google Maps' peculiar choices of font cues for countries, islands and cities. I am not very familiar with Hawaiian geography.
Honolulu was the only large name on the island, with O'ahu being written in a similar font-size to all the other cities. Of course now I can see that the cue is that the island name is written in black, whereas cities are written in very dark grey...
It's a referenced plus-code, which "saves" 4 digits.
Instead of being a true location like the full plus code, coordinates, or MGRS, a referenced plus-code requires a referenced location to resolve (think "124 meters north of the postal office"), and the precision becomes entirely dependent on the precision of the services used to resolve the reference location (i.e. Google Maps might consider the exact location for "Honolulu" to be somewhere else on the island of Honolulu than Bing Maps).
No, they do not work relative to a point. You replace the first 4 digits of the code (the area code) with a location name that's clearly in the area, the following digits stay the same. The name resolution of the location can be off by kilometers and it still works.
While you are correct in stating that the point is only used to resolve the area, you conclusion is off by kilometers (he he he).
When using a point to resolve a 4-digit code (1x1 degree, approx 100x100km), it is true that anywhere within the same 4-digit-equivalent area will result in the same location.
However, while this improves the average case compared to point referencing, it makes the worst case absolutely horrendous: You'll end up referring to a wrong long/lat degree, meaning an error of over 100km!
The closer you are to the edge of a lat/long degree, the more vulnerable you are. If your location is, say, 10 meters from the edge, then 10 meters geocoding imprecision is all it takes to cause a >100km error.
Which is exactly why the plus-code readme says the following, as I have quoted before:
> If the reference location is derived from a town or city name, it is dependent on the accuracy of the geocoding service. Although one service may place "Zurich" close to the Google office, another may move it by a hundred meters or more, and this could be enough to prevent the original code being recovered. Rather than a large city size feature to generate the reference location, it is better to use smaller, neighbourhood features, that will not have as much variation in their geocode results.
In order for the reference system to work, references must either be close to the center of a lat/long degree (which allows great error margins on geocoding), or use points which have consistently high precision.
Neither case result in memorable reference codes like "XYZ Honolulu", so just using the extra 4 digits is the only sensible choice.
In my opinion, a big disavantage of MGRS is that it is based on UTM. These days nobody uses UTM and UTM is hard to grasp if all you are used to is lat/lon coordinates.
So the clear advantage of Plus Codes over MGRS is that it is based on lat/lon
Nobody uses UTM? Whaaaat? UTM is widely used in many many geographic endeavours. It was the de-facto standard for almost any analytical work during my master's and I bet still is. When you're dealing with smaller areas than a country or the whole planet, there's a ton of value of using linear units instead of arcs.
Once you try to do any meaningful spatial analysis, you're projecting your lat/lng to a linear unit. And UTM is possibly your first choice of projection depending on context.
Spherical coordinates systems are always a tradeoff between usability and simplicity.
Plus Codes are certainly simple, easier to calculate, and consistent, but UTM has clear advantages in that it utilizes a Mercator projection adjusted for the contour of the earth, so that distances remain close to scale within any given grid zone…
…except in Norway.
In Plus Codes, the scaling is lost, and the distance covered by coordinates of equal precision changes dramatically with latitude.
Of course, there is also the fact that the mapping ellipsoid used by UTM changed at some point, so old coordinates can be off by up to 200 meters compared to the current mapping. But the current system has been in use long since the advent of GPS, so it's really not an issue.
UTM is widely used and is the standard way of expressing position within many countries, where lat/lon is second-class citizen on everything but phone navigators.
I imagine that you wanted to put focus on "second-class", but if we focus on "everything" we would have a compelling argument for lat/lon as a base for a transmission format.
I've seen a few maps where the first page states what grid zone and 100,000-meter zone the map is in (for the honolulu-example, "Honolulu" would imply 4QFJ).
I’m not so sure 6GCRPR6C+24 is a great replacement for an address, but maybe I just don’t know.
Although I could memorize my own address, I’d have a hard time memorizing my friends’ addresses. Yes, nobody knows each other’s phone numbers anymore, but those were a very temporary relic from a very short span of time (the telephone era). Humans have always known each other’s addresses, and have always spent a lot of time telling each other their locations in the form of a spoken address.
On a more technical note, I am guessing this works super-well for auto-completion, but didn’t see any example of that in the README...
All of the various geonaming systems seem very Esperanto at the moment. I think we (as in all of us, the global community) could build upon Google’s effort to come up with a much more human-friendly system to provide easy global addressing. Yes, the address format system is way too localized and breaks down at both scale and small distances; whatever that code was at the beginning of my post (I’ve already forgotten it, and I’m too lazy to re-paste it) is just not nearly as easy to remember as “100 Ocean Drive” or whatever. I also have no clue how I might represent the building next door.
There's a feature that vastly improves the human usability for Plus Codes. The least-precision, first-four characters can be omitted and replaced with the City / Region name: e.g., "Nairobi PR6C+24". Considering that uniquely identifies just a few square meters of space on Earth that seems pretty good.
Surely the point of truncated codes is that they are used in contexts where other information makes clear the rest? So if I'm talking about things in the UK and someone says they live/work/whatever at "FWG3+2G, London", I already know which London.
As https://xaddress.org/ says, "4 BILLION PEOPLE DO NOT HAVE A FUNCTIONAL ADDRESS ACCORDING TO A UNITED NATIONS ESTIMATE" (Not sure why they say it in caps, sorry.)
This feels like an accidentally arrogant, Western-centric way of looking at addresses that might not conform to our description of an address. Like, “the White house on the hill in John’s village” is as much of an address as 12 Whitehouse Lane, Johnsvillage CA or whatever.
This is the same as saying people don’t have money because their wealth is in forms that aren’t immediately liquid, or translatable into dollars... We need to tread carefully here. Especially if we want people to actually embrace this over far more human-friendly existing forms.
> This feels like an accidentally arrogant, Western-centric way of looking at addresses
nope, many places simply do not have addresses. many places do not have streets. And unless you can find a more global addressing format that does not require translation of complex sentences we can only use location based addresses for a lot of places.
Essentially a plus code is something that you can paste on amazon for a delivery.
Now we could say that web giants like amazon are a danger to the world, a danger ever so ominous as so alluring. Still to the aim of identifying a place for delivery many places do not have addresses.
The primary users of these codes are places where politics prevent addresses from being assigned (government doesn't want to admit people live there). The codes give them a real address that your phone can navigate to, and for them it's working just fine.
I have asked this question to a member of the Google maps team, and have not gotten a precise answer. Is there some scheme which can distinguish between floors of a building? This is very useful, for example, store locations inside malls. The LatLong scheme does not seem to be enough. I'm guessing that it will have to be 3D, but I have never heard of a standard location scheme which incorporates this information.
This may work, I should try this. Can current smartphone resolution decide the elevation difference between the first and the second floors of a building?
lots of phones have barometric sensors that can be used for more accurate elevation differences. sadly it seems to be a "premium" feature and i can't find it in any phone <300 dollars in price
https://ieeexplore.ieee.org/document/6817923
Those sensors you are referring to are not reliable enough to tell elevation accurately. In addition to that, buildings may have different pressure to the outside
i have successfully told the difference between the ground and 3rd floor with a galaxy note 3's barometric sensor(for triggering home routines only when actually at home vs just arriving at the location)
To reliably triangulate elevation from GPS data you need quite a lot of satellites. Air pressure gives a better signal, but obviously needs to be calibrated for weather etc.
Yes, this is the current solution. I am a bit dissatisfied that it is not a "uniform" address scheme. It would be nice if an app can guide you to the exact store on the exact floor based on one location code.
Floors can be weird; I’m not sure how you’d handle a hotel skipping the 13th floor, for instance. Also, are floors 0 indexes or 1 indexed? It therefore probably shouldn’t be built into the protocol.
Who determines what is the "first floor"? Last week I had a medical appointment. The doctor's office was on the 6th floor; but, it was 7th floor counting up, as the building's ground floor is the "Lobby."
This is normal in many countries but it's extremely uncommon in theUS, where as you implied the ground floor is typically the "first" (in the numerical sense) floor.
The AliLocator is flexible enough that whole structures can be sub-divided by any arbitrary criteria, with floor as potentially one of many. Since the AliLocator itself would be a bit awkward to use, you'd just want to create an LNS entry that then pointed to it.
right, I can't see anything about distinguishing floors and doors. I'm pretty sure there are large amounts of people who need a floor and door added to their identifier in order to - what was it again "receive deliveries, access emergency services, register to vote – and more."
"Codes that are similar are located closer together than codes that are different."
I dug hoping to find out how they handle boundary effects, and gave up.
The numbers 0.999999 and 1.000000 are far apart in Hamming distance but close in position. What bounds are achievable for the maximum Hamming distance between two nearby locations, in any such system? Do they approach the theoretical limit here, or is "that are similar" a crock that only sometimes holds?
For example, for a base 12 location code one could overlay a dodecahedron onto the earth, then rotate it by a low-discrepancy sequence of quaternions for successive digits. This would have very nice bounds for the maximum Hamming distance between nearby locations, at the expensive of efficiency: each successive digit subdivides the location by far less than a factor of 12. As locations approach each other, vanishingly few rotations will distinguish them.
One can imagine easy fixes for this scheme, but what is the theory? Do they have a theory? Do they implement it?
I only knew of the 6-character location code, which is typically used when identifying yourself, but it seems there's the expanded version of up to 10 characters.
What I don't understand is the usage scenario. Plus codes are not human-friendly like street addresses, so I'm assuming they're meant for machine processing. But there you have all these other systems like HAM location codes or MGRS, that I don't see added value.
This is an interesting alphabet, even Base58 (Bitcoin addresses) have "o" and "1".
There's some information on how they generated it here in the spec[1].
The characters that are used in Open Location Codes were chosen by computing all possible 20 character combinations from 0-9A-Z and scoring them on how well they spell 10,000 words from over 30 languages. This was to avoid, as far as possible, Open Location Codes being generated that included recognisable words. The selected 20 character set is made up of "23456789CFGHJMPQRVWX".
Others have noted ambiguous character, but an equally important factor was to avoid swear words in all the languages that use the Latin alphabet (or have a latinized form like Russian, Chinese and others)
It is almost impossible to make words out of the allowed characters
Perhaps there's an underlying psychological advantage to using Plus Codes. This past week I had to manually transfer coordinates of various locations from one handheld google machine to another google machine. It was less tedious to use the Plus Codes.
Yeah, that's what3words (https://what3words.com/), which (IMO) makes for easier to remember words. It's available in multiple languages too, for the non-english speaking world.
I do work in rural Kenya, and the big problem what 3 words has is that the words are totally randomly allocated around the world. A REALLY important attribute of addresses is that they can be vague.
"He's on High and 23rd", "I live on Monroe", "Near Jomo Kenyatta Airport", etc.
The biggest mistake what 3 words made was not making the first two words be a geocoding of the approximate area and the last word could provide additional precision. It looks like google plus codes fixed this which is actually a huge improvement.
Knowing your neighbors address tells you nothing about your own address. To be able to get your address, you need a smart phone, and at that point you could just send me a pin with your exact latitude and longitude.
Approximate locations are dramatically more useful for navigating in much of the rural developing world. "How do I get to village X" will have an answer for 10 miles around. "How do I get to X lat/lng?" will be met with a shrug, both from google maps which will suggest you drive through a field and from anyone you ask.
If you can make something that works at the village level, you can bootstrap people getting their location. If the first word provided approximately "country" level information, the second provided approximately 1km bands (what you get if you evenly divide the three little words partitions), and the third gave you the 3m resolution grid, people without addresses could know their approximate address from others.
Basically, there's a bootstrapping problem and a usefulness problem. Right now, no one knows their 3 little words number. To become useful, most people need to know their 3 little words. How do you cross that gap? One way would be to have it be useful to know "2 words" or some approximate identifier for your region and then after locating you approximately, your service provider can tell you your last word.
This is a general problem with solutions in the space. Part of the niceness of say geohashes is that they telescope down.
The startup I'm involved with has developed what we call a geohash phrase. The core idea is to map English (or whatever language) words to the characters of a geohash. We usually map a word two-characters at a time, giving us 10-bits of precision for each additional word. So your location might be something like: "The big dog walks near the red house."
What is nice is that the phrase telescopes. So you can be vague when you want and only provide say the first three words of your location.
It's beautiful except that (1) it could vanish instantly and irreparably if they went bust, because it's not a public database and (2) I'd rather not have a single corporate entity be a gatekeeper of my ability to locate things.
Unfortunately (or fortunately, since it's rather controversial), they made it proprietary, which means it's basically dead regardless of merit.
Also, I believe that they require large dictionaries, which makes it hard for apps to support it on low-end mobile. Wikipedia says ~10 MB for their database.
> Cheap GPS devices have existed for at least 14 years [etrex], and yet latitude and longitude coordinates are still not widely used by people to specify locations. We think that this shows latitude and longitude have too many disadvantages to be adopted for a street addressing solution.
But still, isn't their solution just a "wrapper" around gps coordinates? How is it different than encoding 2 decimal numbers into a short text identifier?
I wish delivery services (mainly food delivery) would accept directions using this, like "Appartment block entry at XXXX+XX with entry code YYYY, building entry XXXX+XX with door code ZZZZ" (with code parsing somehow).
They keep getting things wrong for my location, but things like that (= simple and integrated with maps) would make it easy.
What's neat about this is its simplicity; its unencumbered nature; and its independence from any particular mapping or ontology beyond "a rectangularish portion of the surface of a sphere".
One neat application is for biologists recording locations of field samples.
Aside, if you ever have to do location based matching, having an index on hashes for rough locations with neighboring locations in multiple passes will often be faster than geo indexing.
This is really cool, but not really that much easier than coordinates. The good thing about coordinates is that you can choose the kind of granularity you want.
The biggest issue with solutions like this isn't that they aren't clever, or even that they aren't better than say a geohash or lat/lon, but that they have the wrong target. Computers don't really care since its just as easy to parse a geohash, a lat/lon, or an open location code. The tricky bit is when humans get involved.
Its humans that have way more limitations when it comes to using complex systems. And frankly, humans still use addresses because the system co-evolved with us and our needs. Addresses solve the problem well enough, and have "outs" for when they don't work. For a bit more in-depth discussion on this see: http://qalocate.bamsaas.com/2018/04/04/addresses-are-complic...
So if we want to replace addresses, then we really have to think outside the box. Fortunately, the web has done a lot of the heavy pushing by introducing all kinds of new, useful, and exploitable semantics that we can apply in other domains.
Humans are pretty good at using names for things. When computers were first networked, we soon replaced IP addresses with names. Thus was DNS born. We then combined that with another id, and soon we had email.
We believe that a similar system can be used for locations. No one really cares about the exact geohash or lat/lon of a location, or the niftyness of your coordinate system. Instead, what we need are memorable names. So why not just use names?
For example, I can have "thelittlenag.frontdoor" if I want to point someone to the exact coordinate of my front door. If I want drone deliveries, then maybe I tell Amazon to use "thelittlenag.deliverydrone". The lawn guy can use "thelittlenag.propertyboundaries" to figure where my property lines start and end. And "thelittlenag.house" and "thelittlenag.gardenshed" can logically reference as entities(!) the two structures we have on our property.
I too have developed and patented a location encoding system. Perhaps we could work together.
i don't know how to PM you. If I make a contact request on your website, will that work.
Plus codes don't seem to have any advantage over widely used MGRS (Military Grid Reference System). https://en.wikipedia.org/wiki/Military_Grid_Reference_System