-
Notifications
You must be signed in to change notification settings - Fork 1
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
[Schema] Exposure costs and metrics #194
Comments
To me it is one of the most key information to provide for exposure; similarly to hazard |
This sounds as though we need a new object in addition to "metrics": {
"title": "Asset metrics",
"type": "array",
"description": "The non-monetary exposure metrics associated with specific elements of assets detailed in the dataset. If a metric is measured exclusively in monetary values use `cost`.",
"items": {
"$ref": "#/$defs/Metric"
},
"minItems": 1,
"uniqueItems": true
} where "Metric": {
"title": "Asset metric",
"type": "object",
"description": "The metric associated with specific elements of assets detailed in the dataset.",
"required": [
"id",
"type",
"unit"
],
"properties": {
"id": {
"title": "Identifier",
"type": "string",
"description": "A locally unique identifier for this metric.",
"minLength": 1
},
"type": {
"title": "Metric type",
"description": "The type of the metric, from the closed [cost type codelist](https://rdl-standard.readthedocs.io/en/{{version}}/reference/codelists/#cost_type).",
"type": "string",
"codelist": "cost_type.csv",
"openCodelist": false,
"enum": [
"structure",
"content",
"product",
"disruption"
]
},
"unit": {
"title": "Metric unit",
"type": "string",
"description": "The unit in which the metric is specified, from the open [impact_unit codelist](https://rdl-standard.readthedocs.io/en/{{version}}/reference/codelists/#impact_unit.",
"codelist": "impact_unit.csv",
"openCodelist": true
}
},
"minProperties": 1
} Is this object likely to be potentially needed anywhere else? If not it doesn't need to be in I think though if we go with this we'll need to revise some of the codelist names, rename 'cost_type.csv' to 'asset_type.csv' and rename 'impact_unit.csv' to 'metric_unit.csv'. My logic for the second of these is that impact is a specific type of metric but happy to have alternative names for this one suggested. Or alternatively @matamadio @stufraser1 is 'impact_unit.csv' not appropriate for this exposure metric and do we need an entirely new codelist for this field? |
Thanks for the proposal; I made a counterproposal splitting metric into 2 arrays: Exposure
If this makes sense:
|
Thanks, both. I'll have a think about modelling options. |
As discussed in #75 (comment), these are quantity kinds rather than units. Units would be things like square metres (for area quantities) or hours (for time quantities). I agree that it is more useful to model quantity kinds than specific units, since it should be possible to convert between units within a quantity kind (e.g. hours to minutes), but not between units of different quantity times (e.g. square metres to hours). I would name this field accordingly ( Can you share a link to a dataset in which the exposure metric is expressed as a quantity of density? I'm assuming you don't mean the QUDT definition of density, which is mass per unit volume so it would be good to work out what the correct quantity kind is. |
Agree - number of buildings / number of people / km of roads (e.g. per grid cell) are commonly used as well as total value (replacement cost / insured value) per grid cell or per building.
It is common in national level datasets and some global datasets, but maybe not in the ones used in examples so far. See Central Asia datasets, Africa R5, GEM's global exposure model, as just a few examples. It is also the case as stated that the value might be area or length or count.
Agree -- cost type or (monetary/non-monetary) value of the exposure needs to be readily visible in metadata.
This refers more to population density - relating number in a given geographic area. 'Count' would cover this - number of building / population, which would be given in the data as a count per raster grid cell. I haven't yet seen an exposure dataset with the value given as 'no. buildings per km2'. I think the suggestion from @matamadio works to make it clearer that we can include monetary and non-monetary values and the latter should include Area and Count. I don't think we need Time/Duration here as a metric. In my experience exposure isn't ever given a time value. We might estimate the disruption time as a loss, or (for insurance datasets only) identify an insured value for business interruption for a building, but we wouldn't record a unit of time in the exposure dataset - I can't think of an example where a road or building would be attributed a time value - it wouldn't mean anything practically. I would request that the data structure allows one or more of count, area AND cost to be included in the same dataset - I can point to examples where the cost is derived from one or both of area and count, and all pieces of data are included in the final data. |
Yes, sometimes costs are expressed as PPP of local currency into USD. Anyway, not strictly necessary.
Agree on this solution. |
Great so combining all of this we could remove {
"metrics": {
"title": "Asset metrics",
"type": "object",
"description": "The metrics associated with specific elements of assets detailed in the dataset.",
"properties": {
"monetary": {
"title": "Monetary asset metrics",
"type": "array",
"description": "The monetary exposure metrics associated with specific elements of assets detailed in the dataset.",
"items": {
"$ref": "#/$defs/Cost"
},
"minItems": 1,
"uniqueItems": true
},
"non_monetary": {
"title": "Non-monetary asset metrics",
"type": "array",
"description": "The non-monetary exposure metrics associated with specific elements of assets detailed in the dataset.",
"items": {
"$ref": "#/$defs/Metric"
},
"minItems": 1,
"uniqueItems": true
}
},
"minProperties": 1
}
} {
"$defs":{
"Metric": {
"title": "Asset metric",
"type": "object",
"description": "The metric associated with specific elements of assets detailed in the dataset.",
"required": [
"id",
"type",
"quantity_kind"
],
"properties": {
"id": {
"title": "Identifier",
"type": "string",
"description": "A locally unique identifier for this metric.",
"minLength": 1
},
"type": {
"title": "Metric type",
"description": "The type of the asset, from the closed [cost type codelist](https://rdl-standard.readthedocs.io/en/{{version}}/reference/codelists/#cost_type).",
"type": "string",
"codelist": "cost_type.csv",
"openCodelist": false,
"enum": [
"structure",
"content",
"product",
"disruption"
]
},
"quantity_kind": {
"title": "Quantity kind",
"type": "string",
"description": "The kind of quantity in which the metric is specified, from the open [quantity kind codelist](https://rdl-standard.readthedocs.io/en/{{version}}/reference/codelists/#quantity_kind.",
"codelist": "quantity_kind.csv",
"openCodelist": true
}
},
"minProperties": 1
}
}
} with the quantity kind codes taken as the most relevant selection in the QUDT quantity kinds vocabulary
One issue with this is that as it stands there isn't a way of expressing that a metric is relating to a population. Does it need to be added to the |
Thanks Jen. Agree on the solution, including renaming as |
It seems to me that there are more similarities than differences between monetary and non-monetary metrics so I would lean towards having a single metrics array. What are the advantages of separating monetary and non-monetary metrics in the data model instead of having a single metrics array and using the From a general usability point of view, there are some advantages to having a single metrics array: fewer sheets in the spreadsheet representation and I would've thought it would be easier for users to see all of the metrics in a dataset in a single list/table/sheet than to have them split into separate lists. However, happy to hear if there is a risk-specific reason for separating them! |
This does seem easier to use and communicate range of metrics and I don't think there is a need to have them in two lists/array |
Ok for single array grouping based on |
From GFDRR/rdls-spreadsheet-template#3 (comment):
@matamadio do analysts need to know the exposure metric at the point of selecting a dataset?
The text was updated successfully, but these errors were encountered: