Propose geographic threshold for trigger
hannahker opened this issue · 8 comments
We need to consider the number of admin regions that are required to be experiencing a dry spell for the trigger to be met. This parameter should be based on a historical analysis of the frequency of occurrence of various options so that we can propose a trigger for an event that is sufficiently extreme (for example, the even should be more extreme than having a likelihood of occurring every other year).
@joseepoirier in thinking through this issue I've realized that I could use clarification on a couple points relating to how the trigger would be acted on from an operational perspective, given that we are effectively going to be monitoring a number of different locations:
- Would an action plan for the trigger be developed at the same scale that we're monitoring (eg. admin 2 in this case), or would actions be taken throughout the entire Southern region?
- If actions are specific to an admin 2, would it theoretically be possible to trigger multiple times within the same monitoring period, but for different admin 2 regions?
@hannahker A trigger is always used to decide WHEN to act, not WHERE actions are implemented. Using better spatial resolution improves our ability to detect more localised shocks and provides information to partners as they plan their activities.
For your second point: let's talk this through.
Interesting question/response, look forward to discussing! A few other questions from my side as well:
Dry spell severity
When we discuss severity of a dry spell, is it more severity based on wider geographic spread or length of the dry spell? It seems there were just a few instances of intensely prolonged dry spells in the analysis document (up to around 20+ days or so). Are these "more severe", or is the 14 day period when most damage is already done and there's diminishing marginal impact for additional days afterward?
Admin2 vs. raster?
Looking at the graphs produced by Hannah of ARC2 resolution at the admin 2 level, I was thinking about why not to just directly use the rasters themselves for measuring geographical coverage of a dry spell. Given the lower resolution of ARC2, this might be more accurate. For instance, Zomba City looks to comprise only a single centroid and thus has 3 recorded dry spells whereas Zomba itself has none.
As well, just anecdotally from the data presented above, you could see a case where there might be a large swath of area in dry spell from northern Chikwawa through Thyolo to Mulanje, however it looks unlikely that any of those specifically would register as a dry spell at the ADM2 level.
I know y'all have tested various solutions so be interested to hear what you found, your reasons for going with ADM2, etc.!
@caldwellst good points here.
On severity: I think theoretically we can say that severity of a dry spell is a function of both duration and geographic extent. In this case, the 14-day threshold comes from our field partners and so this isn't a parameter that we have the flexibility to adjust, leaving us to 'tune' the geographic extent according to the severity of the shock that we're looking to capture.
On admin2 vs raster: @Tinkaa can probably weigh in here too, but my understanding is that we've aggregated to admin 2 as we need a generalizable way to geolocate dry spells as granularly as possible. Of course you're right in that defining a naturally occurring phenomena according to 'artificial' political boundaries can lead to results that are misleading. If we're defining our monitoring area as the Southern region (rather than each of the districts within the region), then it probably is more logical to identify dry spells using the same pixel-based approach that we've explored before and then define dry spells according to the % of the Southern district that is in a dry spell state. We'd still want to provide more specifics on where the dry spell is occurring, which could perhaps be done by checking which admin areas it overlaps with (and this could perhaps allow us to go down to the admin 3 level).
Key points from checking in with @caldwellst and @joseepoirier:
- Only a single disbursement of funds will be allocated for this trigger, so we won't trigger more than once in a monitoring period
- Given the current pilot stage, we probably want to stick with the currently implemented method of identifying dry spells according to aggregation within an admin region
- In defining a threshold for # of admin regions that need to have reached a dry spell state, we should consider whether this would be counted cumulatively or whether the dry spells need to be happening concurrently.
I also found in my notes just now another question I had wanted to ask but missed yesterday! In a few ADM2 areas in previously recorded years, the rainy season began after January 1. For our purposes, are we just going to assume that from January 1 the rainy season has begun for all ADM2 levels? Or are we going to be calculating the rainy seasons for each ADM2 and then only once it's been determined they've begun start measuring dry spell duration?
On admin2 vs raster: I think this is super valid @caldwellst, at same time would agree with Given the current pilot stage, we probably want to stick with the currently implemented method of identifying dry spells according to aggregation within an admin region
However, if the resolution is so low that 1 or none cells are within an admin, it might be worth to check if you also want to include any cell that touches the region. If that makes a huge difference an inbetween approach could also be to upsample the resolution.
Nevertheless, wouldn't spend the bulk of your time on this
@caldwellst Per our exchange earlier, there were few instances of rainy seasons starting in January. We excluded December dry spells because of the frequent rainy season onset in that month. For V1, we are assuming that Jan and Feb are in the rainy season. It is one of the things we want to fix / have a better workaround for in V2