Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Review loss metadata modelling #247

Open
duncandewhurst opened this issue Sep 7, 2023 · 3 comments
Open

Review loss metadata modelling #247

duncandewhurst opened this issue Sep 7, 2023 · 3 comments

Comments

@duncandewhurst
Copy link
Contributor

The discussion and examples from #135 (comment) are very useful in clarifying the requirements for the loss component. After reviewing, I think that there are opportunities to improve the modelling of loss metadata so I'm sharing some initial thoughts below:

image

  • cost: See comments in [Docs update] Examples to be included #135 (comment). Also need to consider the relationship between cost.dimension and .category.
  • .impact: Suggest aligning metrics modelling between exposure and loss. Also need to use consistent terminology (losses rather than impact?)
  • .type (loss_type codelist): We should review the semantics of this field and its codes because there seems to be quite a lot of cross-over with the impact_metric codelist and the code descriptions mix at least two different concepts:
    • The kind of quantity being measured (monetary amounts or counts)
    • How different types of insurance and reinsurance are accounted for in the losses
  • impact.base_data_type, .approach, .hazard_analysis_type: Revist modelling and codelists to reduce semantic cross-over (see comments in [Docs update] Examples to be included #135 (comment))
@stufraser1
Copy link
Member

.category: This field might need to be an array

Yes

.impact: Suggest aligning metrics modelling between exposure and loss. Also need to use consistent terminology (losses rather than impact?)

Lets keep this as it is at the moment.

loss.type cross-over with loss.impact.metric

Agreed - the followinng list would work under loss.impact.metric to define the type of information. When used with loss.impact.unit (requires addition of 'cost' and possibly 'index') will tell us whether its a cost value, ratio, count, index, etc. And we can remove loss.type.
Suggested loss.impact.metric codelist:
damage
probability
downtime
casualties
displaced_people
economic_loss
insured_ground_up_loss
insured_gross_loss
insured_net_precat_loss
insured_net_postcat_loss
at_risk_value
at_risk_tail_value

cost: need to consider the relationship between cost.dimension and .category.

Curent cost.dimension: structure, content, product, disruption, population
Curent .category: agriculture, buildings, infrastructure, population, natural_environment
combined into a one or many .category: agriculture_crop, agriculture_livestock, buildings, content, product, disruption, infrastructure, population, natural_environment
Tihs shhould work for Exposure.category too

impact.base_data_type, .approach, .hazard_analysis_type: Revisit modelling and codelists to reduce semantic cross-over

loss/impact/base_data_type: inferred, observed, simulated
loss/approach: hybrid, analytical, empirical
loss/hazard_analysis_type, deterministic, empirical, probabilistic, judgement
I thihnkn we remove loss/approach - this is needed in Vulnerability but doesn't make sense in Loss component. loss/hazard_analysis_type should be renamed loss/analysis_type - it does not only refer to hazard component but the whole risk analysis process.

@matamadio
Copy link
Contributor

Agree on the proposal.

.category: This field might need to be an array since, based on page 32 of the technical report associated with the Central Asia seismic risk Return Period summaries, it seems like one set of losses can cover multiple categories.

One loss dataset can cover multiple hazard types and exposure categories.

.impact: Suggest aligning metrics modelling between exposure and loss. Also need to use consistent terminology (losses rather than impact?)

I would maintain the distinction as losses are calculated from (one or usually more) impacts, as they are not the same thing.
immagine

Curent cost.dimension: structure, content, product, disruption, population
Curent .category: agriculture, buildings, infrastructure, population, natural_environment
combined into a one or many .category: agriculture_crop, agriculture_livestock, buildings, content, product, disruption, infrastructure, population, natural_environment. This should work for Exposure.category too

Makes sense to me. Content is related to buildings as opposed to building's structure, thus I would specify it and reorder as:

.category: building_structure, building_content, infrastructure, agriculture_crop, agriculture_livestock, population, product, disruption, natural_environment.

loss/impact/base_data_type: inferred, observed, simulated
loss/approach: hybrid, analytical, empirical
loss/hazard_analysis_type: deterministic, empirical, probabilistic, judgement
I think we remove loss/approach - this is needed in Vulnerability but doesn't make sense in Loss component. loss/hazard_analysis_type should be renamed loss/analysis_type - it does not only refer to hazard component but the whole risk analysis process.

Agree to have just one approach/analysis_type attribute for the whole risk process.
Codelist could be either:

  1. simulated, inferred, observed
  2. analytical, deterministic, empirical

@matamadio matamadio pinned this issue Nov 9, 2023
@matamadio
Copy link
Contributor

Pinning the issue as priority for next release - this is crititcal to be able to release Loss datasets.
@stufraser1 should we plan a crunch on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Under discussion
Development

No branches or pull requests

3 participants