Support for additional processing variables

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

Support for additional processing variables

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

Once clarity-h2020/csis#101 has been implemented, we need to include study_variant, time_period, emission_scenario and event_frequencyin the csisHelpers.studyInfo JS Object.

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

Not sure if this changed lately, but the study_presets contain wrong values: e.g. instead of "scenario:historial" EMIKAT expects "Baseline" as value for emissions_scenario:

Here is documented what is expected by the table and map applications.

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

O.K., I tried to revolve this in branch feature/010-extend-entityinfo by accessing field_var_valueinstead of field_var_meaning, but this didn't work:

The website encountered an unexpected error. Please try again later.</br></br><em class="placeholder">InvalidArgumentException</em>: Field field_var_value is unknown. in <em class="placeholder">Drupal\Core\Entity\ContentEntityBase-&gt;getTranslatedField()</em> (line <em class="placeholder">587</em> of <em class="placeholder">core/lib/Drupal/Core/Entity/ContentEntityBase.php</em>).

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

Another thing we need in 'study_info' is 'field_eea_city_profile_name' from the Cities/Regions Taxonomy. Maybe @patrickkaleta can add this, too?

[DenoBeno]

Do you mean the "scenario:historical" and such?

If yes, this is a very simple thing to fix. Or at least to work around until we do something better. Let me explain:

We have two taxonomies governing the issue at hand: "DP variable meanings" and "DP variables"

DP variables is used in the ressource tags, whereas the DP variables meanings is used in study to indicate which combinations the user wants. Why two and not one? Because EMIKAT uses the "Baseline" where our hazard packages use the "historical" and we need some way to map this to one other.

Thus, the workaround is simply to replace the value of "meaning ID" variable in DP variables meanings taxonomy so that it's the same as the "variable value" in DP variables. I'll do this now and then your applications will get what they need.

TODO later
One day when we start doing this for non-emikat resources, we'll have to deal with the issue of synonyms. In one way or another, the helpers modules wil lhave to signal that emission scenario can be either "Baseline" or "historical" and the apps will ahve to parse the resource tags to find out which of the two these resources can understand. The alternative woudl be to hard-code such knowledge somewhere - I don't like that idea.

Resolving this is a pre-requisite for clarity-h2020/data-package#47

[DenoBeno]

OK, I have finished setting the "meaning ID" values. If there is any error left, you can fix it here: https://csis.myclimateservice.eu/admin/structure/taxonomy/manage/dp_variable_meanings/overview

This said, the titles of the "dp variable meaning" taxonomy terms are meant to be used as labels on CSIS UI. So they should probably also be exposed by csis helpers.

[patrickkaleta]

O.K., I tried to revolve this in branch feature/010-extend-entityinfo by accessing field_var_valueinstead of field_var_meaning, but this didn't work:

The website encountered an unexpected error. Please try again later.</br></br><em class="placeholder">InvalidArgumentException</em>: Field field_var_value is unknown. in <em class="placeholder">Drupal\Core\Entity\ContentEntityBase-&gt;getTranslatedField()</em> (line <em class="placeholder">587</em> of <em class="placeholder">core/lib/Drupal/Core/Entity/ContentEntityBase.php</em>).

@p-a-s-c-a-l
As explained by Denis, there are two taxonomies at play here and you were trying to access the field of one taxonomy in the second taxonomy, where it's not present... and Drupal doesn't like things like that.

Denis already finished his workaround, so you should now get the wished results. I will revert the changes in feature/010-extend-entityinfo.

Another thing we need in 'study_info' is 'field_eea_city_profile_name' from the Cities/Regions Taxonomy. Maybe @patrickkaleta can add this, too?

That field was added to the studyInfo object already a while ago. It's called eea_city_name, but I can rename it to eea_city_profile_name if you like.

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

but I can rename it to eea_city_profile_name if you like.

no it's o.k. Thanks.

regarding the variables / taxonomies / taxonomy mappings / meanings / .... : we shouldn't overcomplicate things. lets keep it simple and move on.

[DenoBeno]

I wonder what is the status of this ticket now?

In principle we have all we need at the moment. So maybe it's done?
We also know that more will be needed later, see #14 (comment). So is it on hold then?

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

It's done. We open a new issue if we need more.