|
|
|
|
|
by lstamour
4353 days ago
|
|
Goal #3 on their list was: > A conversion need not just be based on formulae. A respectable amount of data may be used as part of an algorithm. Which is why when you go to the downloads page, you'll find sources in C, JavaScript and Java, but they all include "data tables". There are a few other restrictions, though it's somewhat unclear how relevant they are here without inspecting the tables closer: > One such limit is to use only rectangular areas in our definitions. Another is to limit the size of the “context” data table to about 16,000 records. So it's not something you can do without the data tables. And for ease of use, they have disambiguation routines for country/state input. |
|
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.