[Improvement]: Rationalize boundary levels and translations

[ericboucher]

Provide a clear and concise description of what you want to happen.

I would like to revamp the way we define and boundary files and configure admin levels. The current implementation can be quite confusing and error-prone. A lot of things depend on having elements in the correct order, if the deployment is for a country or a multi-country, and so on (eg. c114761). Plus, it assumes that only one translation is available.

For now I am envisioning something like this but the goal of this issue is to dive in and come up with something scalable that simplifies the code.
While we're at it, we should consider simplifying the logic of loading/unloading admin boundaries and simply playing with their visibility instead. The primary boundary layer should always be used for calculations and everything, but could be "hidden" if a sublevel is used.

admin_boundary: {
	...
	adminLevels: {
	0: {
		name: "country",
		idField: "admin0Pcod",
		nameField: "admin0Name",
		translation: {
			fr: {name: "pays", nameField: "admin0FRName"}
			fr: {name: "paga", nameField: "admin0ESName"}
		}
	}
}

Thoughs @wadhwamatic @laurentS ?

Is there anything else you can add about the proposal? You might want to link to related issues here, if you haven't already.

No response

[laurentS]

I haven't touched this code in a while now, but I do agree with the error-prone aspect of it. I just opened a random config file and it is true that admin_boundaries followed by admin1_boundaries doesn't convey obvious meaning. What you're suggesting above already looks like an improvement.

My gut reaction would be to define a data format that removes the implicit/guesswork out of it, then define strong types around it (so no string, but unambiguous types like AdminLevelName, etc...) so that LSPs can provide real support, and typescript won't compile broken code.
I think it should be possible to write some sort of accessor class around this, so that the clunky logic in the commit you linked to is all encapsulated in it, and the rest of the code uses nicely named methods. This should also make it much easier to test this code to ensure it work across countries.

There is a number of tickets in github that revolve around this issue (#993, #307, #604, #994, ...), linking them here to help triaging (hopefully).

[wadhwamatic]

@ericboucher - the configuration of levels for chart_data should also be revisited. Right now, we depend on configuration in layers.json for each chart / layer but the same information could be specified here. I.e., in addition to idField, we could have chartIdField. They are unfortunately unique because of WFP's messy admin ID management.

[ericboucher]

Linked to #360 and #451 and #1248

[ericboucher]

The logic behind getDisplayBoundaryLayers seems a bit overkill now

[wadhwamatic]

As mentioned in PR #1163, we should leverage the name attribute here in the selection list of admin levels for running an analysis.