Geographic extent of data

[stufraser1]

Ensure data extent is included for all data (geom available at data point level) dataset level extent not available?

[stufraser1]

@mamadio @ConnectedSystems have we accounted for inclusion of data extent and does it make sense for this to be a metadata field if storing the file separately? The extent is provided already in the tif/shp metadata and gets loaded to e.g. QGIS, but do we require it in the schema itself, in addition to ISO3a code

[ConnectedSystems]

Yes, the extent is included for Hazard, Exposure, and Loss.

In the last iteration of the schema I implemented with SQLAlchemy, for example, the the_geom field for hazard.EventSet holds a polygon which holds the union of all extents for a submitted dataset.

The proof-of-concept I demoed had a tentative working implementation for the hazard schema (see here for code if curious). This handles import, assuming 1 metadata file per raster, assumed to be a tiff in this case but easy to extend to some other formats.

Checking with @matamadio Vulnerability is a special case which is why the field does not exist for the Vulnerability component.

But should it be a required element of the Schema itself? Probably not. Discussing it with @matamadio, it does seem more an implementation detail; to support map preview, search/filtering, etc.

[stufraser1]

OK, issue can be closed then? V does not have spatial data - applicability of the V relationship is capture in ISO codes. This is a point to consider though (related to putting ISO code in contribution field). A V curve may be applicable to multiple countries, beyond the country to which the project relates. We need to make sure we can handle this in the revision to contribution table / ISO fields. Stuart Fraser, PhD Disaster Risk Consultant http://disaster-risk.uk

…

On Fri, 12 Feb 2021 at 14:47, Takuya Iwanaga ***@***.***> wrote: Yes, the extent is included for Hazard, Exposure, and Loss. In the last iteration of the schema I implemented with SQLAlchemy, for example, the the_geom field for hazard.EventSet holds a polygon which holds the union of all extents for a submitted dataset. The proof-of-concept I demoed had a tentative working implementation for the hazard schema (see here <https://github.com/GFDRR/RISKi/blob/98c75e642bfca72f6bb26f6301db049804c61151/src/riski/hazard.py#L75> for code if curious). Checking with @matamadio <https://github.com/matamadio> Vulnerability is a special case which is why the field does not exist for the Vulnerability component. But should it be a required element of the Schema itself? Probably not. Discussing it with @matamadio <https://github.com/matamadio>, it does seem more an implementation detail; to support map preview, search/filtering, etc. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/GFDRR/rdl-data/issues/21#issuecomment-778238219>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC7PNYRQPC32WMAMDKSNNE3S6U5O5ANCNFSM4UJEVGLQ> .

[matamadio]

Well the extent is not currently implemented in MVP, as BBOX coordinates are not great by themselves but useful to display map extent preview, which we agreed is not part of MVP.
Should we look to add it on MVP based on PoC code, or look forward for having this in REdesign?

V does not have spatial data

I tend to agree, but cannot exclude exceptions (e.g a damage factor map used to multiply hazard).

applicability of the V relationship is capture in ISO codes. This is a point to consider though (related to putting ISO code in contribution field). A V curve may be applicable to multiple countries, beyond the country to which the project relates. We
need to make sure we can handle this in the revision to contribution table / ISO fields.

Yes, in fact I kept the fcore.country_iso applicability; the contribution.geo_coverage refers to country the model was produced for; the fcore.country_iso refers to all countries where the model can be applied to. This needs to be well explained in the guide.