Live data from Hacker News

Open Location Code: An Open Source Standard for Addresses

github.com

11–20 of 95 posts

Re: Open Location Code: An Open Source Standard for Addresses

#11

there's something I don't understand, not coming from a mapping background: sixth decimal place of latitude/longitude is already down to about 10cm precision, so using two 8:24 fixed point would give you comparable precision with half the encoding length than this format (using two fixed points dword encoded straight in base 32). why these encoding prefer to use space partitioning more than encoded coordinates?

I thought this was comprehensively covered in the linked document. Specifically, it says:

... latitude and longitude provide an exact location, are used internally by GPS and satellite navigation devices, and are sometimes printed on paper maps. However they are rarely seen on city or street maps and are difficult for people to use. They consist of long and complicated numbers, have different ranges (-90 to 90 vs. -180 to 180) and need to be used in a specific order. (To express a reasonably precise position requires between 14 and 18 characters.)

A system of encoding location information into a short and an easy to use code would solve these problems.

It goes on to say:

Easy to use: The codes must be short enough to be remembered and used. This means that they need to be shorter than latitude and longitude and about the same length as a postal code or telephone number. The symbols used to make up the code should not include characters that can be easily confused (e.g., 1 and I, 8 and B, 2 and Z, 5 and S etc.)

Does this not answer your question?

Re: Open Location Code: An Open Source Standard for Addresses

#12
post #3

Some alternatives that I am aware of: https://wikimili.com/en/Natural_Area_Code , https://what3words.com/ , https://geokey.io/ , http://geohash.org/ , https://www.mapcode.com/ . Some of which are proprietary. Edit: plus.codes was this same proposal. Removed from the list.

Some of which are mentioned here:

https://github.com/google/open-location-code/wiki/Evaluation...

Re: Open Location Code: An Open Source Standard for Addresses

#13
post #3

Some alternatives that I am aware of: https://wikimili.com/en/Natural_Area_Code , https://what3words.com/ , https://geokey.io/ , http://geohash.org/ , https://www.mapcode.com/ . Some of which are proprietary. Edit: plus.codes was this same proposal. Removed from the list.

This is why these technologies never get mass adoption; so many solutions duplicating themselves trying to solve the same thing. Fact is, most users would care less about numerous implementation, they need to be educated just one solution which works fine. Personally I find plus.codes from Google user-friendly. They are already integrated in Google Maps which has over 1 billion downloads. They are free and opensource which means they can be used in third-party apps. Why is someone is reinventing the wheel is beyond me.

Re: Open Location Code: An Open Source Standard for Addresses

#14

there's something I don't understand, not coming from a mapping background: sixth decimal place of latitude/longitude is already down to about 10cm precision, so using two 8:24 fixed point would give you comparable precision with half the encoding length than this format (using two fixed points dword encoded straight in base 32). why these encoding prefer to use space partitioning more than encoded coordinates?

I thought this was comprehensively covered in the linked document. Specifically, it says: ... latitude and longitude provide an exact location, are used internally by GPS and satellite navigation devices, and are sometimes printed on paper maps. However they are rarely seen on city or street maps and are difficult for people to use. They consist of long and complicated numbers, have different ranges (-90 to 90 vs. -1…

this doesn't really answer the question, because encoding the latitude/longitude number in base32 fixed point makes them short, readable and memorizable as much as it would encode them in this scheme, and as I said above, would even result in a shorter string at comparable precision.

once they're letter, people wouldn't care if internally are mapped to raw numbers or hierarchical quads, a program would do the conversion back and forth anyway for both systems.

so for example the vatican's cupolone center under a b32 fixed point lat-encoded notation would be KUDRL6677SLE at full precision while it's opencode equivalent would be 15 letters (except for the shortening, which could be done here as well)

Re: Open Location Code: An Open Source Standard for Addresses

#15

Earlier quoted context omitted.

I thought this was comprehensively covered in the linked document. Specifically, it says: ... latitude and longitude provide an exact location, are used internally by GPS and satellite navigation devices, and are sometimes printed on paper maps. However they are rarely seen on city or street maps and are difficult for people to use. They consist of long and complicated numbers, have different ranges (-90 to 90 vs. -1…

this doesn't really answer the question, because encoding the latitude/longitude number in base32 fixed point makes them short, readable and memorizable as much as it would encode them in this scheme, and as I said above, would even result in a shorter string at comparable precision. once they're letter, people wouldn't care if internally are mapped to raw numbers or hierarchical quads, a program would do the convers…

I've just glanced again at the linked document and your comments seem to me to be adequately addressed there, so I'm not sure what you're suggesting/asking.

The characters that are used in Open Location Codes were chosen ... to avoid, as far as possible, Open Location Codes being generated that included recognisable words.

...

Open Location Codes are encodings of WGS84 latitude and longitude coordinates in degrees.

...

The first approach ... provides codes that can be visually compared, or alphabetically ordered to determine if they are close to each other. The second approach allows the code area to be refined using only a single digit. If the entire code was generated using the second approach, it would result in codes that could not be reliably compared visually.

I thought the benefits were explained quite clearly, so I'm at a bit of a loss as to what you're suggesting.

Re: Open Location Code: An Open Source Standard for Addresses

#16
I'll forever be mad that my country (Ireland) hired some firm to create eircode, which is a proprietary geo system.

https://en.wikipedia.org/wiki/Postal_addresses_in_the_Republ...

You can't discern the eircode for a given address, as far as I am aware, without looking it up, and lookups are limited to 10 by paywall.

We paid 27m euro for what has already been solved by open source, and for some reason we have to continue to pay for it.

Re: Open Location Code: An Open Source Standard for Addresses

#17

Earlier quoted context omitted.

I thought this was comprehensively covered in the linked document. Specifically, it says: ... latitude and longitude provide an exact location, are used internally by GPS and satellite navigation devices, and are sometimes printed on paper maps. However they are rarely seen on city or street maps and are difficult for people to use. They consist of long and complicated numbers, have different ranges (-90 to 90 vs. -1…

this doesn't really answer the question, because encoding the latitude/longitude number in base32 fixed point makes them short, readable and memorizable as much as it would encode them in this scheme, and as I said above, would even result in a shorter string at comparable precision. once they're letter, people wouldn't care if internally are mapped to raw numbers or hierarchical quads, a program would do the convers…

I'm not sure why you want fixed point. Some of the reasoning behind them going with base20 is here:

https://github.com/google/open-location-code/blob/master/doc...

* 10 characters can represent a 14x14 meter area suitable for many buildings

* Using a number base of 20 makes some calculations easier

* We could identify a 20 character subset from 0-9A-Z that doesn’t spell words.

Re: Open Location Code: An Open Source Standard for Addresses

#18
In some Latin countries, road names are given after "important" people (for a vague definition of important). On the cultural side, having a standard for naming like this removes that and I think it could be a roadblock for adoption. Politicians' names are specially used for naming roads/squares and they are always after promoting their names in every new opportunity.

On the other side, I really like that the code can be shortened with the addition of a location. One concern I have is that most people are very local, they exchange addresses for local places all the time... so easily speaking those addresses is nice thing. A short code helps with that.

And finally, I may have missed it but I didn't see landmark references mentioned. Could it be that people would have to say "I live at XZY123 in New York. Near that ABC456 building, you know?" That would be awkward.

Re: Open Location Code: An Open Source Standard for Addresses

#19
post #9

These codes could benefit from some sort of distinct prefix so that users, browsers and apps could identify it as an open location code and treat it as such apart from a random string. Other examples being things like @username or #hashtag.

Unclear if you already know this, but the usage of the plus sign and the name "plus codes" for this scheme serve exactly that purpose. If you see a code with a plus in it, with usually 2 characters after the plus, it is most likely a plus code. Speaking from experience it is relateively easy to quickly identify by glancing at a webpage or a body of text.

Additionally the plus serves a similar purpose to a dot in the decimal number notation: the plus is always put after the 8th character in the globally-adressed code. So if you see a code with plus after the 4th character, it is immediately clear that the code is a local-notation, and you need to know approximately what country or city this code is referencing to, in order to properly identify a point on the globe. Usually the locale is pretty clear and 4-6 digit codes are just fine, and the plus character provides a possibility to distinguish them from each other.

Re: Open Location Code: An Open Source Standard for Addresses

#20

Earlier quoted context omitted.

this doesn't really answer the question, because encoding the latitude/longitude number in base32 fixed point makes them short, readable and memorizable as much as it would encode them in this scheme, and as I said above, would even result in a shorter string at comparable precision. once they're letter, people wouldn't care if internally are mapped to raw numbers or hierarchical quads, a program would do the convers…

I've just glanced again at the linked document and your comments seem to me to be adequately addressed there, so I'm not sure what you're suggesting/asking. The characters that are used in Open Location Codes were chosen ... to avoid, as far as possible, Open Location Codes being generated that included recognisable words. ... Open Location Codes are encodings of WGS84 latitude and longitude coordinates in degrees. .…

all encodings are arbitrary, to some degree. this scheme of using hierarchical partitioning gives two shortcoming: degenerate area at poles and variable area at fixed precision. using raw degrees doesn't.

why is the former preferred than the latter by mappers?

it can't be just 'because it's letter and not numbers' because, as demonstrated above, that's just encoding data in memoizable forms, which doesn't depend on the choice of the mapping scheme.

being able to visually compare codes also isn't enough of a differentiator, since nearby places would have nearby encoding even in a raw "latitiude/longitude to base-32" scheme, and if it's important that variation is on the least important digit one could just encode lat:long bits interleaved, so that the least significant bits of each are rightmost.

the question I have is not about the encoding, as shown it's easy to create an encoding with the desired characteristics that uses the degrees by themselves without the partitioning and its issues, the question is why use these area based system with all the deformation they have instead of properly encoded degrees, what's the benefit to cartographers etc.

Post reply on HN