Repository navigation
OLC specification doesn't strictly state validity status of codes with odd length <11 #196
Description
Referring to the OLC specification here: https://github.com/google/open-location-code/blob/master/docs/olc_definition.adoc
A question about codes with odd length <11 has been brought up here: https://groups.google.com/forum/?pli=1#!topic/open-location-code/IGhD6rc2EsQ
I wanted to reply that these codes are considered invalid via the OLC specification - because that is how the implementations handle this - but to my surprise, this is actually undefined:
(7) states how "up to 10" characters are encoded, but doesn't state that they need to be encoded in pairs.
(8) states that codes beyond 10 characters can be of odd length - but not that shorter codes cannot.
(9) states that OLC "with even numbered lengths of 10 digits or less have the same height and width in degrees" - but not that odd numbered lengths are considered invalid.
I suggest to insert the following as specification 2.a:
2. a Open Location Codes with less than eleven digits excluding "+" must be of even length. They must be rejected as invalid otherwise.
Activity
zongweil commentedon Oct 5, 2018
Adding @drinckes to consider modifying the spec.
drinckes commentedon Nov 15, 2018
My general feeling is that implementations should not create codes with 1,3,5,7 or 9 digits, but if given one they should decode it: Be conservative in what you do, be liberal in what you accept from others.
I'm open to a discussion though.
bocops commentedon Nov 15, 2018
@drinckes I'm not sure this is what currently happens, though. For example, in the Java implementation, there's the following check in isValidCode():
isValidCode() is called when trying to create an OLC instance from a string (which is a prerequisite for even the static decode() method to work), so it currently shouldn't be possible to decode a, say, 9-digit plus code in Java.
I'm not sure about situations where this might happen, either. If, say, 7-digit plus codes are not something that any implementation should generate in the first place, the only way something like "2345678+" could happen is by dropping a digit when communicating a plus code from person to person or when entering it manually.
In that case, we can't be sure if the original code was "23[X]45678+" or "2345678[X]+", so assuming one or the other might lead to wildly different decoded locations.
fulldecent commentedon Jun 4, 2021
I consider this fixed in #463
The specification states that "Plus codes MUST use one of these code lengths..." and there is no specification that implementations MUST reject invalid Plus Codes.
bocops commentedon Oct 6, 2022
specification.md states that
and has done so at least since a "migration from description document" on April 21, 2019. Closing this as completed.