Use standardized official country codes

[aoles]

It would streamline certain workflows if the APIs could be queried using standardized country codes, such as ISO 3166-1 alpha-2 instead of the ORS-specific(?) numeric ids listed in https://github.com/GIScience/openrouteservice-docs#country-list.

This doesn't need to be a breaking change because ISO_3166-1 codes can be easily distinguished from the current numeric ids, so the API could allow either.

Note that ISO 3166-1 country codes are already used by Pelias gecoder.

[MichaelsJP]

country_codes.csv.txt

[TimMcCauley]

Afaik there is a reason why we use our own, @rabidllama can you elaborate?

[rabidllama]

the main reason was to do with storage space on the graph. It shouldn't be a big thing to change to use country codes, but it would increase the storage (currently it uses I believe 6 bytes, and using a two character country code to store would be 12 bytes per edge). Generally I think that the storage is much more optimised for numerics as then you can do bit shifting to shorten the amount of space needed (which currently hasn't been implemented). The numbers used are a bit arbitary and so yes, country codes would make it easier to understand and identify, but we need to consider whether we store the country codes on the graph itself or if we have a hybrid solution where the codes are mapped to numerical values.

[TimMcCauley]

Thanks for explaining, considering this closed, we have plenty of other things to dig into

[rabidllama]

I am reopening this now as we have resources to look into it.

@takb the api should still work with numbers when finished, but also allow the country codes.

[aoles]

I am reopening this now as we have resources to look into it.

That's awesome news, thanks @takb for picking up on this! Are you going to implement ISO 3166-1 alpha-2 country codes, or some other standard?

[takb]

I was thinking alpha-2 and maybe alpha-3 additionally

[nilsnolde]

+1 for both

[takb]

The code changes won't break anything, but also won't work until you also load the updated CSV file from the gitlab repo openrouteservice-infrastructure/core-deployment. The updated CSV file won't work unless PR 390 is pulled.

[rabidllama]

Will close this when it is put into the master branch