OLC specification doesn't strictly state validity status of codes with odd length <11

[bocops]

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.

[zongweil]

Adding @drinckes to consider modifying the spec.

[drinckes]

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]

@drinckes I'm not sure this is what currently happens, though. For example, in the Java implementation, there's the following check in isValidCode():

    if (separatorPosition % 2 != 0) {
      return false;
    }

// [then, later]

      // Only one character after separator is forbidden.
      if (code.length() == separatorPosition + 2) {
        return false;
      }

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]

I consider this fixed in https://github.com/google/open-location-code/pull/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]

specification.md states that

Below 10 digits, only even numbers are valid lengths.

and has done so at least since a "migration from description document" on April 21, 2019. Closing this as completed.