[HN Gopher] Evaluation of Location Encoding Systems (2021)
___________________________________________________________________
Evaluation of Location Encoding Systems (2021)
Author : tosh
Score : 31 points
Date : 2023-03-26 08:09 UTC (14 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| pestatije wrote:
| I think lat,long is the way to go
| freyfogle wrote:
| 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.
| mikequinlan wrote:
| There are several competing standards...
|
| https://xkcd.com/927/
| bspammer wrote:
| 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.
| samwillis wrote:
| 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.
| kimburgess wrote:
| 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...
| EGreg wrote:
| GEOHASH is way better!
| croes wrote:
| For people?
| mkl95 wrote:
| > 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.
| Kwpolska wrote:
| 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/...
| Rounin wrote:
| 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 0deg06'40.6"S 28deg56'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.
| banga wrote:
| See also:
|
| * https://s2geometry.io/
|
| * https://h3geo.org/
| ggeorgovassilis wrote:
| 10 years ago I would have needed this so badly (I ran an
| Indonesian SaaS startup in the real estate business...)
| EGreg wrote:
| 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...
___________________________________________________________________
(page generated 2023-03-26 23:02 UTC)