Open Location Code: Easier location encoding | Hacker News Reader

Open Location Code: Easier location encoding

openlocationcode.com

52 pointsyarapavan33 comments

Makes me think of what3words.com

edit: why they're taking a novel approach: https://github.com/google/open-location-code/wiki/Evaluation...

The big advantage over w3w is that this is open. Proprietary addressing systems are a bad thing for fairly obvious reasons.

The other advantage of this over w3w is that it the encoding makes any kind of sense.

w3w's feature where it moves an address onto a different continent because you forgot to pluralize a word is the worst idea for an address encoding.

It was actually by design, so you know you have the wrong place. We already have systems like postcodes where small changes result in small geographic offsets and they have major downsides too.

Geocoding seems really simple until you have to build one and have customers use it.

Geocoding is probably simpler if its users aren't "customers".

Lots of systems have checksums. It appears to me that what3words's complexity is designed to make it intentionally difficult for someone else to reimplement.

And the big problem with open systems is that there are so many of them and nobody will pay to market and implement any of them to make one a standard.

Additional info:

[1] https://plus.codes/developers - Plus codes are based on Open Location Code (OLC, for short), an open-source project initiated by a group of Google engineers.

[2] https://github.com/google/open-location-code/blob/master/doc... - Definition document - Open Location Code: An Open Source Standard for Addresses, Independent of Building Numbers And Street Names

[3] https://github.com/google/open-location-code - Github repo

[4] https://plus.codes/howitworks - How it works

  Making a mistake with a code may simply display
  somewhere else - for example, on What3Words,
  "banana rabbit monkey" is a location in Argentina,
  "banana monkey rabbit" is in Russia.

Yes, and the open location code 6GCRPR6C+24 is in Nirobi, while 9GCRPR6C+24 is in Russia. Similar when I make a mistake in a UK postcode (N6 = London, M6 = Manchester)

So the real problem, then, is not the coding system, but rather that humans are involved at all.

A checksum would help and give immediate feedback that the code was entered wrong.

>> for example, on What3Words, "banana rabbit monkey" is a location in Argentina, "banana monkey rabbit" is in Russia.

> Yes, and the open location code 6GCRPR6C+24 is in Nirobi, while 9GCRPR6C+24 is in Russia.

Clearly, the real problem here is Russia typosquatting all our location codes.

Oh, it's like the Grid Square system that Ham Radio operators use: https://en.wikipedia.org/wiki/Maidenhead_Locator_System Just with a greater precision since it seems to go down to a very localized area, such as a building.

After reading their evaluation document, I kinda see the use case. I personally find the mix of letters and numbers a little annoying though.

I think it would be better to use only letters for the first 8 symbols (perhaps after getting rid of some particularly confusing ones like "I"), and only numbers for the rest.

This way you don't need the plus, can use all 10 digits without a chance to confuse them with a letter, remove more potential letter-digit mixups such as 6/G or 7/F in some handwritings, and most importantly make the whole thing a lot easier to say (e.g. over the phone), write (on a phone keyboard you would need only one switch between numeric and alpha layouts, you do want this to be easily texted!), and remember (it's easier to remember a sequence of just letters followed by a sequence of just numbers, imo, even if it's one or two characters longer)

In many parts of the world they use different alphabets - Cyrillic, Arabic, etc

True, and definitely an argument to consider full numeric. I am sure they've thought about that already and decided against though, so I didn't want to go that far.

Also, in practice today there are not many people anywhere in the world who are not at least somewhat familiar with the Latin alphabet to the point they wouldn't be able to recognize/read/write the letters, and (possibly excepting a few old typewriters here and there) people would generally be able to enter letters of standard Latin alphabet into whatever devices they are dealing with.

Is there an advantage over the already established Maidenhead Locator system? [1] Form a first look it seems very similar.

[1] https://en.wikipedia.org/wiki/Maidenhead_Locator_System

According to their evaluation [1]:

"Maidenhead Locator System codes explicitly represent areas, and can be truncated in a similar way to Open Location Codes. The accuracy and length of the codes is similar, but Maidenhead Locator System codes include vowels and so the generated codes include words"

"Maidenhead Locator System codes are based on an interleaving of latitude and longitude, and so are truncatable, and nearby locations have similar codes. It is only formally defined to a length of 8 characters."

This suggests (when compared with their 'desired attributes' [2]) that their innovation over it is increased precision, and a different symbol alphabet to reduce profanity.

[1] https://github.com/google/open-location-code/wiki/Evaluation... [2] https://github.com/google/open-location-code/wiki/Evaluation...

How did you conclude from "The accuracy and length of the codes is similar" that it has increased precision?

Off-topic, but does anyone know how this website was created? It seems too much of a coincidence that it looks nearly identical to https://www.passwordstore.org/.

GitHub Pages Slate theme

https://pages-themes.github.io/slate/

Thanks!

> Each place has only one code.

This doesn't really seem to be true in practice. For a reasonably large building, it seems like I could end up with two codes which for all practical purposes, are equivalent.

"place" is very ambiguous. technically, a place might include several "regions". at the same time, a big building can have several entries, which can be referenced with different codes. and still, codes can vary in length and hence, resolution.

but I agree that the sentence itself is a bit confusing and very not technically meaningful or informative.

I think the point they're trying to convey is that no two codes resolve to overlapping rectangles.

In my town there are two zip codes, but both of these are handled by the same post office, so it doesn't really matter which one you use. This can cause confusion though. Ensuring that multiple codes don't resolve to the same place (i.e. rectangle) means that there isn't this confusion.

I am trying to wrap my head around efficient aggregation of these "places" into a more meaningful shape such as a building footprint. This seems better for this use case than what3words in that it is hierarchical and could help with blocking out large spaces.

latitude,longitude up to the 5th decimal point is easier to remember. and more intuitive.

lat,lon doesn't have any precision attached to it. Also, you might be surprised how many times people get them reversed. Hey, even geojson encodes it as lon,lat.

Also easily normalizing (lat,lon)s isn't so straight forward.

And then there's subtleties when people are actually not using the WGS84 but a crs/datum one shifted a few tens of miles.

Sort of surprised that nobody compares this to geohash[0], though.

I hope that Google will be throwing its weight behind it (seems so for now) and proposes a rfc for this so we can stop bikeshedding about geo encoding standards.

[0] https://en.wikipedia.org/wiki/Geohash

I agree with the bike shedding comment! It seems to me that the location format is the most trivial part of an addressing infrastructure. Any system could easily be successful, but it needs a level of infrastructure and support to work which is not trivial. My guess is that the eventual solution will be for apps to use GPS and camera to identify delivery points in places that lack good addresss infrastructure.

Geohash is a great idea, but at the end of the day all these systems are a mapping to latitude,longitude. The lat,lon precision can be derived from the number of digits after the decimal point. The main argument for the existence of these systems is that lat,lon is hard to remember. Here is a simple solution, convert any lat,lon pair to an easier to remember pair (ie a pair where numbers are repetitive, consecutive, etc).

for eg: 45.89988,-64.36288 -> 45.9,-64.363

and so on. It is a simple hack making ll memorable without sacrificing much accuracy.

https://geocode.xyz/45.89988,-64.36288

Good, now we just have one more format in addition to all the existing ones. (I'm too lazy to look up the xkcd link).

https://xkcd.com/927/

You probably mean the one about the 14 standards https://xkcd.com/927/ but there's one even more relevant about creating a geohashing algorithm https://www.xkcd.com/426/ Truly there's one for every nerdy occasion.

Those location codes look more like (difficult to remember) passwords to me.

Perhaps this xkcd is more relevant: https://xkcd.com/936/

Reply on news.ycombinator.com