Expand analysis feature to allow comparison for different data types while also using operators

[wadhwamatic]

The current run analysis feature is limited for raster data using above / below thresholds, and simply providing area exposed for polygon hazard data. We need to expand the types of analysis which can be done across all data types (rasters, polygons, point), and to allow for analysis based on conditions beyond above / below thresholds.

Going beyond above / below thresholds, the use of operators (<, <=, =, >=, >) will add more flexibility to the analysis feature and be more useful for non-raster data. The screenshots below demonstrate examples of how operators could be applied to various data types.

1. Raster analysis of flood data (categorical variable) based on a specific value (1, flooded) to evaluate the number of pixels that are flooded per admin area.
   

2. Analysis of raster data with continuous values, in this case rainfall estimates. With a >= operator, this analysis would identify how many pixels exceeded a threshold selected from a predetermined list of values
   

[jbperidypathtech]

@ericboucher @wadhwamatic. Can we have example of backend url to call? With different operators >, =, <=.

curl 'https://prism-api.ovio.org/stats?intersect_comparison=value' \
  -H 'authority: prism-api.ovio.org' \
  -H 'accept: application/json' \
  -H 'accept-language: fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7' \
  -H 'cache-control: max-age=0' \
  -H 'content-type: application/json' \
  -H 'origin: http://localhost:3000' \
  -H 'referer: http://localhost:3000/' \
  -H 'sec-ch-ua: "Not.A/Brand";v="8", "Chromium";v="114", "Google Chrome";v="114"' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'sec-ch-ua-platform: "Linux"' \
  -H 'sec-fetch-dest: empty' \
  -H 'sec-fetch-mode: cors' \
  -H 'sec-fetch-site: cross-site' \
  -H 'user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36' \
  --data-raw '{"geotiff_url":"https://api.earthobservation.vam.wfp.org/ows/?bbox=92.2%2C9.7%2C101.2%2C28.5&coverage=hf_water_mmr&crs=EPSG%3A4326&format=GeoTIFF&height=2304&request=GetCoverage&service=WCS&time=2023-06-16&version=1.0.0&width=1100","zones_url":"https://prism-admin-boundaries.s3.us-east-2.amazonaws.com/mmr_polbnda_adm3_250k_mimu.json","group_by":"TS_PCODE","geojson_out":false}' \
  --compressed

Where do we want to configure the different values (for example 0 = Not flooded ; 1 = flooded)?

• Attached to the layer.json definition? Inconvenient a lot of duplication since we have to make this configuration in each wms definition for all countries.
• In a global file configuration? Inconvenient (and question) how can we join a wms layer to this global definition? It seems that wms layers of different countries are independent? I this is the case I think the good approach is the first one.

[wadhwamatic]

@jbperidypathtech - agreed, there's a lot of duplication of configurations across deployments, but that's ok operationally as we need to support as much local configuration as possible. So, keeping this config in layers.json is fine.

As an FYI - we had looked into simplifying the config process for common layers but this wasn't completed: #358