Why not words ?

[X-Ryl669]

I don't know if you know what3words. They use 3 words to describe any place in the world (like OLC with 10 digits).

I think such system is easier for people to use (since there is some kind of natural error correction going on: word have semantic, a succession of digits and letters does not)

Would it be hard to merge or extend to such system ? Would anyone be interested ?

[zongweil]

Thanks for the question! Check out our wiki page, which goes into our design philosophy and comparisons with different systems. We specifically mentioned what3words in the Web-based services section.

One issue to consider with words is localization. Not all countries speak English, so the semantics wouldn't be helpful there. If you support locale-specific translations of the words, now you have multiple phrases that resolve to the same location, but you wouldn't know without querying them. With plus codes, you are guaranteed that each code is a globally unique point.

Since plus codes and what3words both resolve to latitude/longitude, you could convert from one to the other that way.

[X-Ryl669]

I don't understand why words are bad in your requirements. I think that localizing the location's words is good (as long as their is no ambiguity on the translation, for example: avoid "fly"). The mapping word => some 3 character code could be done in the frontend (although, with only three words each match 3 chars, you can't make a 10 char code).

It seems much easier for a French citizen to use "pain épice citron" than "bread spice lemon" and we both expect to get the same location.

Sure you can convert from one system to the other, but as you said, their algorithm for word allocation is unknown. That'd be much better if it was opened and standardized, but this project can do that.

[zongweil]

Using words (with translated equivalents) doesn't match these desired attributes from that wiki page:

• To prevent confusion, a place should have only one code
• It should be possible to look at two codes and tell if they are close together and even the direction. This will help people find their way and make the codes more usable;
• Shortening a code should represent a larger area that contains the original location. A side effect of this is that nearby codes will have a common prefix;

In essence, we don't want just a mapping from string to location. Plus codes are meant to be a replacement for street addresses where they don't exist. There are additional considerations for addressing requirements:

1. If a post office is sorting through mail and they receive one letter addressed to "pain épice citron" and one addressed to "bread spice lemon", they have no idea they're referring to the same place without doing a lookup.

2. Post offices will try to group mail by their approximate location to each other (e.g. so they can send one truck with all the mail for that area). How close are "bread spice lemon" and "spice lemon bread" to each other? No idea without a lookup. With plus codes, the resolution gets more precise the further right you go in the code. As a result, you know that 87G7MXQ4+M5 and 87G7MXQ4+M6 are close to each other just from looking at the codes. This is similar to how you'd expect 111 StreetName and 112 StreetName to be close to each other, granted they're in the same locality.

[X-Ryl669]

Yet, "pain épice poire" is close to "pain épice citron" (because the first 3 letters are mapped to "pain" and the next 3 letters are mapped to "épice"). You actually need to do a look up with a code to figure out the latitude and longitude, there's no additional workload to use words here for the end user (unless you can convert OLC letters to floating point's digits in your head, but I'd say it's hard)

The idea would then be instead of this process (can be offline):

fromGeopos(Lat,Lon):
compute OLC

toGeopos(OLC):
compute Lat,Lon from OLC

you'd have:

fromGeopos(Lat,Lon,Lang):
compute OLC
split(OLC, 3 chars).map(trichar => wordDict[Lang][trichar]).join(' ');

toGeopos(threeWord):
OLC = split(threeWord, ' ').map(word => worldWordDict[word]).join('');
compute Lat,Lon from OLC

Each client would need to store a common dictionnary for world words and a per-language dictionnary for trigram.

As for the change in language, it's already the case, if you write a letter to Brazil, you'll write "Brazil" at the bottom of the address, and Brazil's post understand Brazilia. In all case, the user can use the same code to get the good position.

[WilliamDenniss]

This project doesn't use a word dictionary lookup, and the wiki discusses several advantages of the system it does use. As you point out, alternatives exist should you wish to use them instead.

The specification of the Plus Code encoding system has already been finalized.

[zongweil]

"pain épice poire" and "pain épice citron" aren't necessarily close (you wouldn't know without a lookup). With only 3 words to represent resolution precision, "pain épice X" and "pain épice Y" could be in completely different countries. Is "pain épice X" closer to "pain épice Y" or "pain épice Z"? Again, you can't know without a lookup.

I can tell you that 87G7MXQ4+M5 and 87G7MXQ4+M6 are really close to each other (~10m apart) just by looking at them (relative location). A post office can group all mail prefixed with 87G7MXQ4 without a lookup because of how plus codes does precision resolution. We can't do the same with only 3 words (and adding more makes it harder to use).

In addition, it would be difficult to determine that three random words are meant to be interpreted as a special mapping instead of a normal address. If you type "bread spice lemon" in Google Maps, how would you know to resolve to a mapped location instead of nearby bakeries? Plus codes solves this problem with a well-defined and identifiable format.

We believe that the design of plus codes makes it well suited to solve the lack of street addressing globally. A word-based system is likely easier to remember for the user (which is good if you're trying to meet up with a friend somewhere), but has the drawbacks discussed when trying to use it for addressing purposes (e.g. a government assigning an address for every citizen in a country).

[RiverMersey]

W3W are trying to be proprietary - they wont release the word-list nor the algorithm. Pluscodes have done both!

[fulldecent]

This issue has raised the questions "Would it be hard to merge or extend to such system ?"

This thread has answered, this is impossible. Details are shown at https://github.com/google/open-location-code/wiki/Evaluation-of-Location-Encoding-Systems#web-based-services

Also the issue raised "Would anyone be interested ?"

The answer here is no. That is out of scope for this project.

---

I recommend that this issue be closed, there is no actionable thing remaining here.