Implement EE Table

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

Status:

• [x] GUI implementation ("html wireframe") as React AJAX web Application following the respective Product Mock-Ups
• [x] Integration into the respective GL-Step as External ReactMount Application
• [x] Design of a simplified internal state data model in JSON (the "table model") and definition of static JSON constants (example) as initial reference / example data based on the example table content from the mock-up screens.
• [x] the table contains the content for DC1 Reference study (The content will be retrieved from the table-state-rest-api)
• [x] Mapping of the actual Data Package Data Model to the internal JSON state data model with help of the JSON:API and/or REST Views and additional REST Micro Services for simple data aggregation and transformation.

Implement the EE Table following ~the Mock-Up and~ the approach described here.

EE Table GUI

Important Note: The Mock-Up seems to be outdated. It seems that a request for revision wasn't taken into account. Furthermore, future exposure scenarios as shown in the mock-up above are, if at all, expected to be supported in the expert workflow of DC2 only and for sure not in CSIS v1. Therefore we follow KISS and YAGNI and start with the following EE table example taken from this excel sheet.

HC Table state model

• column 1: Hazard is the hazard 'applicable' to the exposed element
• column 2: category to group several EE layers. Same categorisation as in the map-component and HC/HC-LE tables!
• column 3: the vulnerability class, but essentially that's the name of the EE layer. For each vulnerability class, there will be a separate layer. So column 2 and column 3 define also the hierarchy of the map layer widget for the EE step!
• column 4: absolute numerical value
• column 5: the unit may become part of the class or name, respectively. (to be consistent with in the HC table which lacks a unit column good reasons)

Currently, no realistic example data is available. Example layers however will be reported in this issue.

Mapping Data Package to HC Table state model

Same approach as in Implement HC table: 1) Fetch Data Package Meta Data and build WCS requests, 2) Fetch data for each relevant layer from WCS, aggregate and transform to JSON state model.

[therter]

@ghilbrae @luis-meteogrid: An example for the table state model:

{
    "data": [
        {
            "hazard": "HW,PF,FL",
            "elementAtRisk": "Population",
            "vulnerabilityClasses": "Age group 0-14",
            "values": "2",
            "unit": "pop/km2"
        },
        {
            "hazard": "HW,PF,FL",
            "elementAtRisk": "Population",
            "vulnerabilityClasses": "Age group 15-64",
            "values": "2.45",
            "unit": "pop/km2"
        },
        {
            "hazard": "HW,PF,FL",
            "elementAtRisk": "Population",
            "vulnerabilityClasses": ">65",
            "values": "3",
            "unit": "pop/km2"
        },
        {
            "hazard": "PF,FL",
            "elementAtRisk": "Buildings",
            "vulnerabilityClasses": "Continuous Residential (S.L. > 80%)",
            "values": "2.3",
            "unit": "m3/m2"
        },
        {
            "hazard": "PF,FL",
            "elementAtRisk": "Buildings",
            "vulnerabilityClasses": "Med-Hi Density Discontinuous Res. (30% < S.L. < 80%)",
            "values": "2.56",
            "unit": "m3/m2"
        },
        {
            "hazard": "PF,FL",
            "elementAtRisk": "Buildings",
            "vulnerabilityClasses": "Low Density Discontinuous Res. (S.L. < 30%)",
            "values": "1.3",
            "unit": "m3/m2"
        },
        {
            "hazard": "PF,FL",
            "elementAtRisk": "Buildings",
            "vulnerabilityClasses": "Non Residential",
            "values": "1.56",
            "unit": "m3/m2"
        },
        {
            "hazard": "PF,FL",
            "elementAtRisk": "Infrastructure",
            "vulnerabilityClasses": "Roads",
            "values": "2.34",
            "unit": "ml"
        },
        {
            "hazard": "PF,FL",
            "elementAtRisk": "Infrastructure",
            "vulnerabilityClasses": "Railways",
            "values": "3.98",
            "unit": "ml"
        }
    ]
}

[ghilbrae]

Same as on issue #1:

Do you mean that all this data will be available from the layers that are going to be uploaded to geoserver? Will there be other sources? Where will the Data Package Meta Data reside?

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

Do you mean that all this data will be available from the layers that are going to be uploaded to geoserver?

I hope so. :). But I don't expect that the exposure layers will already contain the information related to hazards. I think this relationship can be made via the Data Package Meta-Data (correct? @maesbri ) which is stored in the Drupal System an can be obtained via the Drupal JSON API.

This data (but for all grid cells of the study area, not just aggregated for tabular visualisation) is also needed for impact calculation. IMHO the relation between Hazard Type and Element at Risk Type is also part of the EMIKAT Logical Model (IMACT_CASE) (correct? @humerh). But I'm not sure whether we can query EMIKAT for this data.

[therter]

current status:

• [x] GUI implementation ("html wireframe") as React AJAX web Application following the respective Product Mock-Ups
• [x] Integration into the respective GL-Step as External ReactMount Application
• [x] Design of a simplified internal state data model in JSON (the "table model") and definition of static JSON constants (example) as initial reference / example data based on the example table content from the mock-up screens.
• [x] the table contains the content for DC1 Reference study
• [x] Mapping of the actual Data Package Data Model to the internal JSON state data model with help of the JSON:API and/or REST Views and additional REST Micro Services for simple data aggregation and transformation.

[ghilbrae]

Sorry for the radio silence.

We are still a bit confused about what it is expected from our side. So I will try to explain what we have understood and what questions we have so you can clarify anything:

• The idea is to have some kind of tool (API?) that queries the layers available in geoserver to return a JSON response with the data needed.
• The tool will be called by some module of the CSIS with the set of parameters/data/whatever that is needed according to the example above.
• The tool will return the information needed back.
• We will probably implement this using python or some python-related framework.
• Where is this tool supposed to be installed?
• How will authentication work?

[therter]

The example request of the table-state-rest-api is now used

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

Currently, the URL to the table-state-rest-api is hard-coded. How can this work for different exposure resources? Why is this not loaded from the Data Package? The URl of the REST API should be stored in the EE Resource in the corresponding Data Package. We can use the new references field and URL of type @tableview:meteogrid:rest analogous to the @mapview:ogc:wms type used by the Map Component. See also https://github.com/clarity-h2020/table-components/issues/16

Furthermore, we have to switch to EMIKAT API as it supports Exposure Data for whole Europe. See also https://github.com/clarity-h2020/table-state-rest-api/issues/3

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

@therter Is the bbox hardcoded, too? Will this table work for the cities of Alba Iulia, Agios Dimitrios and Bottrop ?

[therter]

Is the bbox hardcoded, too? Will this table work for the cities of Alba Iulia, Agios Dimitrios and Bottrop ?

The table reads the bbox and the layers from the study. But the layers must be hosted by the meteogrid wms and contain the data for the cities of Alba Iulia, Agios Dimitrios and Bottrop. I don't know if there are still exposure layers available from the meteogrid wms.

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

Any news on that? Please explain how and where the correct exposure layer used by the table rest API is set. It's not in the data package so I assume it is hardcoded. Where? in the table or the API?

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

This table is obsolete now and won't be updated. See https://github.com/clarity-h2020/csis/issues/15#issuecomment-528248023