Closed odscjen closed 1 year ago
Agree to use the Vulnerability.impact
object for Loss plus the additional attributes specific to Loss schema, and the frequency/occurrence attribute as from hazard schema.
Revisiting #75, there should differences in the codes used for vulnerability impact metric and loss impact metric with the following distinctions:
Vulnerability impact metric includes the metrics found on the y-axis of a vulnerability, fragility, or engineering demand function or vulnerability index. This is really focussed on damage ratios (Vulnerability function), probability - of achieving a damage state (Fragility function), physical structural response (E.D. function).
Loss impact metric refers to the type of loss communicated in the results of an analysis, which need an extra step of processing after the V function is applied. This is for example absolute value with a currency including annual average loss, probable maximum loss, value at risk, tail value at risk; number of fatalities; number of buildings destroyed. Results can also be expressed in terms of a ratio.
I contributed to this confusion by including a reference to 'loss parameters table' here https://github.com/GFDRR/rdl-standard/issues/75#issuecomment-1578241162 but this table actually combined the metrics too.
I think in the end we need two codelists for impact metrics: one for vulnerability object and one for loss object. I will propose these codelists ASAP.
I see your point Stu: many metrics might be the same for the two components, but some would be mostly specific to Vln, other to Loss. It doesn't look too problematic to share one common table, but maybe is just safer to do as you suggest and split the two altogether, while keeping some shared metrics in both lists.
OK.
So the Impact
common object will be left as it currently is. The associated impact_metric.csv
codelist can have two categories of metric in it, one for vulnerability and one for loss. We can achieve this by adding a column to the table, 'Category' and in the descriptions for the impact
object in either component stating to pick only from the impacts_metrics with the relevant category. Does that sound alright? It does mean that the Loss
component will only reference the loss impact metric and not the vulnerability impact metric?
Codes for both types of metric in https://github.com/GFDRR/rdl-standard/issues/125#issuecomment-1622449558
@stufraser1 @matamadio
OK, if best practice to have in same table, seems a good approach. Any codes duplicated for vulnerability and loss do have a slightly different description as they're used in a different context - so loss component doesn't need to access any in the vulnerability category.
Ah, cool. I think I was getting confused as the DDH table references vulnerability in the loss impact field names. Having it in the same table just allows us to reuse the same object. This sounds like this is ready to apply now.
What is the context or reason for the change?
The current version of the schema and the DDH version of the schema have some differences within the Loss component relating to impact. From the discussion in #75 it appears that there was some confusion over whether or not an
Impact
object created forVulnerability
could be reused withinLoss
. ODS thought that it could be, but it appears we got the wrong end of the stick somewhere. This issue is just to clear this up and make sure we're modelling the necessary elements withinLoss
correctly.Current state
These matches may not be what was actually intended but where my best guess based on the allowed values for each (where they existed).
What is your proposed change?
Need to clarify what are the actual values that we need in this component and which are repeats of values found in one or more of the other components.
Is this table correct...
vulnerability.impact.base_data_type
vulnerability.impact.type
vulnerability.impact.metric
vulnerability.hazard_analysis_type
- changed as the frequency/occurence has all been updatedvulnerability.functions.{}.approach
If it is then we could reference the
Impact
object created forVulnerability.impact
although that would offer the potential to include thevulnerability.impact.unit
inLoss
. For the others, we could use the following