GFDRR / thinkhazard

ThinkHazard!
http://thinkhazard.org/
GNU General Public License v3.0
32 stars 19 forks source link

Enabling two-entries layer: view and rank override #880

Open matamadio opened 4 years ago

matamadio commented 4 years ago

Related to https://github.com/GFDRR/thinkhazard/issues/879

There are cases in which we want to be able to override the TH ranking algorithm in some way. One alternative way to do that could be by providing a secondary layer, consisting of a raster (or a point feature) representing the centroids of ADM2 units. This is required when: 1) the set of data does not fit with the current classification script and requires different algorithms (e.g. ARUP landslide layer, FATHOM) 2) the licensing of the data don't allow to share the full dataset, but only the aggregated ADM2 value (e.g. FATHOM)

The idea then is to have a "view" layer that represents the original hazard raster data when clicking "show source data", and an optional supplementary "rank override" layer that includes pre-processed TH values (1 to 4) as centroid points, either as tif or feature points (shp, csv). Whenever this optional centroid layer is added (via admin page?), that is used for classification instead of original dataset.

matamadio commented 4 years ago

After internal discussion, we decide that the use of a double-entry layer may be not as efficient and flexible for future needs. It is suggested to focus on a more flexible hazard ranking script within TH instead of rely on this workaround. First, as a test, we want to implement a new processing approach on our new LandSlide layer (this can be hardcoded because we would need it as soon as possible). In this test, the processing goes as follows:

For ADM2
    apply threshold on raster values using 80th percentile
    extract MAX

In this way, the hazard rank we show in our maps will be the same as the one depicted in the dataset report maps.

If this approach is successfull (works as intended without requiring much additional time to calculate) we may want to apply it to all layers.

Ideally, the parameters for hazard ranking (valid value range, ignore values, threshold filter, hazard classes range) should be all specified for each hazard type/subtype in the yaml file. In this way we can better adapt the assessment according to the source data, withouth having to edit the original data (deprecated) and reharvest.