I find them a lot more human-friendly, but I guess that's subjective. The example from the wiki page you linked:
MGRS: 4QFJ12345678
Plus Code: 835M+Q7 Honolulu
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.
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.
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.
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.
If Google want people to use this system, they need to give a choice of reference points.
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.