Adaptation options in drupal usable for local model(s)?

[DenoBeno]

I have just re-designed the way adaptation options work. As a result, there are three items there that could be useful for (simple) adaptation effect modeling.

1. First, there is the "vulnerability change" indicator. This indicates how important a change in vulnerability can be effectuated by this Adaptation Option. It's a number between -3 and +3, with - indicating that the vulnerability diminishes and + that it augments.
2. second, there is a link to "local hazards change" taxonomy. Each taxonomy term has a name, description, related hazard, value and unit. value & unit fields might be useful for effect modeling.

3. Third, there is a link to LocalEffectsParameters taxonomy. Same data model, except that there is no link to a hazard. This are the parameters PLINIUS has been working on.

I have also redesigned the adaptation options edit mode so that this can be easily used. General idea is that one could parametrise the effects on local parameters (e.g. albedo) or even the effects on local hazards (e.g. extreme heat), for a couple of typical cases (slight/medium/strong effect) and then assign these to the various adaptation options. then model just needs to read the parameters and applies them.

[DenoBeno]

i would like to assign this to someone from PLINIUS so that they can comment on it, but I can't find them...

See e.g. https://csis.myclimateservice.eu/node/553 for an example of how this could be used. This should work if someone parametrize defines the terms and parametrises the values in https://csis.myclimateservice.eu/admin/structure/taxonomy/manage/local_hazard_change/overview and in https://csis.myclimateservice.eu/admin/structure/taxonomy/manage/localeffectsparameters/overview

WDYT?

[p-a-s-c-a-l]

As discussed with @humerh we will only be able to change the land use distribution / land use classes / local effects parameters of the local effects input layers and then re-recalculate the local effects hazards. So ATM we should focus on the LocalEffectsParameters.

These are the parameters currently defined in the local effects model obtained from EMIKAT API:

ROW ID	PARAMETER
3	"HILLSHADE_BUILDING"
4	"HILLSHADE_GREEN"
5	"T_SURFACE_DELTA"
6	"EMISSIVITY_SURFACE"
7	"EMISSIVITY_WALL"
8	"EMISSIVITY_SKY_DELTA"
9	"EMISSIVITY_SKY_TA_FACT"
10	"SHADOW_VEGETATION"
11	"SHADOW_BUILDING"
12	"ALBEDO"
13	"TRANSMISSIVITY"

We should add these parameters as taxonomy and in the adaptation options the percentage of change. For the respective taxonomy, we would need a description, of course. So what we are still missing is how does a particular adaptation option change these parameters?

Until we know that, we should introduce a number of meaningful common "generic" adaptation Options: e.g. ALBEDO+25%, ALBEDO+50%, SHADOW_VEGETATION+25%, etc.

[DenoBeno]

As discussed, this type of "simple" adaptation options are possible already. E.g., "apply roof paint with low albedo" that has just one effect (just one used by the model at least), which is "set albedo to 0.2".

However, the taxonomy must indeed include the "emikat parameter id" or "csis parameter id" parameter, which could be a list or a taxonomy. Guess a list is enough.

In addition, Heinrich needs to know to which layer the adaptation option is applicable. This is another list or taxonomy and this value must be associated with the adaptation option.

[DenoBeno]

I forgot to mention that it's possible to indicate which adaptation options are available in a data package. Thus, it doesn't matter if some options exist that we can't use in screening - these will not be included in the screening package.

[DenoBeno]

I have added the local effects parameters from emikat to the taxonomy, see https://csis.myclimateservice.eu/admin/structure/taxonomy/manage/localeffectsparameters/overview/fields/taxonomy_term.localeffectsparameters.field_le_parameter/storage

[humerh]

This is the list to the defined "land usage" layers in EMIKAT:

https://service.emikat.at/EmiKatTst/api/scenarios/2846/feature/tab.CLY_LAYER_DEF.1837/table/data?rownum=1000

[DenoBeno]

Implemented. If you encounter any issues, please yell but I'm considering this done as far as technical implementation is concerned.

Now it's up to:

1. someone from PLINIUS (?) to configure this in a reasonable way. @RobAndGo , who should we put this on?
2. @humerh to make use of this and up to