Open Location Code
github.com
github.com
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
MGRS: 4QFJ12345678
Plus Code: 835M+Q7 Honolulu
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.
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.
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.
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.
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.
Check digits don't work well with truncatable codes though :-(
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.
Systems such as what you describe are too complex and non-standard.
Programmatic truncation would still be very easy, as it would just require a new checksum to be calculated post-truncation.
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...
UX, yo.
4QFJ12345678 has precision 10 m. Example of plus code with comparable accuracy: 73F69J3M+VV
10 km accuracy in MGRS is just six letters: 4QFJ16
100 km accuracy is just 4 letters: 4QFJ
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).
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.
So the clear advantage of Plus Codes over MGRS is that it is based on lat/lon
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.
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.
MGRS doesn't use a charset that doesn't have ambiguous charachters.
Just two. Might be minor, but it's not no advantage at all.
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).
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.
"9C3XFWG3+2G" is barely any shorter than using coordinates, but "FWG3+2G, London" is significantly easier to read or write down than coordinates.
I guess this isn't really aimed at you.
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 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.
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 same spot, to +-1.5m is universe.renovated.upon as opposed to 6GCRPR6C+24
Almost all English speaker do not need these codes.
Also the complexity of the implementation is not trivial.
If bobs phone is 10 meters higher than alex's phone, and they're in a 2 floor building, bob must be on the top floor and alex on the bottom.
This principle can be used at scale by people like apple and google.
maybe that was just a particularly good sensor...
Edit: Sorry about the terseness. I decided about half-way through to write a top-level comment that delved more deeply.
In short, our solution is this: http://qalocate.bamsaas.com/wp-content/uploads/2018/12/QA-Lo...
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.
Indeed maidenhead seems to be the strongest of the previous approaches, they rejected it because it can include words.
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?
example: http://k7fry.com/grid/?qth=JN17EB67UN
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.
At 6 length, you're already down to the kilometer precision at the equator. At 9 length you're down to 4 meters.
And that's with a dumb grid division, which is very uneven on the globe, the cube projection is probably a better way to deal with it.
Here's the alphabet they chose:
// The character set used to encode the values.
var CODE_ALPHABET_ = '23456789CFGHJMPQRVWX';
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".
[1]: https://github.com/google/open-location-code/blob/master/doc...
One of the design decisions was to avoid ambiguous characters, so that cuts out at least 9 (I1L 0OB8).
It is almost impossible to make words out of the allowed characters
The XKCD on competing standards comes to mind…
https://news.ycombinator.com/item?id=8614198
https://news.ycombinator.com/item?id=17423251
"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.
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.
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.
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?
They keep getting things wrong for my location, but things like that (= simple and integrated with maps) would make it easy.
One neat application is for biologists recording locations of field samples.
But kudos to Google for doing this.
It's supposed to be a square, not a point.
Our platform: http://qalocate.bamsaas.com/wp-content/uploads/2018/12/QA-Lo...
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?
That's what LNS (http://qalocate.bamsaas.com/wp-content/uploads/2018/12/QA-Lo...) is. It works very similarly to DNS and allows one to link arbitrary names to exact coordinate locations, structures, or even regions.
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.
PM me if you have any questions.