Remove ORG_CURIE_TO_MAPIT_AREA_TYPE mapping

[chris48s]

We have a script called import_divisionsets_from_csv.py
which imports divisionsets
from a csv

https://github.com/DemocracyClub/EveryElection/blob/master/every_election/apps/organisations/management/commands/import_divisionsets_from_csv.py

Our CSV contains a 3-letter local authority code.
One of the things this script does is it attempts to look up our area in this big dict

EveryElection/every_election/apps/organisations/constants.py

Line 197 in ef22b5a

ORG_CURIE_TO_MAPIT_AREA_TYPE = {

to work out what sort of organisation it is.

The reason we want to know this is so that we can then look that up in

EveryElection/every_election/apps/organisations/constants.py

Lines 1 to 11 in ef22b5a

	PARENT_TO_CHILD_AREAS = {
	"DIS": ["DIW"],
	"MTD": ["MTW"],
	"CTY": ["CED"],
	"LBO": ["LBW"],
	"CED": ["CPC"],
	"UTA": ["UTW", "UTE"],
	"NIA": ["NIE"],
	"COI": ["COP"],
	"LGD": ["LGE"],
	}

to work out what sort of divisions we're importing.

There are 2 problems with this:

1. Because our organisations are primarily defined in the DB but this lookup is defined in code, every time we add an organisation to our DB, we also have to edit the code. This is a bit silly.
2. In the case where the organisation is a UTA, its sub-divisions can be either UTW or UTE. We have no way to know which, so we just pick UTW The most common case is UTW but this means we are sometimes wrong. There are probably a handful of areas where we have assigned divisions UTW when they should be UTE. This will probably surface when we look at back-porting GSS codes onto areas and we'll need to fix it.

I suggest that we should move to storing this in the DB. We need to define 2 fields. One to store the area code for the organisation itself, and another to store the area code that child divisions of this organisation have (lets call them boundaryline_area_code and boundaryline_children_area_code). I think you could make an argument for either putting this on the Organisation model itself or on the OrganisationGeography. Both fields need to allow blank values because not every single Organisation object will have one of these codes. Most will but not all. To avoid duplication, I think we can also say we should only populate boundaryline_children_area_code when boundaryline_area_code is UTA (i.e: there is not a one-to-one mapping) and just defer to looking the others up based on a mapping:

PARENT_TO_CHILD_AREAS = {
    "DIS": "DIW",
    "MTD": "MTW",
    "CTY": "CED",
    "LBO": "LBW",
    "CED": "CPC",
    "NIA": "NIE",
    "COI": "COP",
    "LGD": "LGE",
}

So then this job is going to break down into the following tasks:

• Add boundaryline_area_code, boundaryline_children_area_code to model
• Write a data migration to populate boundaryline_area_code based on

  EveryElection/every_election/apps/organisations/constants.py

  Line 197 in ef22b5a

  ORG_CURIE_TO_MAPIT_AREA_TYPE = {

• Ad hoc task to look at areas with a blank boundaryline_area_code and work out what to do with them. Some will be validly blank and there will be some we need to fix
• Ad hoc task to correctly populate boundaryline_children_area_code with UTW or UTE for any unitary authorities
• Update https://github.com/DemocracyClub/EveryElection/blob/master/every_election/apps/organisations/management/commands/import_divisionsets_from_csv.py to account for our changes
• Delete redundant code from https://github.com/DemocracyClub/EveryElection/blob/master/every_election/apps/organisations/constants.py