2

Many geocodes, such as Geohash and OLC (Open Location Code), can be reduced by a context reference, as described here and here.

For example:

Being able to say WF8Q+WF, Cape Verde, Praia is significantly easier than remembering and
using 796RWF8Q+WF

The resolver software take "Cape Verde, Praia" (or ISO abbreviation CV instead Cape Verde) and transforms it into a code prefix... The resolver make use of something like a lookup table, 

Prefix | Country | Name (replaces prefix) | Reference is it?
-------+---------+------------------------+------------------
796R   | CV      | Praia                  | 796RWFMP ?
796R   | CV      | Joao Varela            | 796RXC4C ?
797R   | CV      | Cruz do Gato           | 797R3F38 ?
...    | ...     | ...                    | ...

I am supposing that the hidden (black box) algorithm do something simple, based on an official lookup table like the illustrated above. It use prefix of the lookup table to translate short code into complete code, or the inverse:

  • Translating short code to complete code. To retrieve the location from the OLC short code, just know the prefix.
    Example: "WF8Q+WF, CV, Praia " will use the line of CV | Praia of lookup table, that informs the prefix 796R to resolve the code, concatenating prefix with suffix, "796R" with "WF8Q+WF".
    It is like a function
    recoverNearest('WF8Q+WF', getReferencePoint_byText(lookup,"CV", "Praia"))
    but Google/PlusCodes not published lookup dataset of Cape Verde.

  • Translating complete code to short code. To show the short code from location (e.g. from 796RWF8Q+WF), is necessary to check the "nearst reference" to resolve the spatial query — Joao Varela and Praia lines have same prefix, but Praia's reference, by 796RWF, matches better.
    It is like a function
    shorten('796RWF8Q+WF', getReferencePoint_byNearFrom(lookup,'796RWF8Q+WF'))
    but Google/PlusCodes not published lookup dataset of Cape Verde.

Question: where official lookup table of Cape Verde?

NOTES

We can split in more questions to generalize:

  • Is plus.codes really a black box?
    (perhaps I am using some wrong hypothesis on my explanation)

  • The lookup table of a country like Cape Verde exist, and we can download it? where Google is publishing it?

  • The official lookup table of Cape Verde exists and Google is respecting it... where Cape Verde govern is publishing it?

More illustrations for readers that not understand the central problem:

  • Translation from complete code to short code. Suppose the prefix 796R, when a complete code 796Rxxxx+yy is translated to "Praia xxxx+yy" and when is translated to "Joao Varela xxxx+yy"?
    It is an arbitrary choice if you not have a table with the PlusCode official references.

  • Translation from short code to complete code. Suppose that I am developing a Javascript software. The inputs are the short code xxxx+yy and a name (country and city or contry/state/city/district). Suppose only Cabo Verde country names, how to convert names into prefixes exactly as PlusCodes?

(edit after discussions) A preliminary conclusion. There are only two possible answers to the question:

  1. show a link where PlusCodes published its name-to-prefix table;

  2. show the source-code of an algorithm that reproduces exactly PlusCodes, that you developed by reengineering.
    I supposed that the most simple algorithm use the ordinary OLC encode/decode, and a parser for translate names into prefixes (or vice-versa), based in an "official lookup table".

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Peter Krauss
  • 13,174
  • 24
  • 167
  • 304
  • Alexander is right. The open-source specification defines Open Location Codes, or pluscodes, and how if you restrict yourself to a given area you may be able to skip some of the start of the code and still get a unique result. The list of areas and what you choose to call them is outside the scope of the spec. The `plus.codes` site itself has its own list, and since it is based on real-world data you could make your own list that matches (the guidance around the spec even says it contains a margin-of-error to allow for this), but this data itself is not part of the spec. – Rawling Jan 18 '20 at 00:06
  • Also note that the list needn't (or maybe even shouldn't) be a map from name to a prefix. The points within a given named area could have different prefixes if the area lays across a high-level "grid line", but the area will still uniquely identify a point. – Rawling Jan 18 '20 at 00:11
  • See similar (but **not** duplicate) questions: at [OpenData](https://opendata.stackexchange.com/q/16121/1313) and [here](https://stackoverflow.com/q/73738764/287948). – Peter Krauss Sep 18 '22 at 14:44

1 Answers1

0

Open Location Code is just another form of standard geographic coordinate: latitude and longitude. So, to get OLC for any place you need only geo coordinates for this place (see encoding section) and vice versa.

With database of Cape Verde towns and their coordinates you can build your own lookup table for quick OLC transformation with any required precision (starting from Wikipedia List of cities and towns in Cape Verde or using any of free world cities databases) or you can just convert OLC to latitude and longitude and than work with this coordinates.

Alexander Ushakov
  • 5,139
  • 3
  • 27
  • 50
  • Hi Alexander, thanks the good intention, but it is not an anwer, please read the question with some attention, it is about *short code* convertion and the reference points/names for it. It is **not** about *complete code* (complete OLC), that you described. After it, if you believe you have a solution edit with your answer with a complete solution/algorithm (or link to a site that is not PlusCodes but obtain identical return for all places, to and from short codes). – Peter Krauss Dec 24 '19 at 18:04
  • @PeterKrauss short form is just replacement of left part of OLC with country and, optional, city name in human readable format. It is made through the same intermediate conversion from OLC to coordinates as described in my answer. If you know geo coordinates, you can get country and city and vice versa – Alexander Ushakov Dec 24 '19 at 18:08
  • Alexander, you is copy/pasting definitions, but not show that you have the power to reproduce [Plus.codes](http://plus.codes) behaviour.. Please read and show a solution for "Joao Varela vs Praia" for example. – Peter Krauss Dec 24 '19 at 18:12
  • @PeterKrauss Please, describe what exactly causes problem. If you need algorithm for converting short OLC into long format: 1. convert `CV, Praia` into its coordinates and than into long OLC 2. Replace last symbols with your short OLC Note: for places with different sizes short OLC may have different encoded part length. So you cannot use fixed length prefix as in the example in the question – Alexander Ushakov Dec 24 '19 at 18:23
  • Hi Alexander, see at question's text the prefix `796R`, when a complete code `796Rxxxx+yy` is translated to *"Praia `xxxx+yy`"* and when is translated to *"Joao Varela `xxxx+yy`"*? It is an arbitrary choice if you not have a table with the PlusCode official references. – Peter Krauss Dec 24 '19 at 18:48
  • Praia has real prefix `796RW` and Joao Varela - `796RX`. So real short code for `796RWF8Q+WF` is `F8Q+WF, Cape Verde, Praia` (you can check it on plus.codes). But Google want to use unified short codes with fixed length for all places. Thats why it looks like "Praia Wxxx+yy" and "Joao Varela Xxxx+yy" – Alexander Ushakov Dec 24 '19 at 19:00
  • `796RWxxx+yy` will be translated to Praia and `796RXxxx+yy` will be translated to Joao Varela – Alexander Ushakov Dec 24 '19 at 19:02
  • Hum.. Now you see: PlusCodes is a BlackBox, you can't reproduce exacly the PlusCodes behaviour. – Peter Krauss Dec 24 '19 at 19:03
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/204810/discussion-between-alexander-ushakov-and-peter-krauss). – Alexander Ushakov Dec 24 '19 at 19:03