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

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.

[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.