4 ms·

I think you misunderstood the way these reference locations work. Both google maps and bing will resolve the given plus code to the exact same location – a marg

I think you misunderstood the way these reference locations work. Both google maps and bing will resolve the given plus code to the exact same location – a margin of error of 0cm. It's only important that the reference point doesn't leave the 40km square that it's supposed to be in. Google Maps might actually have a smarter implementation than the docs suggest. If the whole city is in the relevant 40km square, using it as a reference point is fine.

londons_explore 8y ago
It would be nice for the code to have some kind of 'check digit', so that the code cannot resolve if the geocoding returns the wrong square, or if any letters are off-by-one or transposed. Check digits don't work well with truncatable codes though :-(
- jacobush 8y ago
  Why not? Every letter could be a check digit. The drawback is that the same location will have many possible location codes, of course.
  - kiriakasis 8y ago
    no, having check digits means that some code corresponds to no location and are syntactically wrong.
    - jacobush 8y ago
      I realize now I meant some kind of error correcting code, combination. Like this: 1 1 can be followed by either odd numbers or even numbers. If followed by an even number, the next number must be odd. 127 Now if you truncate that to 12, crucially 12 has the same meaning as 11. 1 and 2 to have the same symbol meaning, but are using "sign" to hint at the next number. This will greatly reduce the chance that a random number will pass for a position. This can be made more elaborate, with more or less advanced encodings. The problem is of course that you waste bits on redundancy and so addresses everything else being equal, will have more characters in them.
      - arghwhat 8y ago
        A much less expensive and much more normal solution would simply be to put a single CRC digit at the end. Systems such as what you describe are too complex and non-standard.
        jacobush 8y ago
        But then you can not truncate the location.
        arghwhat 8y ago
        I'd argue that this would never be done by hand anyway. The average user will not understand the encoding, and I doubt many will think "Hmm, I have this plus code, but I'd like to only have 1/20th of the precision." Programmatic truncation would still be very easy, as it would just require a new checksum to be calculated post-truncation.
arghwhat 8y ago
Yes, I misinterpreted the problem slightly. Rather than always being a problem, it is only a problem if there is uncertainty to which lat/long degree the location resides in. It appears to search for smaller and smaller features until it finds something that does not span multiple areas, while still being within the same area as the final location. For example, for a random address on Hawaii, the plus-code becomes "74FF+W7 Ocean View, Hawaii, USA", as Island of Hawai'i spands multiple lattitude degrees. However, this results in increasingly complex reference points, and I am not sure whether this can be done in a generic fashion. Of course, it may simply bail out to full codes at that point.

londons_explore 8y ago

It would be nice for the code to have some kind of 'check digit', so that the code cannot resolve if the geocoding returns the wrong square, or if any letters are off-by-one or transposed. Check digits don't work well with truncatable codes though :-(

jacobush 8y ago
Why not? Every letter could be a check digit. The drawback is that the same location will have many possible location codes, of course.
- kiriakasis 8y ago
  no, having check digits means that some code corresponds to no location and are syntactically wrong.
  - jacobush 8y ago
    I realize now I meant some kind of error correcting code, combination. Like this: 1 1 can be followed by either odd numbers or even numbers. If followed by an even number, the next number must be odd. 127 Now if you truncate that to 12, crucially 12 has the same meaning as 11. 1 and 2 to have the same symbol meaning, but are using "sign" to hint at the next number. This will greatly reduce the chance that a random number will pass for a position. This can be made more elaborate, with more or less advanced encodings. The problem is of course that you waste bits on redundancy and so addresses everything else being equal, will have more characters in them.
    - arghwhat 8y ago
      A much less expensive and much more normal solution would simply be to put a single CRC digit at the end. Systems such as what you describe are too complex and non-standard.
      - jacobush 8y ago
        But then you can not truncate the location.
        arghwhat 8y ago
        I'd argue that this would never be done by hand anyway. The average user will not understand the encoding, and I doubt many will think "Hmm, I have this plus code, but I'd like to only have 1/20th of the precision." Programmatic truncation would still be very easy, as it would just require a new checksum to be calculated post-truncation.

arghwhat 8y ago

Yes, I misinterpreted the problem slightly. Rather than always being a problem, it is only a problem if there is uncertainty to which lat/long degree the location resides in. It appears to search for smaller and smaller features until it finds something that does not span multiple areas, while still being within the same area as the final location. For example, for a random address on Hawaii, the plus-code becomes "74FF+W7 Ocean View, Hawaii, USA", as Island of Hawai'i spands multiple lattitude degrees. However, this results in increasingly complex reference points, and I am not sure whether this can be done in a generic fashion. Of course, it may simply bail out to full codes at that point.