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

[Proposal] Socio-Economic Vulnerability layers are not hazard-related #238

Open
matamadio opened this issue Sep 1, 2023 · 5 comments
Open
Assignees
Labels
metadata Issues related to common, core metadata proposal New feature or request vulnerability Issues related to Vulnerability data

Comments

@matamadio
Copy link
Contributor

What is the context or reason for the change?

There vulnerability component has several mandatory fields meant to describe a vulnerability function, e.g. the type of hazard and exp they apply to.
In the same component, we also aim to accomodate se_category which is a different kind of object; not a function but a geospatial layer or just a table with location values. Some examples:

  • Relative Wealth Index (spatial wealth distribution)
  • Vulnerable population (census attribues by adm unit)

Since these aren't model that connect hazard and exp values, the mandatory attributes of the schema can't be met:
plantuml-cad5f6e1c2b28c2002f404123aeb540fc0b80a46 1

What is your proposed change?

I don't see many options. Either:

  • put all fields as non-mandatory. That would not be optimal when proper vln functions are entered.
  • separate the se_category from the rest of the vln schema alltogether

Suggestions are welcome!

@matamadio matamadio added proposal New feature or request vulnerability Issues related to Vulnerability data metadata Issues related to common, core metadata labels Sep 1, 2023
@duncandewhurst
Copy link
Contributor

From a non-expert point of view, it seems to me like that type of data better fits the description of exposure:

Metadata that is specific to datasets that describe the situation of people, infrastructure, housing, production capacities and other tangible human assets located in hazard-prone areas.

Would it make sense to model those as exposure datasets?

@matamadio
Copy link
Contributor Author

matamadio commented Sep 4, 2023

There's no right answer; indeed these are properties of exposure, but they are used to model its vulnerability (see paper example).
It might be easier to fit in the exposure schema, in terms of data type and associated properties.

@duncandewhurst
Copy link
Contributor

From today's check-in call, agreed that this requires further discussion and won't be done as part of 0.2.

@stufraser1
Copy link
Member

I agree it could fit into exposure, and #256, which creates exposure_category for social / economic indexes could address this, by allowing these index values as exposure category.

My suggestion: when data are clearly a social indicator like relative wealth index, it should be put into exposure.
When a vulnerability index combining multiple factors has been created to measure vulnerability specifically to one or more hazards, it can go into vulnerability.

@matamadio
Copy link
Contributor Author

My suggestion: when data are clearly a social indicator like relative wealth index, it should be put into exposure.
When a vulnerability index combining multiple factors has been created to measure vulnerability specifically to one or more hazards, it can go into vulnerability.

In practice, we need to understand how to fit it in the function-oriented V schema without dumbing it down.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
metadata Issues related to common, core metadata proposal New feature or request vulnerability Issues related to Vulnerability data
Projects
Status: Under discussion
Development

No branches or pull requests

3 participants