akbargumbira
commented
9 years ago Hmm, we have implemented some of this in this PR https://github.com/AIFDR/inasafe/pull/1756 as the phase 1.
For the phase 2, these are some list that I have in mind:
- Streamline running an analysis. Streamline the process of running IF just by having its instance with requested extent and all qgis layers as the input. At the moment, the process of running an analysis is quite tedious (dock -> analysis -> impact calculator -> impact calculator thread -> calculate safe impact. Adding analysis handler class routines if the analysis is called from IF wizard). Necessary clipping will also be run in the IF class itself.
- IF Option Review. Review IF options and categorise them into:
- Option that should be in the IF e.g target field, threshold (for flood or tsunami), X, Y variables in the EQ IF
- Option that should be moved to layer's keyword e.g affected field and value selection This will need communication with Ismail and Borys related to metadata and keyword wizard work.
- IF Parameters Review Minimum Needs Configuration Postprocessors Options
- Finish other Report Mixin Population and Roads Report Mixin
We want to adopt a more OOP architecture for IF's using this example as a guide:
https://github.com/timlinux/impact_function_registry
The above is my working proposal for how we could approach a new IF architecture. Note that it is just a prototype and not functionally complete. In that architecture, every IF would inherit from base.py ( https://github.com/timlinux/impact_function_registry/blob/master) and IF will be initialised, have properties set for hazard, exposure, parameters etc. The prototype above addresses a lot of the things we already discussed like providing for pervasive metadata and reducing the amount of boilerplate code we have.
You will note there is a prepare() method in that method the subclass would 'do whatever is needed to classify its data'. Its not in the example but there should be a
run()method that would be the generic IF kernel.A subclass (e.g. ITB Earthquake) could overload the run method if it wanted to do things differently. And of course each if would implement impact() and tabulated_impact() this is where they would write IF specific keywords to the metadata class.
For style we would try to standarised styles so that e.g. @charlotte-morgan 's concern about different IF's writing out high - medium - low in different orders can be address (e..g some list low - medium - high).
@IsmailSunni and @lucernae I think this is a good place for the two of you to dive in would you be happy to take my prototype above and start integrating it?
I think some of the things in the prototype need updating since we have changed the architecture a little since.
We will just need to work to coordinate things as we will be stepping on each other's toes a bit.
I was going to suggest one thing you could do to phase it is to wrap the old if logic inside of the new ones. So by wrap I mean that in the IF package you also put a copy of the old IF. And then in run you actually just delegate a call to old IF. When everything is fine, we delete the old IF. That way we can port the IF's over after the main architectural changes are done, and we can do it in a phased way e.g. do all the flood IF's first, then the earthquakes and so on.