[Alupis]

Hmm, I just took a look at their Java SDK... (clearly just sample code, but intended for embedding into your project to get going quickly)

They make a lot of assumptions, and a lot of hard-coded values.

For example, they seem to have lots of city names and country names hard-coded into a giant String array. ISO country codes are hard-coded (probably a safe assumption so-long as new countries are not added), many "magic numbers".

Overall, I think these things are acceptable... but I don't necessarily like relying on the assumptions that "things today should be the same tomorrow". With plain old coordinates, my software would never care if the ISO added new country codes or what-have-you.

I see they intent this to be mainly for human consumption -- but is US-AK 81.J4W really any more memorable than 52.508957, 4.769173? I'd probably end up writing both down personally, which means the coordinates would suit me just fine.

[frankus]

81.JW4 is a lot easier to tell someone over the phone or transcribe from a business card or billboard, and it's pretty unlikely that the US-AK part would be ambiguous in those contexts. And if it is, a simple "which 81.JW4 did you mean?" would probably disambiguate pretty effectively.

[Alupis]

Well, phonetically, pure numbers are better.

It's much harder to hear "eight" and mistake it for another number, but "P" and "T" are commonly confused (presumably people would read it as "Papa" and "Tango" to avoid confusion). What about "O" and "0", "I", "l", "1", etc. Now we have ambiguities that may not be interpreted correctly, even with phonetics.

[frankus]

FWIW they left O and I out of the list of possible letters for just that reason.

One could argue either way about fully-numeric versus alphanumeric codes. They're a bit harder to communicate but more than three times shorter, on average.

Edit: math is hard. One and a half times shorter, on average.