Google maps and 'Find your code' tool create short codes which aren't decodable offline

[tkafka]

I am developing a weather forecasting smartwatch watchface, and I'd love to be able to give my users a way to enter the location manually. I thought of plus codes, thinking that with a support of Google, I could easily direct people on obtaining a code for their desired location.

However, I found out that even though Codes should be able to be generated and decoded offline. is one of reasons Open location codes were created (see Evaluation of Location Encoding Systems), both Google maps and Find your code tool generates codes which aren't decodable offline.

I would like to add a field that would display a full location code to a Find your code tool - and preferrably an option to generate a full code into Google maps.

Alternatively, an offline place database should be added to https://github.com/google/open-location-code decoders, and there should be a documented deterministic way of generating a city from a location, so that a developer can be sure all generated location codes will be decodable with a given offline database.

[zongweil]

Hey @tkafka,

Full plus codes (e.g. 87G7MXQ4+M5) are fully decodable offline. You can already find the full code in the sidepanel here, although Maps does not currently display the full code.

[tkafka]

Hi @zongweil, thanks, I know, but this issue is about the fact that neither Google Maps, or open-location-code own tool doesn't generate the full plus codes. Currently there is no easily linkable way to a tool which would generate them, and currently generated short codes are undecodable without a planetary place database (as I have no idea which places will the Google maps or the tool use as an anchor) or an internet connection.

I consider this a breach of a promised purpose of these codes.

[zongweil]

Did you click my link above? The plus.codes map has the full code in the sidebar.

[bocops]

Alternatively, an offline place database should be added to https://github.com/google/open-location-code decoders, and there should be a documented deterministic way of generating a city from a location, so that a developer can be sure all generated location codes will be decodable with a given offline database.

I'm not sure how feasible an offline database like this would really be, but it would be interesting to discuss this in more detail. Some thoughts and back-of-the-envelope calculations:

1. We most often want to replace the "area code" (first four characters of a full code) with a city or location name, but not all locations within one four-digit code area will sensibly use the same city name.

2. This means we would need a database that assigns names to all individual six-digit code prefixes - or perhaps even some form of data that is not based on OLC itself, but probably just as big. Even on the level of six-digit code prefixes, we're still dealing with a considerable overlap between neighboring entities (for example, 8FR8H400+ is half France and half Swiss).

3. There are around 26 million (9 x 18 x 20⁴) six-digit code prefixes. If we leave out "empty" ocean areas (for example, not much going on in 35000000+) or combine those areas where one name is sufficient for a whole four-digit prefix (for example, it looks as if the whole area of 72W40000+ could be named "Midway Atoll"), we might be able to reduce this number by 50% (assumption based on the relative surface area of the earth that is ocean), but probably not by 90% or more.

4. That means we're dealing with a set of around 3-10 million entries, each of which consists of a plus code prefix and a (globally unique) name, perhaps 20-50 bytes.

5. App developers might be able to ship just part of this database for any app that is "local" - but using the whole database of ~60-500MB in a mobile&offline context is likely not feasible.

[zongweil]

@tkafka did this answer your question?

[tkafka]

@zongweil Thanks for the link to map - it is unfortunately a bit difficult to describe to users how exactly should they get a full code without them accidentally getting a shortcode. It would help if a map could be toggled to a 'full code' mode, eg. with url parameter.

[tkafka]

@bocops Thank you for the estimation - when I wrote this, my assumption was that you don't need to pick the closest city to the location, that just any location inside the four letter area code will do. And I imagine it could be the one with eg. the highest population at the time, to make it deterministic. So we'd have a dictionary of area code -> name of largest place in the area, and that would be at most 36^4 = cca 1.6M places.

Which is imaginable, with leaving out empty areas and some clever compression, but I admit I initially guessed this to comfortably fit 1 MB.

Wait a second - I just mapped a sample 4 letter code: https://plus.codes/8FXQ0000+ and it has area of cca 7700 km2. Earth surface is 510 million km2, and dividing that (even without considering that there is no need to be precise for arctic and antarctic regions) leads to about 66 000 areas - give it about 30 B per entry (might be quite less with name compression and location encoding), and it could fit 2 MB. Which seems completely OK to me in exchange for universally offline-decodable codes.

Yes, we might need an encoding that doesn't waste half of rectangles for north and south pole, but still - this seems doable. What do you think?

[bocops]

@tkafka Your estimate for the number of 4-digit codes isn't too far off. There are 9 and 18 characters used for the first two positions, respectively, and the full range of 20 characters for all subsequent positions. That leads to 9 x 18 x 20 x 20 = 64,800 code areas.

However, one big problem I still see with the approach to just pick the biggest city in each area would be one with a lack of alignment with political structures. For example, look at one of the neighboring areas of the one you gave as an example: https://plus.codes/9F2P0000+

9F2P0000+ has Prague as its biggest city, so we'd use that. However, Prague extends beyond this code area, so a location in the south of Prague would not use Prague in its shortened code, but another city instead. If the biggest city of the code area to the south is České Budějovice, we might end up with a short code referencing this city for a location that is actually in Prague.

Even worse, because České Budějovice is shifted approximately one full 4-digit code area towards the south, trying to recover a full code (or a lat/long coordinate pair), this short code for a location in Prague might then be recovered to a completely different location that is actually in or near the other city (for example 8FXP X FXF+HJ vs. 8FXP W FXF+HJ).

At the same time, the 9F2P0000+ area overlaps with Germany and Poland, so there would even be locations in those two countries with a short code referencing Prague. That might raise one or another eyebrow as well. ;)

[zongweil]

@tkafka I understand your concern about educating users who aren't familiar with plus codes. How will users obtain the plus code to put into your smartwatch app? Are you planning to link to a map within the app? Or will they get it from another source (e.g. their phone) and then manually plug it in?

@drinckes do you think it might make sense to expose the full code in Maps for the offline use case?

[barryhunter]

I did post about this on the mailing list a while ago https://groups.google.com/forum/?#!searchin/open-location-code/offline%7Csort:date/open-location-code/zvxkqlocZUA/8dCAho8-BgAJ

Agree it seems strange to talk about one of the drivers for OpenLocationCodes was be fully functional offline, but then its highly encouraged to create codes that don't work without access to a gazetteer*. Worse the specs dont mandate any particular gazetteer, so to support decoding ones created by Google Maps, would need the Google Specific gazetteer database (for example).

I think would be interesting to create such a database, would be willing to help. geonames.org or maybe osmnames.org could be used as a starting point.

• at the same time there seems to be very little practical code around, demonstrating using a Gazetteer, along with RecoverNearest to get the full position. (well I can't find any!)

[bocops]

Agree it seems strange to talk about one of the drivers for OpenLocationCodes was be fully functional offline, but then its highly encouraged to create codes that don't work without access to a gazetteer*.

To be fair, short codes do work in offline contexts if the location of the reference point can be assumed to be shared knowledge between all parties involved. This is not necessarily the same requirement as a world-wide gazetteer. For example, one use case of plus codes "in the wild" is enabling postal services to reach people without a proper street address.

If I use an address like CFGH+23, SOMECITY, SOMECOUNTRY, then postal services should be able to first transfer my postcard to the correct city (as long as it is unique in that country), and then it should be able to deliver the postcard to the correct location within that city (as long as the bounding box for the city is not larger than 1°x1°). Both parts of the process work offline - as does the code generation.

[barryhunter]

Thats a good point! Taking the example further, the delivery driver wanting to input destination into a navigation device, could enter the short code, and the device use the current 'GPS' location in hte 'Recover Nearest' process. no gazetteer involved. The decoding of the 'city' name etc, has come via the mail system instead, getting the postcard first to the right local depot.

[chancegold]

Related to this discussion.. Does anyone know if it's accidental or intentional that Maps has been straight up dropping the first 4 characters and using just the xxxx+xx bit?

My use case is full codes for precise location printed as barcodes in order to quickly navigate to a list of locations. OLC codes are fantastic for this as they are as accurate as Lat,Long while being ~half the barcode length. In the last few months as G has expanded the use of the plus codes, I have noticed that it will map/navigate to the "xxxx+xx, city, st" version even if the full code is entered. When mapping a trip that covers the better part of a state, the 'closest locale' pull from gps isn't guaranteed to be accurate, leading to incorrect locations being mapped. This kind of kills it as an "accurate as Lat,Long" solution.

I can see the various sides you guys are discussing with the best way for a user to find their code/easiest way to display while still being offline-capable, etc., but shouldn't full-code always trump any 'nearest-to' or manual 'city,st' pulls?

Back to the original question, though, of whether this is intentional (and thus belongs as commentary attached to this issue) or unintentional (in which case, I will repost as a new, separate issue)- if anyone knows, please let me know.

[bocops]

@chancegold I believe this was an intentional change, probably coinciding with the change in terminology from "Open Location Code" to "plus code" and subsequent usage in Google Maps. The first four characters are now considered to be an "area code" that can optionally be used instead of a town or city name, instead of the other way around: https://plus.codes/individuals (bottom of the page).

This makes sense for the major use case of plus codes to actually address locations within a city (basically replacing street and number in a regular address) - although, as this thread suggests, there still are other use cases where full codes are a more sensible solution.

[chancegold]

So... wouldn't that mean that it is unintentional?

You can use a plus code with a town or city, such as V86P+C8, Paris, or with an area code, such as 8FW4V86P+C8.

If I enter the full code "8FW4V86P+C8", either as an initial destination or an added stop, it should perform the lookup on the full code before/without any area code lookup, no? Preferably, without, since it's not needed and doesn't make much sense to perform an area code look up/conversion just to show the location in the format "V86P+C8, Paris". To me, that seems equivalent to receiving a precise Lat/Long coordinate address, only to look up and display the closest street address, which might be 100km away if the coordinates are in an undeveloped region.

It seems to me that the primary use of OLC/Plus Codes is in areas that either don't have accurate addresses or don't have addresses at all (rural/undeveloped areas). That means that for the areas where OLC/Plus Codes are crucial, there may not be any nearby relevant town/city.

With all of that in mind, while moving towards a more user-friendly "xxxx+xx, city" scheme may seem to work better for some applications, really, is it? It's just somewhat-shortening the existing "street address, city" paradigm while carrying over the issues of such addressing in rural/undeveloped areas if it doesn't offer full-code-first from the ground up. Basically-

if {entered location} = "xxxxxxxx+xxx" or "xxxxxxxx+xx", return offline-algorithm-calculated Lat/Long point/area;

if {entered location} = "xxxx+xxx, city" or "xxxx+xx, city", perform online/local-db lookup of area code, return offline-algorithm-calculated Lat/Long of {area code lookup}{entered location sans city};

if {entered location} = "xxxx+xxx" or "xxxx+xx", perform gps lookup, perform online/local-db lookup of area code nearest gps lookup, return offline-algorithm-calculated Lat/Long of {{gps location} area code lookup}{entered location}; else {closest starbucks}

To be honest, though, I can't really figure out the processes going on in order to replicate what I've seen happening. When it happens, I verify the codes entered, and while some have been a case of a typo/barcode capture misfire, most have been related somehow to the "auto-correct" of a full code to a local code with an incorrect city. I'll see if I can find the note for a specific code giving the error once I get home, but attempts to replicate with, for example, the above Paris code seem to all find Paris; so I don't know.

Regardless- full-code and offline-decodable should both be foundational functions. Use-case specific and user-friendly solutions for short/local codes and the methodologies available are important to decide and standardize, but should be exactly that- standards and methods for specific use-cases, not anything foundational.

[bocops]

I think part of the problem might be that Google Maps, although it accepts full plus codes as input, isn't first and foremost a tool for offline navigation.

As an end user, I probably want the result of a search within Google Maps to be as helpful as possible - and when I paste a full plus code into search while my phone is online, a result basically stating that "this cryptic code refers to a location in Paris, France" seems like a generally good idea. :)

Other than that, I don't think that Google Maps first shortens a full code (dropping the first four characters while adding a location string) only to recover the full code and thus lat/long coordinates later. There does seem to be an issue with some individual plus codes being misinterpreted by Maps, which could be the issue you're seeing - but generally speaking, entering a full code should lead to a map pin in the correct location, even if the code itself is shown in a more human-readable format.

If you can provide a code that misbehaves, I'd be interested to see it. Perhaps yours is the same issue that I've been seeing as well.

[drinckes]

As Andreas says - if you search for a full code, Google Maps will decode it and uses that position. If it can, Google Maps will then convert that code into a plus code address (short code with place name) for display.

We do this because street maps for cities that don't have street names all look pretty similar, and so it's useful to get confirmation that you're looking at Conakry, Guinea vs Lagos, Nigeria.

Hope this helps!

Ngā mihi, Doug Rinckes, Technical Program Manager, Google Switzerland GmbH; 9G8F+6W Zü rich https://www.google.com/maps/search/9G8F%2B6W%20Z%C3%BCrich

On Mon, 3 Jun 2019 at 23:51, Andreas notifications@github.com wrote:

I think part of the problem might be that Google Maps, although it accepts full plus codes as input, isn't first and foremost a tool for offline navigation.

As an end user, I probably want the result of a search within Google Maps to be as helpful as possible - and when I paste a full plus code into search while my phone is online, a result basically stating that "this cryptic code refers to a location in Paris, France" seems like a generally good idea. :)

Other than that, I don't think that Google Maps first shortens a full code (dropping the first four characters while adding a location string) only to recover the full code and thus lat/long coordinates later. There does seem to be an issue with some individual plus codes being misinterpreted by Maps, which could be the issue you're seeing - but generally speaking, entering a full code should lead to a map pin in the correct location, even if the code itself is shown in a more human-readable format.

If you can provide a code that misbehaves, I'd be interested to see it. Perhaps yours is the same issue that I've been seeing as well.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/google/open-location-code/issues/343?email_source=notifications&email_token=ACEN46LQLNC2WVR7XKQDOD3PYWG43A5CNFSM4HOE5FV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODW2ZNZA#issuecomment-498439908, or mute the thread https://github.com/notifications/unsubscribe-auth/ACEN46OZB3QJKAIWUN3KCV3PYWG43ANCNFSM4HOE5FVQ .

[malleo]

Wouldn't it be useful to modify the google maps app as well as the maps web application in a way that they show always the shortend and the full plus code as well as the lat/lon pair? This would give the choice to the user which information he wants to use in his/her use case. Just a suggestion.

[drinckes]

Currently rolling out to desktop Google Maps (may even already be active) is a change so that when you search for a plus code, the global code is put into the URL.

If you search for "9G8F+6W Zürich", the URL will start with https://www.google.com/maps/place/8FVC9G8F%2B6W/....

[torfason]

This new feature that @drinckes refers to is appreciated, but it does not really address the core problem, which goes well beyond offline decoding.

The proponents of plus-codes (OLC), with support from Google, claim to be developing an open and free location standard. This is laudable, and I root for a future in which this has materialized.

But at the same time, Google, the dominant mapping application, is seeding the world with short-codes that are advertised as open but for which everyone except Google is at a significant disadvantage when it comes to decoding them, because nobody outside has access to the proprietary gazetteer used to generate them. And the UI makes it very hard for the user to realize this.

As other mapping providers, such as OpenStreetMap, consider whether to celebrate or fight OLC, this issue must be addressed.

It seems to me that Google is facing a trilemma here, in that it must:

1. Stop seeding the world with short-codes in the way that it is doing
2. Work to ensure that short codes are decodable in a predictable and equitable manner
3. Give up on the idea of plus codes as an open location standard (please don't do that :-))

Of these, I would personally prefer 2, since I can understand the advantages of short-codes from a UI standpoint. This could be done (a) by sharing the location database it uses to generate short-codes, (b) by using an openly available location database to generate the short-codes or (c) check all generated short-codes against an openly available location database and only returning the short-code if it correctly decodes to the right long-code.

In short, if short-codes are to be considered a part of OLC, and not an "embrace and extend" tactic, any generated short-code must be predictably decodable to a long-code using open and non-proprietary components in form of a reference implementation. A short-code that does not fulfil that expectation should be considered to represent a bug in the short-code generation program.

[rsramek]

Dear Magnus,

Allow me to make a few points.

The decision to include the locality in the plus code address is a conscious one. Plus codes as a project have many goals from voting to emergency response, but the one with the largest unrealized impact is a goal of allowing for effective bootstrapping of postal delivery and logistics in less developed parts of the world, in particular most of sub-Saharan Africa and Southeast Asia. As such, the locality must be a part of the address, because while I can already send a package to WFCM+74 Praia, Cape Verde from Switzerland, I'll never be able to send it to "796RWFCM+74".

Decoding a plus code address with a short plus code is relatively trivial if you have a geocoder. You search for all localities with the given name, and you take into account the distance between the closest matching code and the locality. OpenStreetMap is not a mapping provider but a map repository so I don't think it makes a lot of sense to somehow include plus codes in OSM other than in addresses of buildings that have plus code addresses and so far there are only hundreds of thousands of those. What it makes sense to do is to include plus code search support in OSM-backed geocoders, and some indeed already have it. For example I believe short plus codes work in OsmAnd, they work on mapy.cz or the windymaps app. While these were implemented by the developers themselves, we reached out to a number of OSM based geocoders some time ago offering help and were met with a relatively consistent answer: we'll think about it once people ask for them.

I think you are suggesting that we should publish a definite list of localities that can be used to decode short plus codes. That is not doable for a number of reasons, for instance because our data isn't reliable in poorly mapped areas (in fact, due to HOTOSM hackathons and similar, you'll easily find areas in SSA where OSM data is better), and because we would be releasing postal or political division of a country which is something that is completely out of our authority to do. But the beauty of plus codes is that you don't need to do this. The decoding is "the matching suffix closest to given locality" rather than "the suffix with the same prefix as the locality" and that means that if for a point between villages A and B you choose village A and I choose village B, we will still be able to decode the same point. Ultimately, using plus codes still presents a search problem, just a much easier one. Getting the village is easy, getting the road and house is hard.

That was decoding. The harder part is encoding (or reverse geocoding). Because you need to be able to say "which town/village is most relevant to lat long x,y?". That is challenging because you don't want to skip admin area boundaries, country borders, and need to be mindful of disputed borders. Again, this is implementable on your own in principle (mapy.cz/windymaps are working on it, I believe), but we have been looking at options for publishing a library with associated OSM derived data that would allow one to incorporate this easily in code. A request for this from a platform with large user-base would make us prioritize the work. Anything we do pushes back some other plus codes project.

I hope that made sense, it's a bit too late.

[torfason]

Dear Rasťo,

Thanks for your quick and thoughtful response. It is clear that you have a compelling vision for how OLC can be used. I do think and hope that this vision can be achieved while at the same time allaying the concerns that I voiced and others had voiced before on this thread. You answered a number of questions, and I'd like to follow up on some specific points:

As such, the locality must be a part of the address, because while I can already send a package to "WFCM+74 Praia, Cape Verde" from Switzerland, I'll never be able to send it to "796RWFCM+74".

Agreed, this is a compelling use case - basically you are referring to the fact that although the Cape Verde postal service is set up to handle OLC, the Switzerland postal service is not, but they would manage to forward a package to Cape Verde where it would be processed further.

You also mentioned that OLC already works on mapy.cz and other sites (awesome!). I was not aware of this, I went ahead and tried entering "WFCM+74 Praia, Cape Verde" on mapy.cz and yes, it works like a charm.

However, I also tried another code, "2GH7+95 Skinnastaðir" (AKA: "9CR52GH7+95"). This is the address of the visitor center at Asbyrgi (in Iceland), generated by Google Maps, and correctly decoded with Google Maps, but not with mapy.cz, which means that it is useless without access to GMaps (as an aside, in order to get the long code I had to go to plus.codes, because for this location the long code did not seem to be present even in the url, I'm not sure why that is the case).

The user might feel that this is evidence that an alternative mapping application is inferior, while in reality it comes down to using a proprietary (and perhaps overly inclusive) list of locations that are allowed as anchors for short-codes. Skinnastaðir is a farm, not a town, and I'm pretty sure that no postal service would be able to deliver to that location using this short-code.

I think you are suggesting that we should publish a definite list of localities that can be used to decode short plus codes. That is not doable for a number of reasons ...

But this comes back to my point, that this is an absolute inviolable requirement for an open standard. And perhaps more specifically for solution c ("check all generated short-codes against an openly available location database and only returning the short-code if it correctly decodes to the right long-code"). The best approach if a reference decoder would fail (as it probaly would in the case of Skinnastaðir), would in fact be to fall back to a long-code. And for an open standard, that decision should be based on open data.

... if for a point between villages A and B you choose village A and I choose village B, we will still be able to decode the same point.

Yes, that is true, if both you and I know about the existence and location of villages A and B. The issue is that if you generate a short-code based on village A, but I do not know anything about village A, then I will not be able to decode it.

That was decoding. The harder part is encoding (or reverse geocoding). Because you need to be able to say "which town/village is most relevant to lat long x,y?". That is challenging ...

Agreed, and I don't think a reference implementation for this is a precondition for OLC to be an open standard. In encoding, individual providers can compete to come up with the best option. However, regardless of which reference point is used (village A or B), my suggestion is that before it is delivered to the user, it must be checked against a reference implementation decoder to ensure that it actually is independently and predictably decodable.

... we have been looking at options for publishing a library with associated OSM derived data ... anything we do pushes back some other plus codes project.

That would be awesome. I think a reference decoding library would be the key issue, a reference encoding library would be more of a "nice-to-have". And yes, I am also sympathetic that you must prioritize your work. For me (and I suspect for others who have commented), the key thing is not whether such a library would be promised tomorrow. Rather, I would be hoping for an openness towards having such a reference implementation become tightly integrated into the OLC standard, and treating any short-code that is non-decodable by such an implementation as a bug (or at least a deficiency) in the specific encoder implementation. Such a deficiency could then be resolved either by changing the implementation (and producing a long-code if no suitable short-code can be generated), or by adding the corresponding anchor to the reference database.

In the meantime, I guess the robustness principle applies: "Be conservative in what you send, be liberal in what you accept". And until a reference decoder exists, I also think it would be justifiable to make it easier to get hold of the long-code than asking users to copy it from within the URL.

Thanks again for all your hard work!

[apatrida]

@rsramek

WFCM+74 Praia, Cape Verde from Switzerland, I'll never be able to send it to "796RWFCM+74".

But you are omitting the idea that you could send it to 796RWFCM+74 Praia, Cape Verde from Switzerland and then the extra location information is informative but not required to decode the value.

The shortcodes are undermining this standard due to what @torfason mentions:

1. stop seeding the world with short-codes in the way that it is doing

The easiest way to get pluscodes all generate and show shortcodes by default, and even copy shortcodes to the clipboard.

"Send me your pluscode", ... "no, that is the short code, my program can't use those, get the long code". ... "how? no, Google maps on your phone only shows the shortcode, go to https://plus.codes and use the find-your-code page" ... "what? no it shows the shortcode too?!?! ... Click the up arrow thingy at the bottom to get a sidebar, then go copy the full code from the left." ... "no, not just the bolded part, the whole thing including the 4 extra characters to the left" ... "no I don't know why it is so hard, sorry, just send me the code."

That doesn't seem to be worth saving 4 characters of typing or copying by just giving the full code from the start.

I suggest that you never seed shortcodes ever, and probably even remove them from the spec as a core feature (make it optional for local focused applications). Pluscodes are longer but work, short version of pluscodes sometimes work, but likely not outside of Google.

I would rather receive this offline decodable version (not requiring a location database):

766HQ6HC+Q6

Or this longer version of the same (that works for your international mailing scenario):

766HQ6HC+Q6 Santa Rosa de Copan, Honduras

Rather than this ambiguous shortcode that I can't decode without location data of the sender:

Q6HC+Q6

Or this online-only decodable shortcode (with newline) from plus.codes/map:

Q6HC+Q6
Santa Rosa de Copan, Honduras

Or this online-only decodable shortcode from Google maps:

Q6HC+Q6 Santa Rosa de Copan, Honduras

Change Google maps and the https://plus.codes/map/ page to return the full code plus optional informative location, but never use the shortcode by default.

[torfason]

And now it seems like it is utterly impossible to get the full code from Google maps (not possible even to get a full code with some sort of info button). Yuck!

[RiverMersey]

Sort of, it is still possible to get individual plus codes using: https://plus.codes/map Also, remember that site does use Google maps and the 3 horizontal lines icon gives the option of showing the satalite view

Get Outlook for Android

[fulldecent]

The plus codes specification (to be written) notes that a specification location must be provided in lat/long.

This is a known and documented part of this project.

Recommending to close issue as out of project scope.

[torfason]

A specification location does not have to be provided in general, only for short codes. Full codes are absolutely decodable without a reference location, as has been stated numerous times in this thread.

This issue concerns the fact that Google, the sponsor of plus codes, insisted on first making it hard, then impossible, to get full codes using Google maps, which is probably the most prolific source of plus codes in the wild. That issue is still very open.

However, I've long ago given up any hope that plus codes are anything other than Google's attempt to gain control of a location standard that looks open but is actually completely proprietary, and usable in practice only within their own apps and APIs. So, if the admins of this repo agree with that strategy, by all means, go ahead and close this issue :-)

[fulldecent]

I assert that this project doesn't have a (complete) specification even for global codes or for implementations.

Many ideas are here but this is not specification-level work. I am working to fix this by writing an actual, implementable spec and updating all implementation to follow and test for that spec.

You have a valid criticism that short codes are of limited utility until multiple, competing implementations can show cross compatibility.

And I agree with your sentiment that an "open" specification with only one usable implementation is not meeting the spirit of an open implementation. Cough cough Office Open XML, sneeze ISO lost 20 years of reputation with that.

This project is not as bad as Office Open XML. Because anybody can open a paper map (offline) and find an approximate latitude and longitude for Paris. This has O(1) complexity and space requirements assuming you stay near home and only care about locations near you. For arbitrary definitions of "near" this is almost certainly true for most humans.

Therefore we can complain about the lack of competition but I think that criticism for Google is unwarranted.

I think there are two actionable items here:

1) The new specification (I'm writing it) should clearly express the limitation of short codes in succinct and informative language. I welcome your contributions here.

2) A new reference location project may be started. Perhaps named "Well Known Places". This could be a dataset of reasonably many (how many?) locations including a center lat-long and names translated into every human language. The "many" should be set "small" if there are limited resources to update the list because names change. Also note that location names are subject to contention. This dataset could be created manually or generously donated by Google, Microsoft, Garmin or others. Such a project is probably not in scope for this repository. But I hope owners here would accept a PR that links to such a project if it were to exist.

I can help with item 1 here.

If there are significant resources and interest available, and a commitment by owners to merge a PR noted above, then I can help to organize that project as manifested as item 2 here.

[torfason]

@fulldecent, I agree with much of what you said.

If there are significant resources and interest available, and a commitment by owners to merge a PR noted above ...

I think this is a key issue. I feel that my posts in 2019 were an attempt to contribute to item 1 (in terms of what the policy should be), and I actually started some experiments implementing item 2 (as an R package, using OSM data). However, the responses to the posts (@apatrida also had some thoughtful insights), coupled by the subsequent decision by Google to remove the ability to get full codes using Google Maps, convinced me that the owners are not at all interested in going this route and that trying to contribute towards this was a dead end.

I hope that you will find that I am mistaken and that you are able to meaningfully contribute to OLC.

[fulldecent]

Google, as a whole, does not necessarily have consistent interests in its Google Maps product and this OLC project.

(I am an ex-Googler and do not speak for any of the entities involved.)

Because people with commit access here are not completely AFK, I am treating this project with a hopeful optimism and the "GitHub street rules" of "if you show, do all the work, fully understand the project scope, and the committers are fair, then you can lead any project from the bottom."

---

Regarding item one // https://github.com/google/open-location-code/issues/343#issuecomment-826325385 do you have some proposed wording?

---

Regarding item two // https://github.com/google/open-location-code/issues/343#issuecomment-826325385 I'll consider this dead until someone with commit access tells me there is interest to link, and resources are available from somewhere.

[fulldecent]

This issue is fixed at https://github.com/google/open-location-code/pull/463

The statement "Codes should be able to be generated and decoded offline" is removed and appropriate marketing claims are made as to which codes can be decoded offline.

And additionally, the short code specification is tightened, and there are notes to explain under which circumstances a short code could be exchanged between two parties:

A short code Plus Code is meaningful only when the producer and consumer of the Plus Code can agree on the approximate latitude and longitude of a reference location. A short code can be easier to use and remember than a full code.

[drinckes]

Dragging this back on topic, yes, it is possible for people to create short codes with localities. No, it is not in scope of this project to generate a prescriptive collection of place names for the world. Why?

The problem is not that people do not know their town or neighbourhood or village name. The problem is they don't have a street name or number. That is the bit that plus codes are solving, both the global codes and the short codes + locality.

So we don't want to generate a set of localities that end up generating short codes with locality names that are not what are in actual use. Basically, "yes, you know you live in Oberrieden but that place was too small so we left it out and you have to tell people you live in Zurich".

Anyway, closing this as we're not going to try to produce a global locality database.