3 ms·

> That's only a partial plus-code, though, which relies on external positioning of Honolulu. Yes, a concept that is very human-friendly. > Also, that particul

> That's only a partial plus-code, though, which relies on external positioning of Honolulu. Yes, a concept that is very human-friendly. > Also, that particular plus-code you used as example is not recommended. Reference points should be small features that will have low geocoding variance. Larger points like cities, or here whole islands, as there can be very large variance to the exact location derived from the name (i.e. the pinpoint location Google Maps finds you when you just search for Honolulu). You should take that up with the google devs I guess. The code I gave was generated by google maps.

arghwhat 8y ago
> Yes, a concept that is very human-friendly. It's also entirely broken, rendering the system unusable if you expect sub-kilometer positioning across different geocoding providers. Whether something entirely defective is "human friendly" doesn't really matter. > You should take that up with the google devs I guess. The code I gave was generated by google maps. Not my responsibility. That they cannot even use it correctly as per their own docs themselves doesn't make for a good sales pitch. In fact, Google Maps cannot process plus codes using arbitrary reference locations, making use per the plus-code documentation impossible with it. To give an idea of why that plus code is borked: Honolulu @ Google Maps: 21.3069444,-157.8583333 Honolulu @ Bing Maps: 21.30493,-157.85788 The difference is around 300 meters, which results in an absolutely awful error margin, and I'd argue that this is very much one of the best-case scenarios. That's worse than if they had added 2 more characters to the plus code, and just removed the Honolulu part.
- chronial 8y ago
  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.
scatters 8y ago
The problem I have is that the reference points do not respect natural or human boundaries. Around where I live, the reference points Google Maps give are variously an adjacent town (the other side of a major river!) and a small housing estate which no-one living outside that estate will be aware of. If Google want people to use this system, they need to give a choice of reference points.

arghwhat 8y ago

> Yes, a concept that is very human-friendly. It's also entirely broken, rendering the system unusable if you expect sub-kilometer positioning across different geocoding providers. Whether something entirely defective is "human friendly" doesn't really matter. > You should take that up with the google devs I guess. The code I gave was generated by google maps. Not my responsibility. That they cannot even use it correctly as per their own docs themselves doesn't make for a good sales pitch. In fact, Google Maps cannot process plus codes using arbitrary reference locations, making use per the plus-code documentation impossible with it. To give an idea of why that plus code is borked: Honolulu @ Google Maps: 21.3069444,-157.8583333 Honolulu @ Bing Maps: 21.30493,-157.85788 The difference is around 300 meters, which results in an absolutely awful error margin, and I'd argue that this is very much one of the best-case scenarios. That's worse than if they had added 2 more characters to the plus code, and just removed the Honolulu part.

chronial 8y ago
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.

scatters 8y ago

The problem I have is that the reference points do not respect natural or human boundaries. Around where I live, the reference points Google Maps give are variously an adjacent town (the other side of a major river!) and a small housing estate which no-one living outside that estate will be aware of. If Google want people to use this system, they need to give a choice of reference points.