Evaluation of Location Encoding Systems (2021) | Hacker News Reader

Evaluation of Location Encoding Systems (2021)

github.com

32 pointstosh14 comments

The "Open Location Code" is often mentioned on Hacker News, but is sadly neither open, nor a location code.

To pick one example, if you go to 0°06'40.6"S 28°56'27.0"E (-0.111271, 28.940829) in Google Maps, it'll give the Open Location Code "VWQR+F8W Maipi, Democratic Republic of the Congo", or some variation thereof, depending on your local language.

The most significant bytes, "Maipi, Democratic Republic of the Congo", are obviously not a location code, but a place name, and thus cannot be decoded at all.

Moreover, if you go to OpenStreetMap and look up "Maipi", it returns three places in Indonesia, and none in DR Congo. So even using a location service plus the algorithm could land you on the wrong continent.

The "Open Location Code" is essentially only usable as a search key for Google Maps. "Go look it up on Google" isn't a location code, it's advertising.

> The Open Location Code characters exclude easily confused character pairs. There is a risk that "VV" will be confused for "W" in handwritten messages but we consider this to be unlikely, since that would change the length of a code and this should be detected by the user or recipient.

Never assume users will "detect" some tiny detail.

Overall their spec sounds like some googler spent some time writing a DSL on top of lat/long and they are a victim of sunk cost fallacy, so they had to put an API in front of it.

Yeah, that seems like a bad design choice. If you look at the spec [0], you can see that they only use "23456789CFGHJMPQRVWX" in the codes. They apparently scored the letters based on how well they can spell 10000 words in 30 languages, without thinking about character similarity. If they had involved actual humans instead of counting letter frequency, they might have noticed that the letter W looks similar to VV, and that its English name is "double U". And tried a letter like N or Y, which would be much harder to confuse.

[0] https://github.com/google/open-location-code/blob/main/docs/...

I thought I would share our solution for encoding nearby locations, and subscribing to changes taking place within a certain radius:

https://github.com/Qbix/Platform/blob/master/platform/plugin...

It isn't as easy as you think ... we wound up covering a circle with four quantized lat/long squares, and then anything that is posted to one of those four streams gets additionally vetted by radius ("as the crow flies") from the center point.

Specifically, note the comments here: https://github.com/Qbix/Platform/blob/master/platform/plugin...

I think the reason that what3words has taken off while (almost objectively) better systems are mostly unused is that it’s just more fun, which makes it innately viral. Looking up your house and finding it’s called crazy.wooden.marmot is something you’re likely to share and remember. Plus codes don’t have the same appeal.

Also, the vast majority of people really don’t care that it’s proprietary, sadly.

GEOHASH is way better!

For people?

Agreed, but also having a boat load of VC cash to invest in a massive marketing campaign helped.

It's just a shame W3W couldn't have been an industry consortium, or open standard. Due to EU/UK database laws it's illegal to have an open source implementation with the same words. W3W are the sole gatekeeper of the system, it's almost worse than UK postcodes being owned by (the publicly traded company) Royal Mail.

Interesting connection... one of the what3words founders is a question editor on the UK game show Only Connect.

I think the key is it does a great job at the human-to-human aspect, which I lot of location encodings fail at. It's a good demonstration of 7 ± 2 [1] in practice.

In many cases when communicating this style of location, at least one person in that exchange is likely under some form of stress (lost, navigating an unfamiliar area, in need of help, etc). These locations encodings are a compression mechanism and the absolute goal should be to minimise the encode/decode complexity for the people tasked with that.

[1]: https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus...

This evaluation is hardly unbiased, it's promoting the conclusion that Google's Open Location Code is the way to go (as you might have guessed from the fact that it is in the google/open-location-code repo). Some of the points about others are incorrect or outdated.

I think lat,long is the way to go