Implementation of Impact/Risk assement model for Heat Waves with EMIKAT

[maesbri]

Implementation of the model defined in #21.

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

@bernhardsk @humerh

See also Impact modelling logic example

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

Some ideas for the expected output format of the model, visualisation of tabular data but also the need for an additional aggregation of the model results for easy scenario analysis and comparison are discussed in this issue: clarity-h2020/scenario-analysis#7

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

Related discussions that need feedback from @clarity-h2020/mathematical-models-implementation-team :

• Impact Evaluation Visualisation scenario-analysis#7 (comment)
• Data layer needs information on "Exposure Scenario" data-package#2 (comment)

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

General workflow and examples based on this comment:

When Impact shall be calculated (IA/RA Step),

1. CSIS Frontend sends request to Impact Model Service (EMKIT + some simple REST Interface) with URI of the current study object. (you need to be logged-in at CSIS to access these example URIs)
2. Impact Model Service needs to authenticate at CSIS and retrieves study object JSON representation. The study object JSON is a 'flat' object, so it contains just links to sub-objects like data-package. Question @therter : Mabe there is possibility to get an object from that API that is already completely resolved with all of its sub objects?
3. Impact Model Service extracts from the study object the properties relevant for the impact model. E.g. field_area and field_data_package.
4. The Data Package object, which follows the Data Package Specification contains meta-data for all HC-LE/EE/VA datasets needed by the impact model service (as sub-objects in field_resources).
5. the datasets should be 'preconfigured' at the level of the Impact Model Service, so the service just needs the unique ids of the respective datasets listed in field_resources. @fgeyer16 Could we use the field uuid to uniquely identify a datasets or does the uuid change for each new revision?

To be discussed: How to notify the CSIS of new Impact Model Results? In general, the Impact Model Service should call the JSON API and PUT meta-data following the Data Resource Specification (JSON Example). But this meta-data about the IA/RA results must not be added to the original Data Package but a copy that is only accessible by the members of the study.

[humerh]

We have to concern the following events:

• Creating a new study area: This should trigger a PUT call to emikat ("insertNewScenario") with the fields (name, description) -> returns also the ID of the new created Scenario
  The description field should at the end contain the description of the study (<2000 chars) PLUS some METADATA, like
  CSIS_STUDY_AREA: LL_X, LL_Y, RU_X, RU_Y (in WGS84)
  CSIS_URL: url to get further info for the study and the data packages

• Updating a study: This should trigger a PUSH call to emikat ("updateScenario") with the fields (scenarioId, name, description)

As a consequence of UPDATE all data (mbd) are resynchronized to emikat again.

.....
(further definitions will be provided after a already planned session with Patrik Kaleta on Monday)

A SWAGGER-Interface to emikat will be available at the location:
https://service.emikat.at/EmiKat/swagger/index.html

[patrickkaleta]

After our weekly developer telco this monday, @bernhardsk @humerh @fgeyer16 and I discussed how Emikat and Drupal could communicate and exchange data. For now we will try the following:

• using the SWAGGER-Interface Drupal will notify Emikat when a new Study is created or an existing one is being updated and send necessary information (Study ID, Study area, path to data-package,...)
• additional information can be retrieved by Emikat via a REST-view which will contain all necessary fields (since accessing the whole Study object via REST is probably an overkill)
• Drupal will have to store the Emikat-given ID (which it will receive as response from Emikat) of the Study as well, so that in the case of changes in a Study, Drupal can tell Emikat which study needs to be updated. (For that we will look into the Business-rules module to see how this could be implemented)

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

Interesting! Would it make sense / be possible to define such a REST View for Map Layers that are relevant in the context of a specific step. Please have a look at this issue @therter is working on: clarity-h2020/map-component#2

Currently we intend to load the whole study JSON + Data Package & Data Resources JSON and parse it in the Map Component. A REST View that extracts just the relevant properties from the (Data Package Resources) would me more convenient.

[patrickkaleta]

@p-a-s-c-a-l
Yes, creating such a REST View with only the relevant properties from the data-resource should be possible.

I will first deal with the REST view for Emikat (as sort of a proof of concept) and then have a closer look at the issue you mentioned above.

[patrickkaleta]

I had a look at this over the weekend and tried implementing the following:

1. based on the StudyID a REST view returns the path to another REST view for each resource in the datapackage which is used in the Study
   

2. the second REST view returns the relevant fields
   

Originally I tried to do it all in one step, but the problem is getting the necessary data throughout all the different content types (Study -> Data package -> Resource -> Analysis context). It is possible to display a View inside another View (I did that for the second step where I display the Analysis context fields as a nested View), but as can be seen in the second Screenshot it doesn't appear to be properly formatted JSON.

Would it work for the map compoment, to make multiple REST calls in order to get all necessary fields or does it need to happen in just one REST call?

[fgeyer16]

@patrickkaleta
How did you nest the second view into the first?

[therter]

@patrickkaleta Yes, it is also possible to make multiple rest calls from the map component

[patrickkaleta]

@fgeyer16
in this particular instance I displayed the analysis context as a field with the formatter set to "View" and selected the other REST view. As a view argument I'm passing the Field value, which is the ID of the analysis context.

You can view the settings of this REST view here:
https://csis.myclimateservice.eu/admin/structure/views/view/rest_node/edit/rest_export_4

[fgeyer16]

@patrickkaleta
OK This is they way I had done it as well.

[maesbri]

@p-a-s-c-a-l , @therter

HC-LE resources have been added to the Naples data package (resources identifier ranging from 26 to 29).

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

Model implemented, API available here.

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

Recent changes in model to be implemented.

[DenoBeno]

In theory this is done. Who and how (and when) can check if the output makes sense?

[DenoBeno]

Implemented for heat mortality, I suppose? Close this and open new one for other impacts?