Which EMIKAT-generated resources do we need to include in the screening Data Package(s)?

[DenoBeno]

This is related to #18 and clarity-h2020/csis#91
Also related to: #45, #46, #47, #49

Issue at hand: if I understand our application model correctly, we have to list all the EMIKAT results as ressources with EMIKAT-specific variables in the URIs in the Data Packages that will be used for screening. Otherwise CSIS will not be able to visualize them.

@p-a-s-c-a-l , @helllth : is this correct/is this the way to go or not?

One example of such a resource is the "population density within the EU-wide data package (see https://csis.myclimateservice.eu/node/682 and https://csis.myclimateservice.eu/node/754)

@humerh: Which other resources is EMIKAT producing (or will produce) that need to be listed in this ? Impact tables? Impact maps? Impact tables and maps with adaptation options applied (in development/future)? Other? What are the links that need to be added?

Alternatively, we could produce special "screening" versions of the embedded applications that know what needs to be done. This would make it easier to produce screening data packages, but we would have to invest more in javascript application developments.

@p-a-s-c-a-l , @helllth : which way should we go in your opinion?

Any other issues that you are aware of, or ideas how to handle this?

[DenoBeno]

This is pretty much a showstopper IMO. We have to resolve this in order to produce screening results.

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

I want to keep everything as it is now! That is, no special apps for screening. Our current apps will replace EMIKAT variables like $emikat_id in resource URIs with values obtained from concrete studies.

This works and is implemented in the new map component. So there is no need for further action here.

ATM deployment of the new map component is delay until clarity-h2020/csis-helpers-module#10 is implemented.

[DenoBeno]

OK, but I presume that we still miss some resources in the data package ATM. E.g., there are no resources corresponding to EMIKAT impact calculation in the data package atm. Or are they?

[DenoBeno]

OK, I have just discussed this with Heinrich, and we have defined a second EMIKAT-generated data layer for the european data package:

https://csis.myclimateservice.eu/node/1272

This is based on the information in the wiki: https://github.com/clarity-h2020/csis/wiki/Services-endpoints-(used-by-CSIS)

etc.

As you can see, there is a whole lot of variables in this resource file. E.g.:

https://service.emikat.at/geoserver/clarity/wms?service=WMS&version=1.1.0&request=GetMap&layers=clarity%3Aview.2974&bbox=4672000.0%2C1979500.0%2C4687500.0%2C1988000.0&width=768&height=421&srs=EPSG%3A3035&format=image%2Fgif&CQL_FILTER=PROJECT%3D**$emikat_variant**%20and%20PERIOD=%27**$emikat_period**%27%20AND%20RCP=%27**$emikat_rcp**%27%20AND%20FREQUENCE=%27**$emikat_frequency**%27%20AND%20SZ_ID=**$emikat_id**&styles=T_A

See the wiki page for explanation of possible values for each of the variables.

An alternative would be to produce a ressource fiel for all combinations of the parameters, but this would be completely a nightmare to maintain.

How to proceed with this?

[DenoBeno]

The third resource produced by emikat is the "Impact Calculation (Mortality) for each Scenario, Time period, typical Events and for each Adaptation Project", also described in the wiki. Will require the same variables.

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

Following steps are required to make this work:

1. Variables have to be stored in the study or gl_step entity -> somebody has to extend the data models
2. variables are made available as JavaScript variables -> somebody has to extend the csis_helpers_module (see Include additional info in $entityinfo csis-helpers-module#10)
3. variables are supplied by the users => somebody has to implement a use interface for this (see Scenario Selection UI docker-drupal#58)
4. variables are evaluated by the map / table component to generate the parametrised EMIKAT URIs =>CIS has to extend Table and Map Components

[DenoBeno]

OK, I had some house-internal discussion on how to get this started and here is one idea for discussion:

1. Variable names should not be $name but rather ${name} (shell notation) or {{name}}/{{ name }} (twig notation, spaces are ignored) or such - something that's easier to parse. I don't really care what, but with $name it's difficult because it's not so clear where it ends. And having variables called $name and $name2 would cause havoc. (thanks Heinrich)
2. With exception of the emikat_id, other variables should not have emikat in name. So maybe we should call them csis_something or CSIS_something. Or even drop the "csis" part.
3. Hard-coding the possible variable values in the CSIS or in javascript viewers is a particularly bad idea. E.g., maybe some resource allow {{ RCP }} as a variable, but provides the data only for "baseline" and "rcp45" scenarios.

So, I would propose to add a taxonomy of possible variable/value combinations to the system. This taxonomy would have the following fields:

• Title: automatically generated form field_var_name and field_var_value
• field_var_name: one from a list of supported variables, e.g. RCP, frequency,
• field_var_value: free text

Example:

• Title: RCP: rcp45
• field_var_name: RCP
• field_var_value: rcp45

If necessary, we can adopt some naming convention so that e.g. ranges of allowed of values can be indicated too. E.g. RANGE(2020;2050;10). I would rather hope that we don't need this, but it's possible to do if and when needed, so the concept sounds OK to me.

Once such taxonomy exists, we could add "Allowed variable values" field that point to this taxonomy and let the owner of the ressource indicate which variable values are valid with their ressource by linking all the relevant ones with the resource.

Thus, the EMIKAT resource listed above would have a following list included:

• period: baseline (which is?)
• period: 2011-2040 (or 20110101-20401231?)
• period: 2041-2070
• ...
• RCP: baseline
• RCP: rcp26
• RCP: rcp45
  etc.

I'm not sure what to do with "emikat_id" and the "project" variables that do not have a pre-set range of allowed values. Maybe something like this, to indicate that the allowed values will be defined in the project?

• emikat_id:$project_emikat_id
• project: BASELINE
• project: $project_variant

Questions:

1. Should we follow up on this or do you have a better idea how to do it?
2. which variable naming convention to use?

[DenoBeno]

For example, we could use of twig notation {{ }}, and to name the variables in the following way:

• project specific ones with project prefix. E.g. {{ project_emikat_id }}, {{ project_variant }}
• resource specific ones with no prefix or with csis prefix. E.g. {{ rpc }} or {{ csis_rpc }}
• capitalization: ignore capitalization or all lowercase if this isn't an option. So either we only use rpc or we consider {{ RPC }} and {{ rpc }} to be the same.

[DenoBeno]

@p-a-s-c-a-l : this would obviously be just a first step. Once we do have this information, the site functionality would have to be redesigned to use it as you already indicated. In the meantime:

• everything that doesn't use the variables should continue working as it does now in the meantime
• resources that do use these variables would only work in the parts of the site where a change has been implemented...

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

Let me finish the 1st map and table that work with the already available $emikat_id and then we can continue the discussion.

[DenoBeno]

Unless Pascal has some serious issues with this, I second the "New_2" approach.

This means that we need to support the following variables, and that all variables will need to be written as ${variable_name} in the URIs:

Just for EMIKAT resources

• emikat_id

Mostly for EMIKAT resources, possibly other:

• study_variant
• time_period (personally I find this tautology but don't care too much. Maybe period_covered or simply period would be better)
• emission_scenario (singular emission, not emissions. Or simply "rpc")
• frequency

For the sake of typing less, we could go for "period", "rpc" and "frequency".

[patrickkaleta]

For the sake of typing less, we could go for "period", "rpc" and "frequency".

No, we discussed that today in our telco and decided to use "emissions_scenario" instead of "rcp" etc, because that's how we named it in the data package (and probably other places) and we want to use consistent names for describing the same things to minimize confusion.

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

Thanks @humerh , I would rename frequency to event_ frequency. So the final set of variables would look like:

Filter	Variable	Alternatives
EMIKAT_ID	${emikat_id}	n/a
STUDY_VARIANT	${study_variant}	'BASELINE', 'ADAPTATION'
TIME_PERIOD	${time_period}	'20110101-20401231', '20410101-20701231', '20710101-21001231
EMISSIONS_SCENARIO	${emissions_scenario}	'Baseline', 'rcp26', 'rcp45', 'rcp85'
EVENT FREQUENCY	${event_frequency}	'Rare', 'Occassional', 'Frequent'

[DenoBeno]

OK, passt

[DenoBeno]

I am starting the work on the following, should be finished later today:

1. taxonomy of allowed variable values. This will connect emission_scenario with three possible values rpc26/45/85 and so on
2. possibility to state which of these values are applicable for a resource. This is "yet another tagging", I can just extend the existing tagging mechanism by adding a possibility to tag by yet another taxonomy. WDYT?

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

2. adding a possibility to tag by yet another taxonomy

yes, that's o.k.

[DenoBeno]

Question: what to do with free numbers?

1. For EMIKAT, I have indicated "[0-9]+" as allowed value
2. for the study variant, I could define ADAPTATION-01, and later ADAPTATION-02, 03 etc - as we need it. I suppose we will never have more than a handful of variants in a study. Alternatively, I could define a generic 'ADAPTATION-[0-9][0-9]'. WDYT?

[DenoBeno]

What does 'Rare', 'Occassional', 'Frequent' mean?

[DenoBeno]

Taxonomy defined. Just missing the description for the three event frequency items

[DenoBeno]

Done. Tested for a simple case of https://csis.myclimateservice.eu/node/754

[DenoBeno]

According to https://github.com/clarity-h2020/csis/wiki/Services-endpoints-(used-by-CSIS), EMIKAT also differenciates between styles=T_A for Apparent temperature, styles=T_TMRT for Mean Radiant Temperature and styles=T_UTCI for UTCI Temperature

Do we need this as a variable too?

[humerh]

No, I think not, as these are different Parameters with different Semantics. How do you handle this with other data Source, where the data source contains more than one Parameter? We can implement also 3 ressources.

[DenoBeno]

@humerh : this is the first time that we have introduced the variables. Please see #45 and #46 for the first trials that I have implemented now.

[DenoBeno]

Related to #42, #45, #46, #47, #49

We have defined three resources that are generated by EMIKAT and that use variables now. I am aware that we still need to add two more "local heat" resources because styles can have three values (T_A|T_TMRT|T_UTCI). That would be five "EMIKAT" resources.

@humerh: is this all (as long as we don't have flooding hazard/vulnerability/impact), or are we still missing something?

[DenoBeno]

From today's telco I understood that we are missing some resources that are generated by EMIKAT. Which ones?

[DenoBeno]

I can see that EMIKAT is building views with IDs 2955, 2974, 2975, 2994 and 2995 now.

@humerh : Last two are not documented on the wiki, what do they do?

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

From today's telco I understood that we are missing some resources that are generated by EMIKAT. Which ones?

The answer should be somewhere in here. here or here. IMHO mortality rates and azimuth are either missing or already part of another resource.

[DenoBeno]

From today's telco I understood that we are missing some resources that are generated by EMIKAT. Which ones?

The answer should be somewhere in here. here or here. IMHO mortality rates and azimuth are either missing or already part of another resource.

2955, 2974, 2975, 2994 and 2995 do not appear on the linked pages.

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

IMHO this can be closed.