Common configuration for WFP open data cube layers

[wadhwamatic]

We have a number of countries that will use a common set of layers that are accessed through WFP's open data cube instance as WMS layers. Currently, any change to a color ramp, legend text, etc. has to be made for each individual PRISM instance.

Is there a way we can have these common configurations read from a single source so that we can ensure they are always in-sync and avoid errors in repeatedly updating them for each instance? If not a software solution, any suggestions on a file management solution to make this more efficient? Any thoughts @ericboucher?

[reed1]

@wadhwamatic I tried to create common configuration on src/config/shared/layers.json. The file will be referenced by country specific config. Now the layers.json files are smaller because of the shared layers. You can see it on feature/shared-config.

There are many config changes, I wrote a small script for that. The result is here:

summary-changes.txt

Basically, for each country it will show:

• matches: The shared layers that will be used
• modifies: Shared layers that will be used but then there are some changes or additional attributes like "additional_query_params" or "chart_data" or "content_path", etc.
• unique_layers: ODC layers that are not referenced by any other countries. Those layers won't be taken to shared/layers.json file
• renames: Shared layers that have the same URL but different layer id, usually because old naming. For example "rain_anomaly_monthly" (old name) will be changed to "rain_anomaly_1month" (new name in shared layers)
• unused: Showing layer ids registered in layers.json but not referenced in prism.json, probably old layers that are not used anymore

For now, the src/config/<country>/index.ts will have repeated layer merge code for each country, the function cannot be extracted because of strict typing on layers.json. I think with generics it would be possible, but I haven't tried much. Also if we want to make extending shared layers mandatory, this can be simplified, the merge code will only be needed on config/index.ts. But I don't think that's a good idea either.

Please review, if it's good, I can make a PR for feature/shared-config branch.

[wadhwamatic]

Thanks for the work on this @reed1. I would suggest that we remove admin_boundaries and wp_pop_cicunadj from the shared layers file. We may later reintroduce wp_pop_cicunadj since the way we deploy that layer might change.

I'd like to have @ericboucher review how this is implemented, especially the changes to country-level index.ts files. I'm not sure about adding the modifiedLayers logic there.

Please create a PR based on the feature/shared-config branch.

[wadhwamatic]

@ericboucher - surfacing this again as part of the potential work on simplifying layer configuration