Not sure if that was intentional, but in the definition of DecodePairsSequence :

while (i * 2 + offset < code.length) {
      value += CODE_ALPHABET_.indexOf(code.charAt(i * 2 + offset)) *
          PAIR_RESOLUTIONS_[i];
      i += 1;
    }

If the code is long enough, i can get large enough to provoke an array out of bounds access as offset is either 0 or 1.
For example, with +7FG4.9QCJ2VXGJ

LIne 601 (test suite):

MsgBox ("IsFull test " + CStr(i) + ", expected: " + CStr(validity(i)(2) = "true") + ", actual: " + CStr(f))

This ()SHOULD BE():

MsgBox ("IsFull test " + CStr(i) + ", expected: " + CStr(validity(i)(3) = "true") + ", actual: " + CStr(f))

(Notice: the sub-subscript "2" was copied from, presumably, line 597 and was not updated (line 600 was properly updated when copied from line 596).

The current travis config tests js, go, ruby, python and rust.

But cpp, dart, java, js/closure are not automatically tested. Also weirdly travis thinks it tests js three times and I don't know what's going on there.

The new travis.yml file uses matrix:include to set up a node.js and rust instance.

Travis has a language setting for dart.

cpp, java and js/closure are currently tested using bazel BUILD files. It may make sense to have a single configuration that tests all three to reduce the number of times bazel has to be fetched.

Last time I checked a geohash also describes an area. Truncating it only extends the area loosing precision but it will always include the area defined by the longer string.

http://geohash.2ch.to/9r0zn74kf22z
http://geohash.2ch.to/9r0zn74

Please correct comparison.adoc

In a test C++ implementation, long codes were causing segmentation faults. This was due to the grid computation, where the size of the grid squares are computed in degrees latitude and degrees longitude. These start at 1/8000th of a degree, and with each step, divide by 4 (latitude) or 5 (longitude).

Fairly quickly these can get to the minimum values that can be represented as floats and cause underflow errors.

To avoid this happening, I propose to limit the length of OLC codes. This would avoid this problem while still allowing extremely precise codes. 16 digits gives roughly centimeter resolution, and with 32 digits the OLC area is only 7.86E-11 cm wide (this is in the order of a helium atom).

I don't think it matters a great deal what the limit is as long as we define one.

The changes required are:

• To modify the isValid method to reject codes with more than 32 digits or with more than 24 digits after the separator
• To limit the encode method to only return codes with a maximum of 32 digits.

Do the grids exist in the form of a GIS dataset? shapefile, spatialite, geojson, etc.?

I would like to have a reference layer of the grids with my own data and was wondering if anyone generated this and made it available publicly.

@Ironholds created https://github.com/Ironholds/olctools back in 2016. It really should be in this list of OLC implementations.

What is the relation between plus code and the Google S2 coordinate scheme?
https://github.com/google/s2geometry

From reading the specification I could not work out how to identify for example flats that are vertically stacked within a high-rise multiple occupancy building.

Food for thought, but I see a problem when it comes to apartment-style living, especially one with a lot of floors. It might be of interest to look into solutions when say a building has 6 floors and 12 different families live in it. With Open Location Code, they would all fall into the same precise square - yet need to somehow be made unique.

Hi All,

 I'm evaluating OLC for a hands on project to snap a grid cell based on a gps location. The proposal is to create Areas that are hashed for faster look ups on caches. Basically i'm playing around mapping a road network using OLC. There does not seem to be an API or a simple understanding of how to traverse the neighbours..

 The problem is: Supposing there are 100Meter by 100Meter precision areas mapping to different roads that pass through, I'm trying to find what is the traversal (algorithm) route to my destination.
 Any light on this is highly appreciated...

Best Regards
CVP

I created a Swift 3.x implementation based off your python/rust/C++ code and it is available as a cocoapod for people who want to use it in developing iOS applications. If you'd rather that I just give you the code (since it's 99% yours), I'd be more than happy to.

The cocoapod is here

I assume the plus code will be written unchanged (left-to-right) even in RTL languages, but it would be good to specify it. If English were RTL, this is what I'd expect:

.there weren't you but 23456789+23 to went I

Hi,
I am calling the api:
https://plus.codes/api?address=17.422066,78.338942&key=<api_key>
I have enabled GeoCodingAPI in developer console. While I am trrying to get the PlusCode for the above address, I am getting error: "No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost' is therefore not allowed access."
Please suggest if I am doing anything wrong.
Thanks in advance.

Hello there,

In Google Maps help page it says that 'Plus codes aren’t shown in some countries.'

• Where do we find this list of countries?
• Is it just some country-based regulation, or some specific flaw / problem in the overall code / implementation?

Curious since I'm looking to support / utilise it in a precision service, thank you.

I noticed slightly different plus codes results of a specific point between the plus code API search and the plus code webpage search.

E. g.:

point (Lat,Lon): 50.963400,13.939100

search result api: 9F2MXW7Q+8P

search result webpage: 9F2MXW7Q+9J

Formatting section in https://github.com/google/open-location-code/blob/master/docs/olc_definition.adoc
conflicts with API definition for isValid function in https://github.com/google/open-location-code/blob/master/API.txt in following:

Formatting: The solution here is to use zero, as a padding symbol, giving us 6GCR0000+.

isValid: If the separator character is present, it must be after four characters.

In large cities, when description a store, a restaurant or a venue, most of time we need to also state our it's floor. If we could also add floor number to the end of open location code, we can even present location where coordinate cannot cover.

We can considering to add a '+/-' in the end to indicate the floor numbers (ground floor = '+0', minus represent underground floor ).

Do you have a TCL version? If not, I have "translated" the code and the test suite passes successfully (VBA --> TCL)

Sorry for the bug report; I couldn't find a "contact" link for this project.

Encoding a code using a 90degree latitude and code length of 10 causes a segfault.

The problem is to reduce the latitude to be within the code area. If the latitude is 90 degrees, it needs to be reduced. One solution is to compute the resolution of the code, and reduce the latitude by a fraction of that amount.

If the code length is 10, the resolution should be 1/8000th of a degree. Instead it was computed as 8000 degrees. The latitude was reduced by the resolution / 20, which meant that instead of 90 being turned into 89.99999375 it was being turned into 90 - 80000 / 20 = -310.

If the code length was more than, or less than 10, the latitude is adjusted in a different code path that worked correctly.

2.3.0 :020 > olc.encode(43.845825324701, 87.6474347905425) => "8MM9RJWW+8X" 2.3.0 :021 > [olc.decode('8MM9RJWW+8X').latitude_center, olc.decode('8MM9RJWW+8X').longitude_center] => [43.845812499999994, 87.6474375] 2.3.0 :022 > olc.decode('8MM9RJWW+8X') => #<PlusCodes::CodeArea:0x00000009ab8458 @south_latitude=43.845749999999995, @west_longitude=87.647375, @latitude_height=(1/8000), @longitude_width=(1/8000), @latitude_center=43.845812499999994, @longitude_center=87.6474375>

I think its a good project that appeals with the travelling demographic as not all places actually have addresses.

Though would be good to get as many libraries up for this. Would love to see the JS code usable in node.js though (ideally as something you can install with npm)

Thoughts?

Hi, sharing an issue with plus codes that say a postal service or a database operating at the level of a country like India would experience:

• I have one location in Pune city, which is in Maharashtra state of India: https://i.imgur.com/1xlxexM.png
• I copy the plus-code given at the bottom. It is a shortened version, but an unfamiliar person wouldn't know.
• I open maps.google.com and am looking at all of India. I type in the plus code : GRW4+7J . It takes me to another address in another state.
• I search for "GRW4+7J, maharashtra". It still takes me to another address in the state.
• I include two more letters from the left of the full plus code (note, at this point the lay person will have abandoned the search): CMGRW4+7J
• I go back to all-India map, and search for it. It takes me to the ocean, somewhere near Myanmar.
• It's only when I type the full code, 7JCMGRW4+7J that I get the correct location.

Can we make arrangements so the default display on plus.codes (that shows at the bottom of the page) shows the full code in small size in brackets to the right or something, or in a ?-tooltip advising the user to use the full code in case of searching over a large area like state or country? It's there when you click further, but it's not very intuitive to open that and doesn't always open.

Also, a copy-to-clipboard button would be great!

If you want to use open location codes (or plus codes) it would be great to have a logo/icon, so if you reference it on sites or even print material, then you have some (additional, besides the plus) identifier. Maybe something like a geo-pointer with a plus inside it (or since it's from google a "g+"?)

"+" is the separator character, used to break the code between neighbourhood and building levels, and to help disambiguate OLC codes from postal codes.

On its own it has no meaning - it has to be either preceded, followed (or both) by valid OLC alphabet characters.

Currently the method that checks for validity passes. Adding a check that the code does not solely consist of "+", and returning false if it does, will solve this issue.

Currently, Plus Codes only work with roman characters A-Z and arabic numerals 0-9. While this isn't an issue in any countries that use roman-scripted languages, it can be incredibly alienating to anyone whose primary or only languages use non-roman scripts. This can be a huge barrier to understanding and ease of use if users don't know or understand Roman script. What should Plus Codes do for non-Roman scripts? Should they just have character substitution or have a different system altogether?

This is shorter solution
https://gist.github.com/webstory/9739339b163f765a36a3f7f353d55590

In some cases, recovering a short code to a full code does not return the nearest match.

Calling recoverNearest('22+', 14.9333, -23.5125) returns 796RXF22+. This is not correct - the nearest match is 796RXG22+.

The problem seems to be with the step where the reference latitude and longitude are rounded down before generating the candidate code. In the above example, it should generate a code whose center is at most .05 degrees from the reference location, but due to the rounding down it is .08 degrees away.

It appears that removing the rounding down step entirely fixes this.

Would be nice to see it in the list at https://github.com/google. Thanks!

While the documentation says it returns an unchanged code for full code input, it actually raises a ValueError instead.

 Returns:
   The nearest full Open Location Code to the reference location that matches
   the short code. If the passed code was not a valid short code, but was a
   valid full code, it is returned unchanged.

openlocationcode.recoverNearest("9FMC3QQP+29", 0.0, 0.0)
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "/home/shoeper/Documents/dev/jodelbot/libs/openlocationcode.py", line 285, in recoverNearest
    raise ValueError('Passed short code is not valid - ' + str(shortcode))
ValueError: Passed short code is not valid - 9FMC3QQP+29
# expected output would be 9FMC3QQP+29
openlocationcode.recoverNearest("3QQP+29", 0.0, 0.0)
'6CGX3QQP+29'

Codes missing leading digits can be recovered using a reference location. The general approach is:

1. Take the reference location and generate a long code;
2. Use the leading characters of that code as a prefix for the short code;
3. If the latitude of the new code is more than half the resolution of the missing prefix north or south of the reference location, move the new code by one step in that direction (i.e., north or south).
4. If the longitude of the new code is more than half the resolution of the missing prefix west or east of the reference location, move the new code by one step in that direction (i.e, west or east).

This can produce incorrect results when the reference latitude is closer to the pole than the desired recovered code as it moves the code to a latitude greater than 90 degrees, or less than -90 degrees.

Here are two examples:

1. Short code is 2222+22, reference location is 89.6,0.0. We encode 89.6,0.0 and prefix the short code with the first four digits, giving CFX22222+22 with a center latitude of 89.0000625 degrees. The resolution of a four digit grid is 1 degree, and the latitude difference between the code center and 89.6 is 0.5999375 degrees. This is more than half a degree so we move the code north by one degree to 90.0000625 degrees latitude. Since that is invalid a bad code is returned.
2. Short code is XXXXXX+XX, reference location is -81.0,0.0. We encode -81.0,0.0 and prefix the short code with the first two digits, giving 2CXXXXXX+XX with a center latitude of -70.0000625 degrees. The resolution of a four digit grid is 20 degrees, and the latitude difference between the code center and -81.0 is 10.9999375 degrees. This is more than 10 degrees so we move the code south by 20 degrees to -90.0000625 degrees latitude. Since that is invalid a bad code is returned.

These two test cases should be added to each implementation and then the implementations need to be modified to ensure they pass.

East/west adjustments across the 180 degree longitude line don't seem to exhibit this bug.

It would be great if the python project were installable via pip.

The codes aren't case sensitive and don't include easily confused characters. We've selected the characters to make it difficult to impossible to spell words in any language.

should be

The codes aren't case sensitive and don't include easily confused characters. We've selected the characters to make it difficult to impossible to misspell words in any language.

#81 identifies an error in the encode method in python.

What it does is require the length parameter to be an even number, if it is less than the separator position (8). This is incorrect, it needs to be an even number if it is less than (or equal to) the pair code length (10).

The result is that encode can request a 9 digit code, which isn't valid. Currently I think implementations return a 10 digit code anyway, so the result of fixing this will not change the codes generated, but to throw an error when requesting a 9 digit code (invalid length).

There is entire category of spherical location codes used in astronomy. Compared to Lat/Long codes it does not have distortion and requires shorter code.

Not sure if this is useful, just FYI

http://healpix.jpl.nasa.gov/

http://research.microsoft.com/pubs/64531/tr-2005-123.pdf

http://www.skyserver.org/htm/

http://www.sai.msu.su/~megera/oddmuse/index.cgi/SkyPixelization

http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=1992ASPC...25..379W&db_key=AST

Well, a couple of days back I noticed a nice feature (Plus Codes) in Google maps and immediately forwarded the screenshots and informed my friends to use it.

I checked again yesterday, it has disappeared..why what happened.

It would be nice if we could copy the code and send on social media messengers to locate our address.

With initial version of http://plus.codes demo site, it was possible to find out the plus code of one's own location, and find distance to a location given as a plus code. After the update, it is no longer possible. The site needs to be downloaded to use any functionality at all.

Passing values as strings instead of numbers will produce unexpected results, due to Javascript string handling.

The inputs (lat, lng, code length) should be coerced to numbers (using Number()) and if it produces NaN throw an exception.

While you're there, adding an exported constant for the code length e.g. OpenLocationCode.CODE_PRECISION_NORMAL and OpenLocationCode.CODE_PRECISION_EXTRA seems like a good idea.

The current Java implementation has a number of confusing code blocks that are hard to follow:

• The encoding method in the constructor
• The decode method is also confusing.

In addition, there other things to improve:

• Fixed values being used that should be constants: 20 (the number base), 5 & 4 (the refinement grid rows and columns), 10 (default length), 8 (position of separator), 90, 180, 360 etc.
• Use of the CHARACTER_TO_INDEX structure
• LATITUDE_PRECISION variables are misleading and unnecessary - latitude and longitude have the same precision, and the values are divided by 4 for some unexplained reason.

The only external dependency for the Go implementation is gopkg.in/inconshreveable/log15.v2.

This package should be updated to use only the standard library.

Links to gthub_.org_. Should be .com. I don't see that code in this repo, but would be nice if the owner of the demo site could fix that link.

The implementation is Apache Licensed which makes patents put on the code of the implemention transferred to the user (automatically), which is good but still not enough, I think but not sure :)

E.g. the costs for using the open location code itself is unclear to me. Can you point me to a license part that guarantees that using this code in e.g. competitive maps or routing services will be free for the provider and its customers? Or is it automatically assumed that the "data"/outcome of the algorithm is free for anyone?

The method of calling go-fuzz has changed slightly, and there is also no longer a separate corpus directory and flag. The 'corpus extraction' code should be moved behind a test flag instead of running at init().

cc: @tgulacsi

The rust setup added in #71 has broken the travis CI build process:

$ sudo apt-get -y install libstd-rust-1.16 libstd-rust-dev rustc cargo
Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Unable to locate package libstd-rust-1.16
E: Couldn't find any package by glob 'libstd-rust-1.16'
E: Couldn't find any package by regex 'libstd-rust-1.16
The command "sudo apt-get -y install libstd-rust-1.16 libstd-rust-dev rustc cargo" failed and exited with 100 during .

Floating point errors can cause incorrect code to generate. This depends on the language, but as an example we noticed that encoding latitude 1, longitude 1 produces an X for the 11th digit.

The 10 digit code latitude and longitude ranges are the same - 1.0 to 1.000125. In the 11 digit sub-grid, the characters are assigned as:

So for latitude 1.0, longitude 1.0 we want to get 2. But we are getting X.

This seems to be a problem in the encodeGrid functions where we try to work out which column the longitude is in by getting the remainder of dividing the longitude by the grid size (0.000125).

You can check this in Javascript by doing:
1.0 % 0.000125

It should be zero, but in my browser I'm seeing 0.00012499999999997919 which is nonsense.

Instead of directly comparing values in that function, we may need to use "close enough" comparisons, where if numbers are within 1E-10 of each other that's good enough.

Another strategy is instead of doing the remainder of 181.5 % 0.000125, we ditch the degrees and use 0.5 % 0.000125.

The solution in each case is probably language dependent.

How can an extension of open location code look with the elevation or a building level included?

E.g. if you want to meet it would be nice to know the building level of the room or if it is under or on a bridge :)

i have this error
Error:(21, 35) error: package com.google.openlocationcode does not exist

Given MQPX9G Nairobi, Kenya, one cannot recover the full OLC without a network connection or gazetteer. This breaks the design requirements to work offline.

Suggested is a "level 0" implementation describing only full OLCs with no gazetteer requirement, as could be encoded/decoded by an embedded device with no network access.

(Short codes are also culturally sensitive. 845R+3C Stanley, East Falkland and 845R+3C Puerto Argentino, Islas Malvinas are the same place to different people. Perhaps best to quietly drop the "global address" term.)

hi

    it is really good thing. and i try to put my html page.but it can't show anything then i check console also. it shows some key problem. even i download and try githup fie also. but, it is not work.