Align district codes with OCHA p-codes

[jhenshall]

Issue

OCHA maintains Common Operational Datasets (CODs), which are available through HDX and are the 'authoritative reference datasets' for admin boundaries and their unique p-codes, which are essential when joining datasets.

The district codes on GO come from the ICRC shapefile and in many cases do not align with OCHA's p-codes (e.g. as commented here). This could limit the potential for using GO data in operations when joining by district is necessary.

What next

It would be a significant piece of work to address this issue on GO - so I'm capturing here for future discussion. Initial thoughts / options:

• Discuss with ICRC whether OCHA standards could be used on their dataset
• Default to instead using OCHA CODs for Admin1 on GO where available
• Mapping our existing codes to OCHA's and storing both in the database
• We just accept that they are different because we have to use RCRC approved boundaries?

This will open up a lot of considerations of how else the ICRC data differs from OCHA - including geometries and naming. Any option would have to be taken with continued maintenance in mind.

[JonathanGarro]

Notes from my conversation with Simon Johnson and @jhenshall on 2021-08-06:

GO currently uses ICRC p-codes which leads to interoperability issues with partners like OCHA. Johnny is already engaged with them on this issue, citing three key decision gates:

ICRC and IFRC need to agree on a data model There needs to be an owner identified (or some other governance structure) as it is currently dealt with via ICRC volunteers (e.g. there is a clunky/cumbersome process of clicking around Google maps to find branch locations to convert them to x,y coordinates - this should be data collected and shared by the NS directly, and support is likely necessary to help with this outside of any GO engagement). Need to have a clear argument to communicate with NS about the value of p-code data. Simon sees two scenarios when addressing this issue:

Best case: ICRC adopts UN P-codes for most countries (exceptions will exist in places like Palestine, and in those cases the gap will need to still be filled by ICRC). Minimum viable solution: A lookup table that merges the two datasets, defaulting to UN and falling back to ICRC. A fuzzy matching system would help with issues that arise from translating place names from different alphabets like Cyrillic or Arabic).

[nanometrenat]

How does this fit with the recent work done on admins 1 & 2? What is current thinking?

[nanometrenat]

Closing based on David's comment in "Ticket time" - work done under https://github.com/IFRCGo/go-api/issues/1882 is to address this issue