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.
I don't know about that specific listing from your link, but I dropped a pin right on l'avenue Gustave-Eiffel behind the tower and got the code V75W+43 Paris, France. Plus codes appear right under the address line.
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.
The eiffel tower search result is the whole park, which is larger than the area spanned by a single plus code and therefore does not display it's plus code.
I just got more and more frustrated reading the README because I kept thinking this has already been done brilliantly and in multiple languages. It’s called What3Words.
what3words has appeared twice recently as a news story on bbc.co.uk
I'd not heard of plus.codes even though now I realise I'd seen them on google maps listings
The most recent article [1] read like an advertisement. They even quoted someone as saying "I just cannot see a downside". It's a shame they didn't find time to mention any of the many criticisms of it, most of which are listed on Wikipedia!
Seems like reinventing a solid wheel with a disposable one...
I'm more for Latitude and Longitude:
- 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)
You need to specify latitude/longitude as a specific relationship relative to a specific reference surface. Polar coordinates alone are insufficient for consistent addressing.
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.
I agree, however this and latitude longitude don't fully solve the problem the post discusses. Just because you know where the entrance is, it doesn't describe how to get there. Maybe the area isn't available on mapping services (not that uncommon for small communities, even in Western countries) or maybe you need to take a specific route to get there.
I was thinking that it would be cool to have some AR thing going (ala Pokemon Go - virtual arrow pointing toward the destination) But of course that fails if there is no direct route from where the traveler is.
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.
You are fortunate that lat/long is sufficient for your use-case.
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.
Yeah had that happen on google maps API a few years back where the earth adjusted southeast or something like that... I wonder if the offset you experienced was able to be re-adjusted by calculation or was the new geometry inconsistent?
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.
In retrospect I also wonder why we didn't just do a bulk update. I think the problem was that we discovered the geocoding problem and started correcting for it before we understood where the problem was actually coming from. By the time we discovered it was a simple constant offset, we'd already damaged our own data with the one-off fixes.
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.
hoover your mouse on any of the words and it tell you how many aditional words are available, click on any of the words to change it for other more suitable if you don't like the default.
Skimming through the docs, even though warts of postal addressing are mentioned, this seems like a (base-14?) encoding of geocodes rather than unified hierarchical postal addressing (which is still an accomplishment, and something I can see a need for). Though this seems to work for latin scripts only I guess.
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.
I think a more accurate description is "Open Source Lat/Long Alternative". Addresses, at least in my part of the world, work relatively well for telling a person where you are, given some knowledge of the town.
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.
Unfortunately we're conflated addresses with coordinates, but fundamentally addresses are not geo-coordinates. Addresses are really just an ancient (500+ years!) short-hand for giving a person a set of rough directions to a "place", with the person supplying that last mile of figuring from context exactly where they are going. It is impressive how far we've taken this technology, but it is really starting to falter as the information age has matured.
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.
Just wanted to express thanks for this very insightful comment. The range of solutions visible in other posts must be ridiculously amusing (being absolute, global, western-centric, experience and culture-denying, and having properties irrelevant to local inhabitants) to anthropologists.
Btw, I just extended 3geonames.org - another open location code system - to support elevation, something no other system does. (eg. https://3geonames.org/RIGA-FRIDAY-OKEG )
(3geonames codes are made up of 3 place names and show a semantic likeliness when spatially close - an “anti-feature” of what3words, for example)
So this is based on GPS, right? How does this system deal with tectonic plate shift? A house may move by a couple meters over years, which will exceed the accuracy of the 12 digit code. At the very least the code should include a timestamp (year is probably precise enough).
Hi, plus codes founder here. We did think about this but we think there are two things that reduce the impact of this kind of movement.
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.
In a previous discussion about the topic it was mentioned that an earthquake can move a road a few meters to a side. Tectonic shift might be less important but physical relocation could be. A road could be moved du to a large urban work in the area for example.
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.
When an earthquake has shifted a house a meter to the right, the plus code is (a) still good enough and (b) doesn't matter because there is not much of a house left to "locate".
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.
Yet another alternative is GeohashPhrase (https://www.qalocate.com/resources/) which is a simple and direct mapping of word tuples to geohashes.
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.
A five word phrase is roughly a 5m x 5m region, so 1m wouldn't be enough to move into the next block.
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.
When does a location become an address? Because as far as I can tell, this is a geolocation scheme, not an address system.
(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)
I agree that what3words is easier to remember. The disadvantage is that close by places don't have similar address codes.
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.
There is one significant problem with how Open Location Codes are being used and promoted by Google.
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?
Neat, but what I really want is a dynamic abstraction layer above this, similar to DNS. I'd like a unique code that translates to a physical address (or a system like this, or both), but is adjustable by me.
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).
A good explanation of this against competing standards seems to be available here [1]. It seems weird that they complain about discontinuities in such a system, where there has to be some discontinuities in a tiled system.
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.
Alternative to DNS you say? Like a Location Name System!?!
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.
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.
It's not just latin countries. In Germany, and most east-European countries and Russia as well I believe, newly build roads get generic names (named after flowers, for example), then later get renamed after persons, though not living ones, which helps with politicians promoting their names I guess.
If you enter the address in to google maps it will give you the eircode. The issue in Ireland is the non unique addresses in rural areas. The fact that the last 4 characters are randomly distributed means that a sequence for addresses on the same street is not something you can derive. You need to look up each in turn.
Ireland's non unique addresses aren't a problem for any of the open standards around this I've seen. Eircode is unnecessary. Using one of these geo location centric systems also means no central system is required to add new ones etc.
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.)
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)
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.
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.
you can vary precision in a "degree encoding" scheme as well just truncating rightmost bits, that's precisely why I referenced using fixed point and not floating. it also makes extra convenient to transform them into base32 and maintain some of the property that the scheme has (small changes in coordinate result in small changes in the encoded sequence etc)
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.
Doing this saves you about two bits worth of information while usually greatly increasing complexity.
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.
If one could maintain an index of a single reference point for human settlements, as geodetic latitude and longitude, addresses could relatively reference from a specific center, and include relative waypoints.
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.
Was actually looking into something like this to help with matching companies addresses to building addresses to track the number of tenants in each building.
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.
On my Android I copy&paste this short locations code from Google Maps to OSMAnd+ to get the same location. Works faster and better than confusing long and lat (which I don't know how to copy out of Google Maps btw).
Bummer, I was hoping we were going to all memorize quaternion coordinates and visualize travelling around the globe as moving along a 4 dimensional hypersphere.
The docs also seem to indicate that 3mx3m is the smallest grid they can address, but at the same they use addressing in slums as a use case...who has that much real estate in the slums?
Wait a minute. How are Kolkatans with (probably) cheap phones getting their hands on coordinates that accurate when phone GPS is usually only good to within ~5m?[1] I assume the postal workers are getting high end equipment?
First guess: Signs, maybe? You only need a few accurate surveyors and they could write coordinates in places. Use the cheap accuracy to get close then follow the signs.
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.
Where do I find them in Google maps? what is the plus.code for the Eiffel tower? https://www.google.com/maps/place/Eiffel+Tower,+Paris,+Franc...
https://www.google.com/maps/place/Eiffel+Tower/@48.853909,2....
V75V+8Q Paris, France
I don't know about that specific listing from your link, but I dropped a pin right on l'avenue Gustave-Eiffel behind the tower and got the code V75W+43 Paris, France. Plus codes appear right under the address line.
Thanks. It seems you have to specify a pin, and not an area to get a plus code.
Hi - plus codes founder here.
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!
The eiffel tower search result is the whole park, which is larger than the area spanned by a single plus code and therefore does not display it's plus code.
picking a smaller location displays the plus code, for example https://imgur.com/0YoSuWz
As usual there is a relevant XKCD. This time it is https://xkcd.com/927/
That xkcd is very common around here I noticed. We often get brilliant ideas that someone else already had.
Some of which are mentioned here:
https://github.com/google/open-location-code/wiki/Evaluation...
Also, much older systems: QRA Locator and Maidenhead Locator System.
There's also this: https://en.wikipedia.org/wiki/Military_Grid_Reference_System
I just got more and more frustrated reading the README because I kept thinking this has already been done brilliantly and in multiple languages. It’s called What3Words.
No. W3w is not open and not brilliant precisely because it exists in multiple languages.
I wish Google to put a tiny bit of their money [0] into promoting this more. To counter the closed-source, for-profit what3words offering.
[0] https://www.theverge.com/2019/8/1/20749831/alphabet-google-a...
what3words has appeared twice recently as a news story on bbc.co.uk I'd not heard of plus.codes even though now I realise I'd seen them on google maps listings
The most recent article [1] read like an advertisement. They even quoted someone as saying "I just cannot see a downside". It's a shame they didn't find time to mention any of the many criticisms of it, most of which are listed on Wikipedia!
[1]: https://www.bbc.co.uk/news/uk-england-49319760
BBC regional news will often promote British businesses. It's part of their remit.
Google maps shows "Plus Codes" (same thing) in it's UI. eg Salesforce Tower shows plus code of
QJQ3+V3 SoMa, San Francisco, CA
Seems like reinventing a solid wheel with a disposable one... I'm more for Latitude and Longitude:
- 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)
You need to specify latitude/longitude as a specific relationship relative to a specific reference surface. Polar coordinates alone are insufficient for consistent addressing.
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.
I agree, however this and latitude longitude don't fully solve the problem the post discusses. Just because you know where the entrance is, it doesn't describe how to get there. Maybe the area isn't available on mapping services (not that uncommon for small communities, even in Western countries) or maybe you need to take a specific route to get there.
I was thinking that it would be cool to have some AR thing going (ala Pokemon Go - virtual arrow pointing toward the destination) But of course that fails if there is no direct route from where the traveler is.
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.
You are fortunate that lat/long is sufficient for your use-case.
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.
Yeah had that happen on google maps API a few years back where the earth adjusted southeast or something like that... I wonder if the offset you experienced was able to be re-adjusted by calculation or was the new geometry inconsistent?
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.
In retrospect I also wonder why we didn't just do a bulk update. I think the problem was that we discovered the geocoding problem and started correcting for it before we understood where the problem was actually coming from. By the time we discovered it was a simple constant offset, we'd already damaged our own data with the one-off fixes.
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.
There is https://xaddress.org
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.)
My office has the suffix "AFRAID SPEAK" - I'm not sure my bosses would like that!
It's one of the problems with word lists. At any sufficient length, you'll get an offensive combination.
hoover your mouse on any of the words and it tell you how many aditional words are available, click on any of the words to change it for other more suitable if you don't like the default.
Skimming through the docs, even though warts of postal addressing are mentioned, this seems like a (base-14?) encoding of geocodes rather than unified hierarchical postal addressing (which is still an accomplishment, and something I can see a need for). Though this seems to work for latin scripts only I guess.
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.
> this seems like a (base-14?) encoding of geocodes
It's a Base-20 encoding of lat/long.
I think a more accurate description is "Open Source Lat/Long Alternative". Addresses, at least in my part of the world, work relatively well for telling a person where you are, given some knowledge of the town.
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.
Unfortunately we're conflated addresses with coordinates, but fundamentally addresses are not geo-coordinates. Addresses are really just an ancient (500+ years!) short-hand for giving a person a set of rough directions to a "place", with the person supplying that last mile of figuring from context exactly where they are going. It is impressive how far we've taken this technology, but it is really starting to falter as the information age has matured.
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.
Just wanted to express thanks for this very insightful comment. The range of solutions visible in other posts must be ridiculously amusing (being absolute, global, western-centric, experience and culture-denying, and having properties irrelevant to local inhabitants) to anthropologists.
Btw, I just extended 3geonames.org - another open location code system - to support elevation, something no other system does. (eg. https://3geonames.org/RIGA-FRIDAY-OKEG )
(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
So this is based on GPS, right? How does this system deal with tectonic plate shift? A house may move by a couple meters over years, which will exceed the accuracy of the 12 digit code. At the very least the code should include a timestamp (year is probably precise enough).
Hi, plus codes founder here. We did think about this but we think there are two things that reduce the impact of this kind of movement.
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]
Why should it handle that?
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.
In a previous discussion about the topic it was mentioned that an earthquake can move a road a few meters to a side. Tectonic shift might be less important but physical relocation could be. A road could be moved du to a large urban work in the area for example.
I know that. But why do you insist that a location code stays the same? The location has really changed.
Plus codes are not street addresses.
> 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.
When an earthquake has shifted a house a meter to the right, the plus code is (a) still good enough and (b) doesn't matter because there is not much of a house left to "locate".
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.
Yet another alternative is GeohashPhrase (https://www.qalocate.com/resources/) which is a simple and direct mapping of word tuples to geohashes.
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.)
Will two close-by locations eg. just a meter apart have any part of the phrase in common?
A five word phrase is roughly a 5m x 5m region, so 1m wouldn't be enough to move into the next block.
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.
When does a location become an address? Because as far as I can tell, this is a geolocation scheme, not an address system.
(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)
From my point of view, this approach is harder to remember than remembering 3 words (what3words).
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
Also I will never forget glorified.bodily.passage and pigs.pigs.pigs: https://news.ycombinator.com/item?id=11896883
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.
I agree that what3words is easier to remember. The disadvantage is that close by places don't have similar address codes.
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.
what3words is a much nicer system. It's actually such a simple system that I could think of a few other things to apply it to:
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.
Project website: https://plus.codes
This reminds me of the Japanese Chome system: https://en.wikipedia.org/wiki/Japanese_addressing_system.
There is one significant problem with how Open Location Codes are being used and promoted by Google.
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?
Neat, but what I really want is a dynamic abstraction layer above this, similar to DNS. I'd like a unique code that translates to a physical address (or a system like this, or both), but is adjustable by me.
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).
A good explanation of this against competing standards seems to be available here [1]. It seems weird that they complain about discontinuities in such a system, where there has to be some discontinuities in a tiled system.
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.
Alternative to DNS you say? Like a Location Name System!?!
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.
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.
It's not just latin countries. In Germany, and most east-European countries and Russia as well I believe, newly build roads get generic names (named after flowers, for example), then later get renamed after persons, though not living ones, which helps with politicians promoting their names I guess.
Of all the possible examples where purely alphanumeric addresses would be awkward to use you chose New York?
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.
If you enter the address in to google maps it will give you the eircode. The issue in Ireland is the non unique addresses in rural areas. The fact that the last 4 characters are randomly distributed means that a sequence for addresses on the same street is not something you can derive. You need to look up each in turn.
Ireland's non unique addresses aren't a problem for any of the open standards around this I've seen. Eircode is unnecessary. Using one of these geo location centric systems also means no central system is required to add new ones etc.
Ah https://plus.codes/ .. I've noticed them on Google maps: https://s.natalian.org/2019-08-20/yard.jpeg
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.
In that case you need to include Singapore. The inclusion of Singapore allows the plus code itself to be shorter.
Alternatively, you could use the full plus code: 6PH58VG3+J4
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?
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)
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.
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.
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.
you can vary precision in a "degree encoding" scheme as well just truncating rightmost bits, that's precisely why I referenced using fixed point and not floating. it also makes extra convenient to transform them into base32 and maintain some of the property that the scheme has (small changes in coordinate result in small changes in the encoded sequence etc)
There are so many established and commonly used grids, such as MGRS (military) or Maidenhead (amateur radio), this just makes things more complicated.
Reinventing UTM/MGRS again, I see.
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.
Doing this saves you about two bits worth of information while usually greatly increasing complexity.
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.
If one could maintain an index of a single reference point for human settlements, as geodetic latitude and longitude, addresses could relatively reference from a specific center, and include relative waypoints.
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.
Honestly, I want an address that follows me as I move, so I don't need to keep updating every service that sends me mail.
Was actually looking into something like this to help with matching companies addresses to building addresses to track the number of tenants in each building.
Check out UBID (https://ubid.pnnl.gov/) which uses plus.codes
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.
Missed that, thanks for pointing it out.
On my Android I copy&paste this short locations code from Google Maps to OSMAnd+ to get the same location. Works faster and better than confusing long and lat (which I don't know how to copy out of Google Maps btw).
No one has mentioned H3: Uber’s Hexagonal Hierarchical Spatial Index.
https://eng.uber.com/h3/
Bummer, I was hoping we were going to all memorize quaternion coordinates and visualize travelling around the globe as moving along a 4 dimensional hypersphere.
Oh, these Google Map codes -- the geographic equivalent of Internet Time. Pass.
I think triangles would have made more sense.
The docs also seem to indicate that 3mx3m is the smallest grid they can address, but at the same they use addressing in slums as a use case...who has that much real estate in the slums?
Hi - plus codes founder here. You can just keep adding digits and the area gets smaller. The way I think of it is:
+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.
Wait a minute. How are Kolkatans with (probably) cheap phones getting their hands on coordinates that accurate when phone GPS is usually only good to within ~5m?[1] I assume the postal workers are getting high end equipment?
[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/
First guess: Signs, maybe? You only need a few accurate surveyors and they could write coordinates in places. Use the cheap accuracy to get close then follow the signs.
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.
Thanks for clearing that up!