[Proposal] Loss impact, method and type fields

[odscjen]

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 for Vulnerability could be reused within Loss. 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 within Loss correctly.

Current state

rdl_schema_0.1 field	rdl_schema_0.1 description	DDH field	DDH description
Calculation method	How the scenario was calculated	vln_calc_method	Type of data on which the impact function is based (Simulated, Inferred, Observed)
model.impact	Type of impact	vln_impact_type	Type of impact calculated (Direct, Indirect, Total)
model.loss_type	Type of loss	los_type	Ground-up, Insured
model.metric	Type of loss metric	vln_impact_metric	Annual Average Loss, Annual Average Loss Ratio, Probable Maximal Loss, Value At Risk (VAR), Tail Value at Risk (TVAR), Scenario Loss(for use in deterministic scenario?)
		hzd_frequency_type	Rate of Exceedence, Probability of Exceedence, Return Period, Susceptibility
		los_approach	Overall approach on which the loss calculation is based (Empirical survey, Analytical, Judgement, Hybrid)

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...

Loss field	equivalent in other component
vln_calc_method	vulnerability.impact.base_data_type
vln_impact_type	vulnerability.impact.type
vln_impact_metric	vulnerability.impact.metric
los_type	Loss specific
hzd_frequency_type	vulnerability.hazard_analysis_type - changed as the frequency/occurence has all been updated
los_approach	Loss specific but uses the same codelist as vulnerability.functions.{}.approach

If it is then we could reference the Impact object created for Vulnerability.impact although that would offer the potential to include the vulnerability.impact.unit in Loss. For the others, we could use the following

field	title	description	codelist	open/closed
type	Loss type	The type of loss described in the dataset.	ground-up, insured	closed?
analysis_type	Vulnerability hazard analysis type	The type of analysis applied to the hazard data used to calculated the vulnerability data used in the loss dataset.	analysis_type.csv (probabilistic, deterministic, empirical)	closed
approach	Loss approach	The approach the loss calculation function is based upon.	function_approach.csv (Empirical, Analytical, Judgement, Hybrid)	closed

[matamadio]

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.

[stufraser1]

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.

[matamadio]

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.

[odscjen]

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

[stufraser1]

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.

[odscjen]

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.