Hacker News Reader

Comment by arghwhat | Hacker News Reader

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.

View on HN

> 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.

> Yes, a concept that is very human-friendly.

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.

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 :-(

Why not? Every letter could be a check digit. The drawback is that the same location will have many possible location codes, of course.

no, having check digits means that some code corresponds to no location and are syntactically wrong.

I realize now I meant some kind of error correcting code, combination. Like this:

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.

A much less expensive and much more normal solution would simply be to put a single CRC digit at the end.

Systems such as what you describe are too complex and non-standard.

But then you can not truncate the location.

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.

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.

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.

Honolulu is a city, not an island. It is more than enough information to select a rectangle roughly 40km on a side.

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...

UX, yo.

Reply on news.ycombinator.com