Open Location Code: An Open Source Standard for Addresses
github.com
github.com
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.
https://github.com/google/open-location-code/wiki/Evaluation...
V75V+8Q Paris, France
We display the plus codes in Google Maps on all business listings.
We don't display it on political features or boundaries (typically because having a lat/lng for "France" isn't super useful).
That particular Eiffel Tower result is for the area, not the tower itself, so it doesn't get a plus code.
The entry specifically for the tower, https://g.page/toureiffelofficielle?share, should display the plus code on it.
If you're on mobile, you can get the plus code for any location by just holding your finger on the map, and then expanding the card that appears. It should include the lat/lng and plus code.
Hope that helps!
picking a smaller location displays the plus code, for example https://imgur.com/0YoSuWz
[0] https://www.theverge.com/2019/8/1/20749831/alphabet-google-a...
QJQ3+V3 SoMa, San Francisco, CA
- Latitude/Longitude have been around for a long time, established, proven reasonably reliable.
- Ultimate more calculable, no need for lookup/conversion
- No language issues (three words seem to be primarily English) also unless it becomes an international standard whats to stop someone making a similar service with different words...
- Latitude/Longitude could be added to map legends (even with decimals, it still is quite understandable)
- Letter codes can be more confusing then a general numeric coordinate, get one letter wrong and you are off the map and not sure which letter is the one.
I use Lat/Lon in my apps and can't see how these would make things more efficient or as independent on external resources. They all seem much more arbitrary. (edited for formatting)
In my experience, the problem is that it isn't as exact as you'd think, especially when your measurement passes back and forth between reality, the idealized cartesian lat/long, and node/distance understandings of road networks. At a previous company, our map provider moved the entire United States three meters to the west and we spent the next week re-adjusting endpoints that were suddenly in medians, on overpasses, etc.
tl;dr: Nothing's easy.
Ive realized we can't ever get exact - best we can hope for is finding something that's constant enough for a long period. So far lat/lon has done best.
Worse, the offset was right there in black-and-white in the release notes that we failed to read.
By the way, I apologize for being flippant about it. Location is just one of those things -- like time -- that too many people think is simple, but actually has devilish details that bite the unwary. You are fortunate that lat/long is sufficient and I hope you remain wary.
For example, you could specify the latitude/longitude be interpreted as geodetic coordinates relative to the WGS84 ellispoid, neither of which will always be true when working with unspecified polar coordinates.
To get directions working right. I think there needs to be a good open standard for road/pedestrian maps, but that will only be as good/reliable as the data source... Haven't looked into open street maps but I think that would be one to check out.
1) Opensource and free
2) Can be used offline
3) Designed to be used in low tech environments and decoded by hand
4) Multilanguage
5) Error correction incorporated with visual avatar.
6) Short code for storing or linking.
7) Works with any map.
8) Yow know is an address when you see it.
-----------------------------------------
Here is a comparision side by side of each option
For GPS : -6.7184 , 129.5080
XADDRESS: 7150 Magical Pearl - Maluku, Indonesia
WHAT3WORDS: percolator.surmount.retooled
GEOHASH: qyu1g0by7
MAPCODE: VQ6.1MFD
OPENLOCATIONCODE: 6Q5F 7GJ5+J6
-----------------------------
Article about it: https://medium.com/hackernoon/an-algorithm-that-can-give-an-...
Github: https://github.com/roberdam/Xaddress
(Disclosure: im the creator of Xaddress.)
It's one of the problems with word lists. At any sufficient length, you'll get an offensive combination.
For actually representing global postal addressing schemes with all warts and historic practices, I know no better standard than UPU S-1. I had a project for (partially) implementing it for a large logistics provider ten years ago. It was one of the few cases where using XML for business data genuinely made sense, as addresses could be represented in a line-oriented format (as you'd write on a postal piece) and at the same time structured info in the address (postcodes, streets, house numbering tokens) could be tagged for extraction, validation, etc. Though to make end-of-line chars significant in XML (which we had to somehow because postcodes are often placed at the begin or end of a line in formal addresses) we had to represent addresses basically as address_line_1, adress_line_2, etc. SGML could've handled this much more elegantly, as not only can it assign meaning to line breaks via short references, it also (theoretically) allows representation of overlapping (concurrent) tagging structures for two or more vocabularies.
It's a Base-20 encoding of lat/long.
I can tell someone "College between Drake and Prospect" and they can picture it in their head. Sure, it requires some level of knowledge of the town, but no level of knowledge of the town is going to make "HW8C+FH" something that someone can picture. They're going to have to plug it into their phone.
I work in real estate, and this doesn't really solve anything for our system either. These codes don't solve our address problems (of which there are many). It doesn't solve parcel identification. Not really sure what it does solve other than shorter lat/long.
From my perspective any solution, like this one, that tries to solve the problem of addresses through the lens of coordinates is doomed to failure. The reason is that there are just too many use cases that raw coordinates cannot supply context for.
For example when I ask for directions to a restaurant, the context of who I am and what my relation to the restaurant is matters quite a lot. A set of coordinates handed out uniformly to all who ask does nothing for my particular use case. Plumbers, health inspectors, and delivery drivers don't use the same entrance, or parking, as ride share or pedestrians.
I think it would be more productive to move to a system that is capable of capturing and relaying these kinds of relations, or at least taking as them as input. Better geo-coordinates miss the forest for the trees.
(3geonames codes are made up of 3 place names and show a semantic likeliness when spatially close - an “anti-feature” of what3words, for example)
The slides for a recent talk at Perlcon 2019 announcing the system are here: https://3geonames.org/riga.html
If you move a house (say, a trailer home) from Nebraska to Oregon, you wouldn't expect the location to stay the same.
OLC encodes position on the globe (basically angles), not points on the crust or other territorial features.
Plus codes are not street addresses.
One of the main use cases for plus codes is to be a street address in places for which street addresses are challenging.
To put it another way - we almost always use co-ordinates to help us find a particular physical object (peak of mountain, end of runway, house on street). Co-ordinates that shift with tectonic movement are most useful for that.
I'd even argue that especially in those catastrophic scenarios, location (as in GPS coordinates) is still more important than addresses that depend on physical features (like a street) that may simply be gone.
First, most plates move a couple of centimeters per year, and the fastest plates (those in Australia) move around 7-10 cm. The default precision plus code is 13x13 meters, so it should take a long time to be wrong.
Secondly, one aim is for this to be an addressing solution in places without street names. If the point doesn't exactly align with the house, if they have a sign, it's still going to be easy to get the right place.
Nice question though!
[edit: move corrected to most]
The word tuples are intentionally structured so they can form a phrase. The exact phrase is left up to the person, with the only constraint being that that phrase use all the base words.
And because of how word choice is made (words that map different parts of the geohash come from disjoint dictionaries) the phrase mapping is invariant under changes in recalled word ordering, word use (noun to verb, or adjective to noun), and more.
Some advantages of the GeohashPhrase:
1) Will be open source and free (Once we finalize the dictionaries and write some real docs.).
2) Designed for offline usage.
3) Designed to be friendly to humans. Phrases and words are MUCH more friendly than alphanumeric digits.
4) Multi-language. The encoding scheme works for most languages.
5) Resilient to errors in human memory, which tends to re-order words, change pluralization, etc.
6) Easy to read, write, share, etc.
7) Directly decodes to a geohash.
8) Works with any map.
-----------------------------------------
Here is a comparison side by side of each option:
Lat/Lon : -6.7184 , 129.5080
GeohashPhrase (Raw): salute tell small student muddy
GeohashPhrase ("Encoded"): The small muddy student told me of a salute.
XADDRESS: 7150 Magical Pearl - Maluku, Indonesia
WHAT3WORDS: percolator.surmount.retooled
GEOHASH: qyu1g0by7
MAPCODE: VQ6.1MFD
OPENLOCATIONCODE: 6Q5F 7GJ5+J6
-----------------------------
(Disclosure: I work for QALocate.)
But in general yes, locations that are "close by" will share the same set of words.
The mapping itself is extremely simple. A geohash is encoded as string of alphanumeric characters where each character is in base-32. This means each character encodes 5-bits of coordinate information. To get to a 5m x 5m region you need 45-bits worth or 9 geohash characters.
To map this 9 character geohash to a phrase is simple - we simply use the binary representation of the characters as a numeric index into a fixed dictionary of words. The first character is mapped to a word in a dictionary containing 32 entries. After that we map characters in pairs to dictionaries of 1024 words; 2 geohash characters being 5-bits we get a 10-bit index.
So two geohashes that share the same prefix will also share the same words, modulo our grouping scheme.
(As far as I know, an address is for "addressing" a person, except by mail rather than by spoken means, which is why it's based on identifying a building and even room in that building)
Try to remember:
6GCRMQPX9G
3FHMRV5JMX
8FJM2QRW78
Or try to remember:
tell.fantasy.animal
zone.house.horses
home.penguin.room
Also what3words have got bad thinks as that similar words are far away from each other and the words location are not properly translated
1. Random but fair distribution of domain names to everyone on Earth, if that becomes a thing.
2. Any kind of unique identifier that should be user memorable.
In principle, armed with just a compass and odometer and knowing your current plus code, you can make your way to a nearby plus code. Similarly, once you get a feel for the distance increment a plus code give you, you can tell how far away a given location is, and in what direction.
But don't confuse glorified.bodily.passage https://map.what3words.com/glorified.bodily.passage with glorifies.bodily.passage https://map.what3words.com/glorifies.bodily.passage, which is in a totally different part of the world.
Try to find the following place on Bing or OpenStreetMap without using Google's services: 9MHR+PW Retkowy, Poland
The 9MHR+PW part is readily decodable, and could denote any of thousands of places around the globe. But the most significant part of the code is routinely omitted by Google, and replaced by a place name that one needs Google Maps to look up.
The question is, do we really need another way to link to Google Maps?
Verified by sending a physical card to the location, adjustable by the owner, query-able via an API. Post-offices can perform a lookup and calculate postage fees in this way.
Voluntary nomads (techies) could subsidize the service for involuntary ones (refugees).
Now, could this be used as an alternative to DNS? have a registrar per tile, and delegate if necessary.
I wish this could be used as a geo: URL, or as a location field in my ical invites. I guess I need better support in various apps for it.
Maybe it lack elevation information to specify meeting rooms, though? Perhaps it could be extended to support both ground and absolute elevation.
Excluding words somewhat makes sense, but also removes some opportunities for artificial attractions, it isn't like some areas don't already have interesting ones [2]). So I am a bit split on this one, as it does generate longer names. Maybe emojis would be a better fit?
Now, a note about standard presentation: I would have preferred a technical overview to an introduction that merely sums up some obvious (to me) facts, without really getting into explaining the standard. Perhaps someone has already come up with a way to publish standards together with a few sliders to control the amount of content displayed? That would be great.
[1]: https://github.com/google/open-location-code/wiki/Evaluation...
[2]: https://www.estately.com/blog/2016/09/the-complete-list-of-l... as an example, it gets worse if you include foreign cities, regardless of the language.
Well, we're building it! I cannot supply much info right now other than the whitepaper at https://www.qalocate.com/resources/ but I'm really hopeful that we'll have a beta out in the next few months.
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.
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.
However: https://plus.codes/8VG3+J4 Says it couldn't find it.
Did I make a typo? There is no mention of a checksum in the doc.
Alternatively, you could use the full plus code: 6PH58VG3+J4
... 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?
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)
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.
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.
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.
The major problem with these as addressing standards, and with open location code, is that most people do not live or receive mail at a fixed location in the middle of the ocean. Most location codes encode an empty quadrilateral of ocean.
Addressing with efficient encoding needs to be dense in cities, and sparse in uninhabited wilderness.
To see why consider how geohashes work. As you add letters you telescope in to a more precise region. The land/water distinction is less information than even what is encoded by the very first character of your 9 or 10 character geohash.
us;il;chi = {41.88206,-87.62781} The Chicago base reference point, positive x-axis points to 0 degrees N, positive y-axis points to 90 degrees east.
us;il;chi;0,0 = Madison and State, street level
us;il;chi;-278,+305 = 111 S. Michigan, street level. This is between the lions of the Art Institute. Horizontal offsets are in meters.
us;il;chi;-278,+305>90:165 = east 165m into the museum, over the bridge, into Greek, Roman, and Byzantine art.
us;il;chi;-278,+305>90:165>180:32,+1 = south 32m into the Modern American Art wing, up the stairs one level, in the top level of the 2-level sculpture court. Vertical offset is in building stories.
us;il;chi;-278,+305>90:165>180:32,+1>270:13 = west 13m into gallery 262, home of Nighthawks.
A geohash can tell you where Nighthawks is, in terms of a geodetic location to a certain precision, but it doesn't tell you that it's on the second floor of a building whose second floors don't all connect, or how to get there to see it. If doesn't matter how many extra characters of precision you add when the place you want to be is separated from the locations of the public access points. Addressing sometimes has to include routing information. Complexity is sometimes needed.
The base reference point for Manhattan (us;ny;nyc) could have its reference grid rotated to 29 degrees NNE, but cities without a grid system needn't bother.
Check out UBID (https://ubid.pnnl.gov/) which uses plus.codes
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.
+XX "house" (13x13 meters) +XXX "bathroom" (3.5x2.8 meters) +XXXX "chair" (87x56cm) +XXXXX "envelope" (22x11cm)
In Kolkata the NGO (Addressing the Unaddressed) are using +XXXX codes.
[1] "GPS-enabled smartphones are typically accurate to within a 4.9 m (16 ft.) radius under open sky" -- https://www.gps.gov/systems/gps/performance/accuracy/
Looking up the charity mentioned, they even have a nice photo of such a sign, so my guess appears validated: https://www.addressingtheunaddressed.org/services
Neat.