Talk:Open Location Code

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Possible COPYVIO[edit]

Most of the lead looks like it may have been copied from [1] Nyth63 16:51, 17 November 2017 (UTC)[reply]

That link was published several years later than the WP article. −Woodstone (talk) 19:09, 5 September 2018 (UTC)[reply]

Grammar[edit]

The sentence In the code, each time one digit of latitude and one of longitude alternate. does not parse well. I think it means that the code digits alternate between latitude and longitude. There may be a comma or word missing but I did not want to edit it and change the meaning. Nyth63 17:06, 17 November 2017 (UTC)[reply]

The other "right"?[edit]

The last paragraph of the example reads "The next step takes the rightmost block on the second row from the bottom in this block: 6PH57VP3+PR6." If this refers to the table above, the "6" is in the *leftmost* column, correct? FBitterlich (talk) 10:10, 5 September 2018 (UTC)[reply]

Yes, indeed. I corrected the location based on newer and more clear Google satellite images and forgot to update the explanation. The location jumped over the border between blocks. −Woodstone (talk) 19:03, 5 September 2018 (UTC)[reply]

Cabo Verde[edit]

Just for reference related to the "Google states that" element: you can check the active usage on the Cabo Verde postal website, and when I was talking lately with cleaners from Cabo Verde in the Netherlands they were amazed that I knew about this: it's really a live changer for them there. LaPingvino (talk) 14:12, 12 February 2019 (UTC)[reply]

Plus one character codes[edit]

The website https://plus.codes does allow the codes like GV2G+ and GV2G+75, but does not allow GV2G+7. Currently the article looks as if they are okay. Is there some official rule that discourages them? Hellerick (talk) 04:27, 18 May 2019 (UTC)[reply]

The article states "the code begins with up to five pairs of digits" and "after 8 digits, a plus sign (+) is inserted in the code". In the discussed code there are 9 digits (not counting the inserted +), forming 4 pairs and a dangling digit 7, making it an invalid code. −Woodstone (talk) 06:50, 18 May 2019 (UTC)[reply]

Shortened codes without a locality[edit]

Four- and six-digit codes are described in the opening section as valid only when combined with a locality; however, Google Maps and the site plus.codes supports shortened codes. The behavior of the websites appears to be that the inferred location of the browser is used to generate the unspecified leading digits. If this is a behavior only of these tools, I suggest that an expansion of the Usage with Plus codes section is warranted to describe this usage. I also suggest that "Extensions with Google Maps and plus.codes website" may be a better section title. -TimberFeller (talk) 16:02, 7 September 2020 (UTC)[reply]

Redundant section "Other geocode systems"?[edit]

Hi all, presently there is a section entitled "Other geocode systems" which seems redundant to me, since a superset of the same information is contained in the template "Geocode systems" which maintains all such information in a standard manner and a single place. In the article, this template is currently hidden by default but could be displayed by default instead - as per other similar pages e.g. ICES_Statistical_Rectangles, which has no such section (not deemed necessary, since the template provides all that is required). If others do not object within a little while, I will remove this section and set the "Geocode systems" template to be displayed by default instead of hidden... any thoughts? Cheers - Tony Tony 1212 (talk) 19:17, 26 October 2021 (UTC)[reply]

OK, have "been bold" and implemented the changes as flagged above, after checking that no other similar pages have such a section, and all use the template. In order to get the template to default to show, not hide, I had to delete a second one ("Google") that is not so relevant in my opinion; apparently, multiple templates at the foot of a page always default to hidden, not so good in this case... more explanation at https://en.wikipedia.org/wiki/Template_talk:Hidden . Tony 1212 (talk) 05:51, 28 October 2021 (UTC)[reply]

Use of "see also" section[edit]

Anonymous user 2A00:23C5:FE20:5901:FCB5:82C4:D59E:318D has added "what3words" to the "see also" section, which is to my mind redundant - would have been in former section "Other geocode systems", treated as redundant since October 2021 (see immediately above) and replaced by template "Geocode systems", which already includes what3words - so I am deleting this to avoid scope creep of the "see also" section... Regards Tony Tony 1212 (talk) 18:34, 8 January 2022 (UTC)[reply]

Clarify context for various use cases of short codes[edit]

I recently updated the section on short codes: https://en.wikipedia.org/w/index.php?title=Open_Location_Code&diff=prev&oldid=1120589531&diffmode=source After a brief conversation with @LaPingvino at https://eo.wikipedia.org/wiki/Uzanto-Diskuto:NealMcB (Recent edit on Open Location Code), the current paragraph once again confuses the situation by claiming that context is not necessary, despite the fact that in the cited (first-party) page, context is always explicitly noted in the examples given. It must be understood that there are many many use cases for location coding systems, and we can't e.g. assume that any particular bit of decoding software knows where the user is. I've blended in the new cite and some of the new clarifications to my earlier edit. ★NealMcB★ (talk) 04:02, 25 November 2022 (UTC)[reply]

@Nealmcb you still repeated again the falsehood that the reference maps directly to the prefix, this is NOT how short codes work. LaPingvino (talk) 16:38, 25 November 2022 (UTC)[reply]
Ahh - thanks for clarifying the lack of a 1-1 correspondence between prefixes and reference locations. I've updated the text to hopefully avoid that misunderstanding, make it clearer and avoid some repetition. ★NealMcB★ (talk) 18:54, 27 November 2022 (UTC)[reply]

PlusCode is not OLC[edit]

PlusCodes is the Google-map infrastructure, including PlusCodes API. The PlusCodes solve names, the OLC algorithm say nothing about "how to solve names", it is only a open-standard that suggest rules for shortening codes. The PlusCodes algorithm is not open, it has a black box (with no data base "model + algorithm" and no open data samples for reproducibility), about its shortening process:

See https://github.com/google/open-location-code/issues/497

The rules of the "name to prefix" black box are explained at git.OLC/docs/specification.md#short-codes.

Source-code of the diagram:

flowchart TD
A[Enter a Plus Code] -->|type: 598P+Q36 Itagui, Antioquia, Colombia| B[Split it into 2 parts]
B -->|name=Itagui, Antioquia, Colombia| E[Resolves the name to<br/>a prefix in a <i>black box</i>]
B -->|suffix=598P+Q36| D[Concatenate prefix+sufix]
E-->|prefix=67R6| D
D-->|olc=67R6598P+Q36| F[Convert OLC to LatLon]

Krauss (talk) 18:52, 29 August 2023 (UTC)[reply]

Hi @LaPingvino, can I split this article into two? Plus Codes is another page. 2804:14C:43:3582:CCCA:CA2C:9478:819D (talk) 22:25, 17 December 2023 (UTC)[reply]
@2804:14C:43:3582:CCCA:CA2C:9478:819D it's literally the same thing. LaPingvino (talk) 00:41, 18 December 2023 (UTC)[reply]
@Krauss it's NOT a black box, I tried to explain this to you before. Google isn't deterministic in this either. It works exactly according to definition and you can fully replicate this with open systems or even with paper maps of any make. My tool at whenwhere.cf relies on this. LaPingvino (talk) 00:44, 18 December 2023 (UTC)[reply]
See reaction https://github.com/google/open-location-code/issues/500 to mentioned Github issue to have a proper response. It points out the prefix vs reference point misunderstanding and the high viability of using any other dataset like Nominatim for resolving codes properly. Unlike suspicions by several people, the data set involved is literally just "general geocoding data" which has open alternatives and can even be done by e.g. paper atlas. LaPingvino (talk) 02:00, 18 December 2023 (UTC)[reply]