Naming conventions for LE Temperature layers

[ghilbrae]

As discussed with @luis-meteogrid in today's meeting, we would like to have some inputs from Maja regarding the naming of the Local Effects' layers related to the Temerature probabilities during N days.

Once we have this information we will update both CKAN and the layers in geoserver. Also this information will be needed by @maesbri and @humerh to update the Data Package and EMIKAT, respectively.

[mzuvela]

One suggestion would be to define naming with these attributes: LE$parameter$event_$timeperiod$scenario_$location where: LE= local effect $parameter= temperature, Ta (air temperature), Tmrt (mean radiant temperature) $event = RareEvent, FrequentEvent, … $time_period =1971-2000, 2011-2040, 2041-2070, 2071-2100 $scenario = observations, historical, RCP2.6, RCP4.5, RCP8.5 $location = Naples, Linz,…

Example: LE_Tmrt_FrequentEvent_1971-2000_observations_Naples

or to include the information of the Event like: LE_Tmrt_FrequentEvent(26°C,3days)_1971-2000_historical LE_Tmrt_RareEvent(40°C,8days)_2071-2100_RCP8.5

[ghilbrae]

Thank you for your proposal @mzuvela We've been considering the options and we think that the first option seems like a good choice:

LE$parameter$event_$timeperiod$scenario_$location

Example: LE_Tmrt_FrequentEvent_1971-2000_observations_Naples
LE_Tmrt_RareEvent_1971-2000_observations_Naples LE_Tmrt_VeryRareEvent_1971-2000_observations_Naples

We'll rename the layers in our geoserver accordingly. @maesbri @humerh please take notice of this change.

[ghilbrae]

@mzuvela sorry to bother you again, but we have some doubts about the naming conventions and we'd like to clarify this before changing everything.

One suggestion would be to define naming with these attributes: LE$parameter$event_$timeperiod$scenario_$location where: LE= local effect $parameter= temperature, Ta (air temperature), Tmrt (mean radiant temperature)

I've seen that some of these parameters follow the naming of the ones detailed by Plinius on the models spreadsheet. Should we follow what's in there or is this information coming from a different source? I've been looking in the Climate Indices spreadsheet and I'm not certain if we have to follow what's written in there too.

$event = RareEvent, FrequentEvent, …

What are the options for this? We currently have layers for low, medium, high and very high. How will this match? FrequentEvent --> Low RareEvent --> High VeryRareEvent --> Very High ??? --> Medium

Thanks for your help!

[mzuvela]

This naming convention was just a suggestion, so if the order of attributes is defined differently in other sources, feel free to modify it. In naming of climate indices, there is still information about the models, but this is here not relevant. Or I missunderstood the question? @RobAndGo @claudiahahn Please correct if you see it differently.

For naming of the $event, we discussed at the ZAMG that in case of Hazard Events for Impact Scenarios it would be better to refer to "Frequent", "Occasional" and "Rare" than "Low", "Medium", "High" or "Very High". Because "Low", "Medium", "High" were used in context of impact and here we are looking at a probability of hazard event without knowing what the impact would be.

[ghilbrae]

This naming convention was just a suggestion, so if the order of attributes is defined differently in other sources, feel free to modify it. In naming of climate indices, there is still information about the models, but this is here not relevant. Or I missunderstood the question? @RobAndGo @claudiahahn Please correct if you see it differently.

I'm sorry if I was not clear enough. I have no issue with the naming convention. I was just wondering if the names of the indexes, such as $parameter= temperature, Ta (air temperature), Tmrt (mean radiant temperature), are coming from some document. Mainly to ensure that we all rename layers, CKAN entries, or the Data Package following the same criteria.

For naming of the $event, we discussed at the ZAMG that in case of Hazard Events for Impact Scenarios it would be better to refer to "Frequent", "Occasional" and "Rare" than "Low", "Medium", "High" or "Very High". Because "Low", "Medium", "High" were used in context of impact and here we are looking at a probability of hazard event without knowing what the impact would be.

So there will be no medium or very high events, it will only be: "Frequent", "Occasional" and "Rare".

Thanks!

[ghilbrae]

Hi @maesbri @mzuvela @RobAndGo We need to continue with this conversation and come up with a good convention for all this stuff. On today's meeting Denis has expressed the convenience of having also a convention that is clear for the final user.

It may be that we have a "developer/code friendly" name and a "user friendly" translation. I don't know if this is something that can be added as a "easy name" somewhere in the data package (it may even exist already). Thanks!!!

[ghilbrae]

Hi! I've created a spreadsheet with some info related to layers taken from the data package that @maesbri mentioned yesterday. You can see the source here (https://raw.githubusercontent.com/clarity-h2020/data-package/master/examples/dc1-naples/datapackage.json)

I've added a few more layers that are not the ones related to LE but I feel that they may be useful to consider them too.

Naming_of_layers_LE.xlsx

I hope this may be useful to @RobAndGo when creating his spreadsheet, as discussed yesterday.

Looking into the naming convention @mzuvela suggested, I think it is useful and fits our needs well. The issue of the "human understandable" title for LE is another matter and it would be great if any of you (or the people related with WP3) could make some suggestions.

[maesbri]

Naming convention MUST be also compliant with data package specification. In that regard, the "name" property for the resources ONLY accepts identifiers that match with the following regular expression: ^([-a-z0-9._/])+$" (this is inherited from the Frictionless data package specification).

That's it: Only letters, numbers and ".", "_" and "/" symbols.

This is because the name acts as unique identifier for resources within the data package, therefore we should have a naming convention that prevents from having possible collusion of two resources with the same name.

A part from that, I would remove any reference to formats in the name (e.g., "netcdf32) and use only (if possible) lower-case letters.

Being said that, I would expect that WP2/WP3 proposes the naming templates for the different types of resources we have in the data package.

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

Is there also human readable title available, e.g. for the map component's layer widget? @therter

[maesbri]

title and description in the data package are free text, so no problem with that. Nevertheless, it would be very nice to have also some sort of a title and description texts templates (for each type of resource) with placehoders where we can replace for instance {place}, {year}, {emissions scenario} and so on. This way for instance, the future QGIS plugin could already pre-fill in those text titles/descriptions based on the resource type and some other parameters, letting the user to fine-tune the text afterwards if it is deemed necessary.

[therter]

Is there also human readable title available, e.g. for the map component's layer widget?

The layer widget uses the attribute field_title as title for the layers, at the moment.

[RobAndGo]

In response to @ghilbrae here is a first attempt at her excel spreadsheet with some modifications.

Naming_of_layers_LE_zamg.xlsx

Of note on the first sheet are the new names of the data files. Column E contains the old naming convention. These names corresponded to 1 model only. In reality, the output will be the result of an ensemble of model calculations where the plan is to show the ensemble mean (_ensmean: average of the result across all models) and an ensemble standard deviation (_ensstd) as a measure of how certain the result is (i.e. how much the models deviate from one another). These new names are shown in Column F.

I have added a new sheet labelled "hot-days". This is one of many hazard characterisation indices which is planned to be used to:

1. help the user relate the climate change signal to indices that they may be more familiar with but,
2. will not be used for the calculations of i) local hazard characterisation, and ii) risk and impact.

If you are happy with this format, I will complete the table for the remaining hazard characterisation indices. Note, that to date, "heat-wave-duration" is the only index which is used in the local hazard characterisation, and risk and impact calculations. It is still to be determined which index will be used for the precipitation/flood calculations proposed by PLINIVS.

[maesbri]

Hi @RobAndGo , @ghilbrae

I am taking this example for my comments: "clarity:Tx75p-consecutive-max_rcp45_20710101-21001231_ensmean, Tx75p-consecutive-max_rcp45_20710101-21001231_ensstd"

• there are three characters in the name that should be replaced: ":", " " (white space) and "," as they don't follow the naming limitations from my comment above
• "clarity" prefix I think it is added by geoserver (together with the ":"). Is not possible to configure Geoserver to not add the prefix? (we already know that all layers are being produced by CLARITY)

[RobAndGo]

Sorry, in this cell I meant only to indicate the two additional files:

1. Tx75p-consecutive-max_rcp45_20710101-21001231_ensmean
2. Tx75p-consecutive-max_rcp45_20710101-21001231_ensstd

[maesbri]

ok, forget my comment from above, I hadn't notice the "hot-days" tab. "The values in the "name" column are fine for me :)

edit: hmm, but "exposure_population_age<15_naples" is not valid as it contains "<"

[maesbri]

ok, forget my comment from above, I hadn't notice the "hot-days" tab. "The values in the "name" column are fine for me :)

edit: hmm, but "exposure_population_age<15_naples" is not valid as it contains "<"

I think it would be easier if just "name" property and layer name (in geoserver) had the same values (with the restrictions mentioned above).

[RobAndGo]

I have replaced the "<" and ">" symbols using "lt" (less than) and "gt" (greater than) in the excel file.

[ghilbrae]

Thanks all! The proposal looks good to me too.

@maesbri regarding the "clarity:" or "Local Effects:" as you guessed, this comes from geoserver. It is related with the workspace in which the layer has been placed. We created four of them: Exposure, Hazard, Local_Effects and clarity, we thought that it might be better to classify the layers in some way inside geoserver. TBH, I don't know if the layers can be added outside a workspace. Anyway, if the resulting name cannot be correctly handled by the data package maybe it can be constructed on-the-fly based on some other field (?).

[RobAndGo]

Here is an update of the excel spreadsheet with additional sheets added for the other indices. Naming_of_layers_LE_zamg.xlsx Note that it is not yet complete.

[humerh]

I am wondering about the big number of different LE layers, especially regarding the variations of Time-Periods and RCP's.

I understood in the discussions with ZAMG and PLINIVS, that the Local Effect input (and output) data are INDEPENDENT from Time-Periods and RCPs. The ONLY input parameters are TEMPERATURE and DURATION!

This was also the base of our current implementation in EMIKAT.

The TIME-PERIOD and the RCP-Scenarios influence only the probability of the events!!! Not the actual results of the LE calculation. This also seems to be true for the data currently on the GeoServer:

The data of these 3 layers seems to be the same, only the naming changed. Is this correct? Therefore a multiplication of data will result.

Our proposal would be to have only Local effect layers with a naming like:

• LE_Tmrt_3d_34C_Naples
• LE_Tmrt_6d_34C_Naples
• LE_Tmrt_3d_38C_Naples
• LE_Tmrt_6d_38C_Naples and so on ....

If we misunderstood the whole thing, please correct us =)

Best regards, Heinrich & Bernhard

[claudiahahn]

You are right. The TIME-PERIOD and the RCP-Scenario influence only the probability of the event, not the actual results of the LE calculation.

If the LE calculation is the same as provided in the Excel sheet by PLINIVS September last year, only the temperature is needed for the LE calculation, not even the duration. This should be double checked with @luis-meteogrid

see also: [https://github.com/clarity-h2020/local-effects/issues/3]

[luis-meteogrid]

I'm afraid that's not the adopted convention. We need to know not only temperature and extent but also when and under what scenario it will occur, otherwise the user will not be able to obtain the necessary time evolution for the analysis of adaptation measures. So even if some layers are are repeated the names include period and rcp: Local_Effects_LE_Tmrt_FrequentEvent_historical_19710101-20001231_ensmean_3d_26C_Naples Local_Effects_LE_Tmrt_FrequentEvent_rcp45_20110101-20401231_ensmean_3d_28C_Naples Local_Effects_LE_Tmrt_FrequentEvent_rcp45_20410101-20701231_ensmean_3d_34C_Naples Local_Effects_LE_Tmrt_FrequentEvent_rcp45_20710101-21001231_ensmean_3d_34C_Naples ...

[luis-meteogrid]

... and Claudia you are right, the layers don't depend on the extent just the temperature is needed, although the impacts in human health do depend on the extent.

[luis-meteogrid]

Bellow you can check the names of the layers we have uploaded to Geoserver:

Local_Effects_LE_Tmrt_FrequentEvent_19710101-20001231_observations_3d_28C_Naples Local_Effects_LE_Tmrt_FrequentEvent_historical_19710101-20001231_ensmean_3d_26C_Naples Local_Effects_LE_Tmrt_FrequentEvent_rcp45_20110101-20401231_ensmean_3d_28C_Naples Local_Effects_LE_Tmrt_FrequentEvent_rcp45_20410101-20701231_ensmean_3d_34C_Naples Local_Effects_LE_Tmrt_FrequentEvent_rcp45_20710101-21001231_ensmean_3d_34C_Naples Local_Effects_LE_Tmrt_FrequentEvent_rcp85_20110101-20401231_ensmean_3d_30C_Naples Local_Effects_LE_Tmrt_FrequentEvent_rcp85_20410101-20701231_ensmean_3d_32C_Naples Local_Effects_LE_Tmrt_FrequentEvent_rcp85_20710101-21001231_ensmean_3d_34C_Naples Local_Effects_LE_Tmrt_OcasionalEvent_19710101-20001231_observations_3d_30C_Naples Local_Effects_LE_Tmrt_OcasionalEvent_historical_19710101-20001231_ensmean_11d_30C_Naples Local_Effects_LE_Tmrt_OcasionalEvent_rcp45_20110101-20401231_ensmean_13d_32C_Naples Local_Effects_LE_Tmrt_OcasionalEvent_rcp45_20410101-20701231_ensmean_3d_38C_Naples Local_Effects_LE_Tmrt_OcasionalEvent_rcp45_20710101-21001231_ensmean_11d_34C_Naples Local_Effects_LE_Tmrt_OcasionalEvent_rcp85_20110101-20401231_ensmean_5d_34C_Naples Local_Effects_LE_Tmrt_OcasionalEven_rcp85_20410101-20701231_ensmean_4d_38C_Naples Local_Effects_LE_Tmrt_OcasionalEvent_rcp85_20710101-21001231_ensmean_4d_40C_Naples Local_Effects_LE_Tmrt_RareEvent_19710101-20001231_observations_3d_32C_Naples Local_Effects_LE_Tmrt_RareEvent_historical_19710101-20001231_ensmean_3d_36C_Naples Local_Effects_LE_Tmrt_RareEvent_rcp45_20110101-20401231_ensmean_4d_40C_Naples Local_Effects_LE_Tmrt_RareEvent_rcp45_20410101-20701231_ensmean_5d_40C_Naples Local_Effects_LE_Tmrt_RareEvent_rcp45_20710101-21001231_ensmean_7d_40C_Naples Local_Effects_LE_Tmrt_RareEvent_rcp85_20110101-20401231_ensmean_6d_38C_Naples Local_Effects_LE_Tmrt_RareEvent_rcp85_20410101-20701231_ensmean_8d_40C_Naples Local_Effects_LE_Tmrt_RareEvent_rcp85_20710101-21001231_ensmean_8d_40C_Naples

as you can see there are some repetitios but not so much considering temperature and extent (a lot considering just temperature).

[ghilbrae]

@claudiahahn @humerh @luis-meteogrid any updates on this? Do you deem necessary to involve Plinius in this discussion?

[claudiahahn]

For me it seems to be a matter of organising and retrieving the files. If it is possible within the system to select the correct local effect layer for each RCP-scenario, time-period (2011-2040, 2041-2070, ...) and event (frequent, occassional, rare) from only a few local effect layers (one for each temperature), it would be possible to avoid multiplication of data. However, with the naming convention above it is easy to see what e.g. a rare event at the end of the century for RCP8.5 looks like (8day, 40 °C).

[humerh]

I want to propose another solution:

As the attributes "FrequentEvent"/"OcasionalEvent"/"RareEvent" are dependend of the location (or the study area) there should be a configuration table like this:

EventPropability	Scenario	Period	Event
Frequent	observed	19710101-20001231	3d_28C (3days, 28degC)
Frequent	historical	19710101-20001231	3d_26C
Frequent	rcp45	20110101-20401231	3d_26C
Frequent	rcp45	20410101-20701231	3d_34C
Frequent	rcp45	20710101-21001231	3d_34C
Frequent	rcp85	20110101-20401231	3d_30C
Frequent	rcp85	20410101-20701231	3d_32C
Frequent	rcp85	20710101-21001231	3d_34C
Occasional	observ	19710101-20001231	3d_30C
Occasional	historical	19710101-20001231	11d_30C
Occasional	rcp45	20110101-20401231	13d_32C
Occasional	rcp45	20410101-20701231	3d_38C
...... and so on ...
Rare	observed	19710101-20001231	3d_32C
Rare	historical	19710101-20001231	3d_36C
Rare	rcp45	20110101-20401231	4d_40C
...... and so on ...

This table should be defined for each "data package", because it is characteristic for a specific region!

For the test case "Naples" this table may look like described above. In the test case of "Linz" this may look different.

I think, if we have a table like this we have no need to double the "Local Effect Layers" and this definition is usable as well for Drupal front end, and is also usable for emikat calculation.

The name of the event can easily be mapped to my suggested "Local Effect layers" like this:

Event	Layername
3d_28C	LE_Tmrt_3d_28C_Naples
3d_34C	LE_Tmrt_3d_34C_Naples

[ghilbrae]

@humerh I'm reopening because the discussion seems to be still open. If you feel it's settled let me know.

[ghilbrae]

@maesbri as per @luis-meteogrid comment, the current names for the LE layers can be updated in the data package and are as follows:

Bellow you can check the names of the layers we have uploaded to Geoserver:

Local_Effects_LE_Tmrt_FrequentEvent_19710101-20001231_observations_3d_28C_Naples Local_Effects_LE_Tmrt_FrequentEvent_historical_19710101-20001231_ensmean_3d_26C_Naples Local_Effects_LE_Tmrt_FrequentEvent_rcp45_20110101-20401231_ensmean_3d_28C_Naples Local_Effects_LE_Tmrt_FrequentEvent_rcp45_20410101-20701231_ensmean_3d_34C_Naples Local_Effects_LE_Tmrt_FrequentEvent_rcp45_20710101-21001231_ensmean_3d_34C_Naples Local_Effects_LE_Tmrt_FrequentEvent_rcp85_20110101-20401231_ensmean_3d_30C_Naples Local_Effects_LE_Tmrt_FrequentEvent_rcp85_20410101-20701231_ensmean_3d_32C_Naples Local_Effects_LE_Tmrt_FrequentEvent_rcp85_20710101-21001231_ensmean_3d_34C_Naples Local_Effects_LE_Tmrt_OcasionalEvent_19710101-20001231_observations_3d_30C_Naples Local_Effects_LE_Tmrt_OcasionalEvent_historical_19710101-20001231_ensmean_11d_30C_Naples Local_Effects_LE_Tmrt_OcasionalEvent_rcp45_20110101-20401231_ensmean_13d_32C_Naples Local_Effects_LE_Tmrt_OcasionalEvent_rcp45_20410101-20701231_ensmean_3d_38C_Naples Local_Effects_LE_Tmrt_OcasionalEvent_rcp45_20710101-21001231_ensmean_11d_34C_Naples Local_Effects_LE_Tmrt_OcasionalEvent_rcp85_20110101-20401231_ensmean_5d_34C_Naples Local_Effects_LE_Tmrt_OcasionalEven_rcp85_20410101-20701231_ensmean_4d_38C_Naples Local_Effects_LE_Tmrt_OcasionalEvent_rcp85_20710101-21001231_ensmean_4d_40C_Naples Local_Effects_LE_Tmrt_RareEvent_19710101-20001231_observations_3d_32C_Naples Local_Effects_LE_Tmrt_RareEvent_historical_19710101-20001231_ensmean_3d_36C_Naples Local_Effects_LE_Tmrt_RareEvent_rcp45_20110101-20401231_ensmean_4d_40C_Naples Local_Effects_LE_Tmrt_RareEvent_rcp45_20410101-20701231_ensmean_5d_40C_Naples Local_Effects_LE_Tmrt_RareEvent_rcp45_20710101-21001231_ensmean_7d_40C_Naples Local_Effects_LE_Tmrt_RareEvent_rcp85_20110101-20401231_ensmean_6d_38C_Naples Local_Effects_LE_Tmrt_RareEvent_rcp85_20410101-20701231_ensmean_8d_40C_Naples Local_Effects_LE_Tmrt_RareEvent_rcp85_20710101-21001231_ensmean_8d_40C_Naples

Until we get to a new understanding or solution, we are using this convention.

Thanks!

[humerh]

As I understand we need also Local_Effect Layers, which are the result from appling Adaptation Options. What is - outgoing from your suggested naming convention - your strategy:

• Which layer is used as base layer?
• What is the Name of the layer coming as consequence of an Adaptation Option Measure?
• Should the Adaptation Option be applied to all your Basic layers?

The overall strategy of workflow is not agreed, an as consequence we have no common Picture. This is a big Problem!!!

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

The overall strategy of workflow is not agreed, an as consequence we have no common Picture.

You are right. Some months ago, I made a proposal, but dind't receive any feedback.

[humerh]

You are also right. I thought about this. I have a picture on this point, but this picture is based on an emikat picture of the world. At that time I had the impression we investigate on a multi-server implementation, and therefore I have no clear picture. Till now the selected strategies on different sites do not match. But I will try to prepare "my interpretation" for the session on Thursday. We can then discuss on this.

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

Until we get to a new understanding or solution, we are using this convention.

So we can close this issue?

[ghilbrae]

I think so, at least for now. We can always reopen or open a new one when/if we need to revisit this topic.