Closed odscjen closed 11 months ago
Good point - some vulnerability relationships relate to only a general occupancy type e.g. 'residential', 'commercial', 'industrial'.
Either we (1) assign taxonomy type based on this - we can create one in ODS/GEM taxonomies for general residential with all other taxonomy string components as unknown, or (2) make taxonomy optional and fall back on the occupancy type only - which now I look for it, isn't within the schema or codelists (was this removed, we had it in at one point).
We need some way to tie the V relationships to a type of exposure - and using exposure_ctegory
to tie it to 'buildings' is not enough.
We did remove occupancy type as this isn't necessarily always the same across every asset in a dataset.
vulnerability.taxonomy
as it stands doesn't hold the actual taxonomy codes (for the same reason of them not being the same across every asset in a dataset), it gives the name of the scheme that the taxonomy codes in the dataset are taken from, e.g. GED4ALL.
Taxonomy should be optional, because exposure grouping is often custom.
some vulnerability relationships relate to only a general occupancy type e.g. 'residential', 'commercial', 'industrial'.
That is true, yet datasets could include one or more of these occupancy types. Right now we identify only category
(buildings, infrastructure, agriculture, population, natural environment). Occupancy type would refer only to buildings.
I would keep occupancy details as part of data instead of metadata - at least for this release.
Not having this in the metadata reduces search capability - it is useful for users searching V functions to filter by those suitable for Residential buildings, or by a certain construction type, for example (see OpenQuake tool example), but yes by including in metadata we potentially introduce long string / array of occupancy types
For this iteration of the standard I think we should make it optional. The next version of the standard could look to work out if occupancy is worth putting back in, and in conjunction making taxonomy
(the name of the taxonomy scheme) required. @matamadio @stufraser1 is this okay?
@stufraser1 are you okay with the above suggestion?
From example being developed in https://github.com/GFDRR/rdl-standard/issues/135#issuecomment-1686621456 the dataset doesn't have a specific taxonomy scheme that it's used. Should we make this field optional instead of required?
If it does need to stay as required we should add a code to 'classification_schema.csv' to cover these scenario's for consistency and add a bit to the guidance to state what to use in this situation.