Implement new Adaptation Options table

[DenoBeno]

We need a new adaptation option table to replace the one shown on https://csis.myclimateservice.eu/study/1/step/445/view/table

This table must have the following features:

• Shows the adaptation options that are defined as adaptation_options drupal entites (as in https://csis.myclimateservice.eu/adaptation-options-overview)
• Shows only the adaptation options that are listed in the data package (maybe with an option to show all?)
• Allow the user to add the adaptation option to the report, like it's implemented for twins

The idea is to have something working now and to add a possibility to APPLY the adaptation options to the project and see the result later.

probably related to:

• Make the backlinks from showcases to adaptation options visible #76
• Implement Table Components #46

[DenoBeno]

@fgeyer16 : I suppose that only few people understand how this is even supposed to work, so please explain...

I am looking at the https://csis.myclimateservice.eu/study/1/step/445/view/table step.

That step shows https://csis.myclimateservice.eu/admin/structure/views/view/view_mode_for_gl_step/edit/page_6?destination=/study/1/step/445/view/table, which only says the following:

1. you have two contextual parameters: group ID and ID of a specific GL-step node
2. GL-step must belong to the group, but the group ID or contents apparently aren't used at all.
3. Show the GL-step node in the "Table" view mode.

That table view mode is defined in https://csis.myclimateservice.eu/admin/structure/types/manage/gl_step/display/table and displays "table_app", which is defiend as external applicaiton.

So far so good, but what I need is an internal view instead. There is such a view defiend for "twins" step, as shown here https://csis.myclimateservice.eu/admin/structure/types/manage/gl_step/display/twins?destination=/contextual/render&destination=/study/1/step/445/view/twins

So, I could add a viewfield "view table" and set it per default to the view that will produce what we need, but how do I assure that this table is only shown in the "adaptation options" step, whereas the javascript app table is shown in other cases?

[DenoBeno]

Following the discussion with Florian, I know how to do this in principle now.

[DenoBeno]

List of changes to the system:

In the study group:

• field_included_contents entity reference for storing the chosen AOs. This could be used for storing other node references in the future if needed.

In the gl_step node:

• Relabeled the field_view_* and field_*_app so that they are sorted next to each other.
  
• added field_view_table Viewfield - for showing the table view
• added this field to table view mode
  

[DenoBeno]

More changes:

Adaptation option effects node:

• fields: hazard, element at risk and change in vulnerability (between --- and +++)
• automatic title [node:field_hazard2]/[node:field_element_at_risk] [node:field_aoe_vuln]

Adaptation options node:

• removed targeted elements at risk
• field_adaptation_option_local_ef has a new label (Local effects change)
• field_adaptation_option_local_ef can use "LocalEffectsParameters" and "Local hazard change" taxonomy now.

"LocalEffectsParameters" and "Local hazard change" taxonomies

• "sister taxonomies", same structure
• in addition to title & description, they also have a "value" and "unit" fields. Intended use is illustrated below.

It's up to our colleagues from plinius and Heinrich to decide how they want to use this (if at all), but this allows to transparently add parameters for local effect calculations. And the local effect can be also directly on a hazard if that is what we want.

[DenoBeno]

Even more changes...

Adaptation options table on https://csis.myclimateservice.eu/adaptation-options-overview reworked.

• floating table legend
• "effects" contains both local effects change and vulnerability change
  
• filtering
  

Adaptation options main view reworked:

• todo: add backlinks for solutions and for showcases.

Adaptation options edit mode improved

• entity browsers for Vulnerability & for Local effects change.

[DenoBeno]

I was stalled with this due to work on templates for studies. Still on my TODO

[DenoBeno]

I have implemented a new "exposure twins" view and realised that the way we are looking for available twins is broken.

I also implemented a view to show available AOs, but it will suffer from the same issues.

[DenoBeno]

@patrickkaleta : I have implemented a new "adaptation options" table for the study "ADAPTATION OPTIONS: IDENTIFICATION" step.

see https://csis.myclimateservice.eu/study/17/step/1030/view/table

Problem: the buttons are disabled. Why?

[patrickkaleta]

@patrickkaleta : I have implemented a new "adaptation options" table for the study "ADAPTATION OPTIONS: IDENTIFICATION" step.

see https://csis.myclimateservice.eu/study/17/step/1030/view/table

Problem: the buttons are disabled. Why?

It works now. Adaptation options can now be added to the GL-Step using the CSIS-helpers module.

FYI:
Buttons didn't work, because the respective JS file in the CSIS helpers module is specifically limited to the content types we want to have in the GL-Step (until now it was only Showcase and Twin).

I could remove this "safety lock", but I'm not sure what will happen when the JSON:API suddently tries to add content types to the field_included_twins field that are not allowed in the field's configuration. When I find time, I will try this out, but until then I would leave the safety lock on.

From my point of view this issue can be closed. @DenoBeno do you require anything else regarding this topic right now?

[DenoBeno]

@patrickkaleta : no, everything works now.

the only remaining open issue is that Heinrich needs to know which adaptation option to apply to which types of surface layers. I suppose that we need a list or taxonomy of possible surface layers and a field in the AOs that can reference to 0..1 or 0..* such layers.

If 0 - nothing to do for emikat.
If 1 or more : apply the linked "Local effects change" to a given surface layer.

TODO

1. I already added a taxonomy, but it lacks entries. referencing to https://csis.myclimateservice.eu/admin/structure/taxonomy/manage/land_use/overview. What are the possible land use categories/IDs?
2. add a reference field to https://csis.myclimateservice.eu/admin/structure/types/manage/adaptation_options/fields,

FYI

Since local effect change accepts two types of entries AND we can't be sure that al lthe linked entries are correct, EMIKAT will need to to decide which ones are usable and ignore the rest.

[DenoBeno]

OK, I added the entries to taxonomy now, see https://csis.myclimateservice.eu/jsonapi/taxonomy_term/land_use?fields&#91land_use&#93=name,%20field_id

I also added a field_land_use ("Applicable to") and filled in the values for some existign AOs. See https://csis.myclimateservice.eu/adaptation-options-overview

This is done for me now. What's still needed is new entries/improving existing entries, but that's on PLINIUS and co.

[DenoBeno]

I thought that I'm finished with this, but @humerh has just reported that the "local effects change" can not be the same for all relevant land use categories.
In practical terms, this means that we need a possibility to state that albedo will be 0.5 for "buildings", 0.6 for "low urban fabric" and 0.4 for the "dense urban fabric".

Of course, this is already possible to do but in a way that would lead to inflation of the adaptation options, which would make them more difficult to use for the end users.

I need to think about this....

[DenoBeno]

Since this is already ranged into "done", I'll close it again and open a new issue instead.