Added 2-digit ISO codes

[drwelby]

Added in the 2-digit ISO codes for those that need them under the key "id2".

[dungeontiger]

Thanks for including the ISO codes. I appreciate it!

[johan]

It might have made more sense to pick these iso 3166-1 alpha-2 (prominently used as country TLDs in dns) instead of the alpha-3 codes (maybe more known from, say, country stickers on cars) as the feature id and filename scheme. I unfortunately misremembered my ISO standards, conflating with the ISO 639 language codes, where the three-letter ones form a larger set than the two-letter ones.

Per the geo-json spec, however, "If a feature has a commonly used identifier, that identifier should be included as a member of the feature object with the name "id"" – whereas all additional secondary, tertiary and so on data should go in the properties object. I'll merge an updated version of this PR if you drop them in there (maybe named tld, alpha2, or indeed id2).

There's a Malta on master too now that wasn't in the set at the time of this PR, if you wonder about the merge failure.

[drwelby]

OK, I'll give some thought to the name and then move them into the properties.

[tttp]

@drwelby

Any issue you faced with moving the id to property?

I'd love to get it merged

[drwelby]

I moved the 2 digit code to "properties" under the key "alpha2". Didn't add Malta, though.

[Fil]

I would like to see also the numerical code. It's a small overhead, and it would make the feature set useable with any flavor of iso3166 coded data.

[Fil]

We could follow https://github.com/mledoze/countries and use:

• code ISO 3166-1 alpha-2 (cca2)
• code ISO 3166-1 numeric (ccn3)
• code ISO 3166-1 alpha-3 (cca3)

[johan]

@Fil, that sounds like a great idea. I'd totally merge a changeset that populates all the cca2 and ccn3 attributes to the properties object (mentioning https://github.com/mledoze/countries for proper attribution) – and maybe tld too if you like, where available. I have less resistance to adding in this type of easily verifiable constants than the type of data the CONTRIBUTING doc declines.

And, if any of the existing (code ISO 3166-1 alpha-3) id attributes (and, consequentially, filenames) are wrong, fixing those as well, for that matter. I don't think adding a duplicate cca3 property adds value, as I have never seen these acronym denominations for the iso-3166 properties before, but as they are totally practical, reusing the others seems good to me, as nobody in their right mind likes JSON attributes like code ISO 3166-1 numeric. :-) Props if you also add a little note to the README about the existence, meaning and source of this data, while at it.

[Fil]

I should have read CONTRIBUTING before :) Now I understand I will not use
this set. Thank you @johan for clarifying.

PS: this pull request page makes my browser explode, as it tries to display
a "diff" map for each changed file. I don't know if @github reads this
message, but they might need to fix this.