Add branch offices data to the API - Local unit mapping

[geohacker]

This will involve:

• [ ] Inspecting the data @jhenshall @geohacker
• [ ] Create migrations for new models
• [ ] Management command for importing data from shp/csv
• [ ] API routes
• [ ] Test

@batpad @szabozoltan69 @thenav56 @tovari @LukeCaley

[geohacker]

The data looks ok but there are problems. Overall:

1. There are 2584 points
2. It's unclear what NS_Type, NS_SubType. These have several options that looks not very clean 1,2,3,4, some lat/lng values, IFRC etc

What attributes do we want to import?

1. Unique ID [ISO2]0001 - e.g NP0001
2. Country ISO (2 or 3)
3. National Society name
4. Branch name in local
5. Branch name in EN
6. Branch level (0-10)
7. Branch type name
8. Created timestamp
9. Last updated timestamp
10. Draft boolean (default false)
11. Validated boolean (default true)
12. Source? (NS, ICRC, Others?)
13. Address
14. Postcode
15. Telephone
16. Link (social)

[esario]

I have an up-to-date highly accurate dataset of Finnish RC branch data. The issue is that there's no point data, only polygons (branch polygons are comprised of 1-n zip code areas). I can compute centroids, but for attributes, there is no address and postcode data - appreciate any advice on how to tackle.

[geohacker]

@esario do you mind sharing that data with me? We can handle computing centroids during the import. For address and postcode, I'd suggest we leave them empty for now and then when you have it either go through the GO Admin to edit or reimport if that's too slow a process.

[geohacker]

To move forward on this, we decided in Kathmandu that we'd start with Ukraine data that looks reasonably complete.

[batpad]

cc @willemarcel here - it would be great if you could start looking at this. I think what we'd need roughly:

• [x] A new model for NSBranchOffice or so that would have a ForeignKey to Country and the attributes listed above (@geohacker please confirm)
• [x] Add API endpoints to LIST Branch offices, with some filters (perhaps just country for now), and GET details of a branch office.
• [x] Ensure that Admin interface to edit Branch offices work, including ability to move point on the map.
• [x] Import scripts to be able to import this data via a management command from a CSV or so (@geohacker can help with this).
• [x] Tests to cover the above.

@willemarcel let's catch up on this when possible - @geohacker can you add any clarifications, etc. to the above?

[tovari]

@willemarcel, would you mind adding the required, optional attribute naming of the import file to this ticket?

[szabozoltan69]

The "phone" field should be slightly bigger than 20. (In a recent load there were phone numbers which did not fit here.) Let's use 30 for it.

[szabozoltan69]

Deployed to Staging (increased phone-nr field).

[davidmuchatiza]

We have made a few changes to the Local Unit data dictionary and a few suggestions on how to deal with this dataset. For now, we are focusing on the main information table, which will form the global dataset. However, in the second version, we would explore having a unique local table for secondary information for each National Society, and this table will be primary based on the information provided by each NS during batch imports. Please see the attached files and the link to the UI done by YU. Local Units Data Dictionary - Copy.xlsx

So now as the next step, tomorrow will have a discussion with DFS and YU on the work to ingest the wireframes to staging and production.

[frozenhelium]

@tovari should we close this now?