Allow Exposures.from_raster to set Exposure metadata #1091
Conversation
|
Tests are failing but I'm not sure they're related to the proposed change |
|
@ChrisFairless thanks for the suggestion.
|
|
Changelog updated! Regarding your question about whether we should be able to set non-metadata properties through this new parameter: my thinking was to restrict it to the metadata parameters so that we don't have to write a lot of code to police the unexpected things someone might provide through this call. However, reading the So ... let's remove the restriction? The danger is that someone provides e.g. cover and deductible info through I'll make the change, but will revert it if anyone wants to be more careful. |
Previously we only let the attrs parameter set Exposures metadata attributes. We remove this restriction so that it can specify any parameter in the Exposures.__init__ method.
Good! @emanuel-schmid any objections to this solution? If not, please feel free to merge. Thanks! |
Changes proposed in this PR:
attrsparameter to theExposures.from_rasterclass method, analogous to theHazard.from_rastermethod. In this method theattrsparameter is a dictionary that is used as additional keyword arguments in the subsequent call of the__init__.Exposures._metadatalist["description", "ref_year", "value_unit"]. Other arguments taken byExposures.__init__method are either already provided by thefrom_rastermethod, or could make a mess (e.g.lat,lon,value). In the current implementation, they are dropped quietly – should there be a warning too?Hazard.from_rastermethod takesattrsas one of its first parameters, here I've addedattrsas an additional, final parameter. I think it i's less likely to break stuff and the end is usually where a**kwargsgoes anyway.PR Author Checklist
develop)PR Reviewer Checklist