Audience: Local disaster managers, community leaders, NGO staff, field teams, and analysts who can use web tools; works in low bandwidth settings.

Prerequisites: Web browser; a group communication channel (WhatsApp, SMS tree, radio contact); basic spreadsheet skills.

Data & Tools:

• Google Flood Hub (forecast flood risk by location)
• Copernicus GloFAS (riverine flood forecast and monitoring)
• GFMS (satellite-rainfall-driven flood signal and rainfall totals)
• NASA Worldview (to view and export flood and rainfall layers)
• GPM IMERG precipitation (to confirm recent upstream rainfall)
• SMAP soil moisture (to understand how saturated the ground is)
• A simple AOI reference map (villages, roads, rivers); a shared Google Sheet (or notebook) as an incident log; WhatsApp/SMS for alerts.

Steps:

1. Define the Area of Interest and watch points. Write down the districts, watersheds, or communities that matter. Add a short watch list of 10–30 named places: key river towns, bridges, clinics, camps, and known floodplain villages. Put these in a sheet with columns: Name | Type | Coordinates | Notes (why it matters).

2. Pick two forecast views and one confirmation view. Choose one forecast dashboard that covers the AOI (Flood Hub and GloFAS both can) and one “reality check” source for what is already happening (satellite flood layers and rainfall).

3. Set simple triggers tied to what the dashboards actually show.

   • In Flood Hub, triggers are easiest when tied to the categories and return periods shown for a location. A “1-in-20 year” or worse return period is a strong signal of severe flooding risk, but it is still a probability statement, not a promise.

   • In GloFAS, use the “exceedance probability” view if available. A practical trigger is “forecast indicates a high chance of exceeding a high return period” for a watched river reach, plus local vulnerability (settlements on the floodplain).
     Write the triggers as a short SOP in plain language and keep them consistent.

4. Add rainfall context before sending an alert. Check IMERG rainfall totals upstream for the last 24–72 hours. In practice, look for heavy totals that match the basin size (small basins respond to short, intense rain; large basins respond to multi-day totals). If rainfall is light but the forecast is extreme, treat it as a “watch” and look for model disagreement.

5. Check soil saturation to avoid “surprise runoff.” Use SMAP to see if soils are already wet. A wet signal means less rainfall is needed to produce flooding. A dry signal means flooding may still happen, but it often requires more sustained rainfall or upstream release. Log “wet / normal / dry” for the AOI in the incident sheet.

6. Confirm with satellite floodwater layers when possible. In NASA Worldview, add the near-real-time flood layers (search for “Flood NRT” in the layer list), choose the latest day, and compare to what is normally water in that area. Treat this as confirmation of surface water extent, not a perfect boundary. Cloud and terrain shadow can still confuse optical flood mapping, so do not rely on a single frame for a high-stakes call.
   If cloud is persistent, use radar-based water extent when available (DSWx-S1 is designed to map surface water regardless of clouds and night).

7. Send a short alert that separates “forecast risk” from “observed flooding.” Use a consistent template:

   • What: Flood Watch or Flood Alert

   • Where: place names and river reach

   • When: forecast window plus “as of” time for any observed flood layer

   • Confidence: forecast-based, confirmed by rainfall and/or satellite, or unconfirmed

   • Action: monitor, prepare to move assets, check routes, pre-position staff

8. Log outcomes and refine triggers weekly. Track false alarms and misses. If alerts are frequent but impacts are minimal, tighten triggers (higher return period, add rainfall threshold, require soils “wet”). If floods are missed, loosen triggers or add a second check time.

Outputs: A daily monitoring log, a repeatable SOP, and a consistent alert message format.

Validation & QA: Compare forecasted risk vs observed floodwater (Worldview flood layers) and local reports. Review at least 5 events after the season: what was detected early, what was detected late, and why.

Maintenance: Update the watch list, contact lists, and SOP every season. Re-test links and dashboards after long inactive periods.

Risks & Considerations: Cloud cover (optical flood layers), model uncertainty, and communication outages. Make it clear that forecasts are probabilistic and that confirmation steps can lag by hours to days depending on satellite overpass and processing.

Audience: NGO ops teams, emergency operations centers, small GIS teams, and technologists comfortable with spreadsheets and no-code automation tools.

Prerequisites: A Google account (Sheets); one no-code tool (Make, Zapier, or Apps Script); a messaging method (email, SMS, WhatsApp Business).

Data & Tools:

• CAP alert feeds (from national or regional agencies, where available)
• USGS National Water Dashboard (US gauges) or local gauge portals
• NOAA National Water Model (US streamflow forecasts) if operating in the US
• GloFAS / Flood Hub as a forecast “flag” source (manual at first, automated later)
• Google Sheets (configuration + event log); Make/Zapier/Apps Script; WhatsApp/SMS/email delivery

Steps:

1. Create a single configuration sheet that controls everything. Tabs:

   • Watchlist: Name | Type (river, town, facility) | Lat | Lon | Admin area | Notes

   • Thresholds: Watchlist Name | Trigger type (CAP, gauge, forecast) | Threshold | Severity mapping

   • Recipients: Group name | Channel (email/SMS/WhatsApp) | Contact list

   • Templates: Message template text with placeholders (Location, Time, Source, Severity)

2. Start with two automations that are reliable in most countries.

   • CAP polling: Many agencies publish CAP feeds; the automation checks every 10–30 minutes, filters for flood-related alerts, and logs new items.

   • Gauge threshold checks: If gauges are available (USGS in the US, or another national service), pull the latest value and compare to thresholds in the sheet.

3. Normalize every trigger into one “event record.” Write each trigger to a single Event Log tab with columns: Event ID | Timestamp | Source | Location | Severity | Confidence | Link | Action status. This makes deduplication and auditing easy.

4. Add a lightweight forecast flag without trying to automate everything on day one. Many teams lose time trying to scrape forecast dashboards. A cleaner approach at this stage:

   • A human checks Flood Hub or GloFAS once daily.

   • If a watch threshold is crossed, they add one row to a “Forecast Flags” tab.

   • The automation treats that row like a trigger and sends a prepared message.

5. Include a satellite confirmation checklist in the outbound message. For any medium or high alert, the message should include one line that tells the recipient how to confirm quickly in Worldview:

   • “Worldview: add Flood NRT layer and check latest date for this location”

   • “IMERG: check last 24–72h rainfall upstream”

6. Decide when the system sends automatically vs when it waits for review. A practical rule:

   • CAP alerts: send immediately (these are official warnings).

   • Gauge exceedance: send immediately if it is a high threshold; otherwise log and wait for a second check.

   • Forecast flags: require a human review until the team is confident.

7. Tune thresholds using the log. Every two weeks, sort the log by “false alarms” and “misses,” then update thresholds. Keep the SOP simple and consistent.

Outputs: Automated alerts for official warnings and gauge thresholds, plus a single event log for reporting and improvement.

Validation & QA: Confirm the automation is not duplicating alerts (same CAP item repeatedly). Run a weekly test by forcing one “test” event and verifying delivery to each channel.

Maintenance: Update recipient lists, check feed links, and review message templates each season.

Risks & Considerations: CAP coverage varies by country; some areas will have no CAP feed. Gauge data availability also varies. Treat this as a modular system that works with whatever official feeds exist and improves over time.

Audience: GIS technicians and generalists using QGIS or ArcGIS; small teams that need fast briefing maps during an event.

Prerequisites: QGIS installed; basic GIS operations (clip, buffer, raster stats); internet for data download.

Data & Tools:

• VIIRS/MODIS near-real-time flood extent (Flood NRT GeoTIFF or Worldview export)
• DSWx-S1 surface water extent (radar-based, cloud independent) for confirmation where available
• ESA WorldCover (to separate built-up, cropland, water, etc.)
• WorldPop (population exposure)
• Admin boundaries and key infrastructure layers (roads, clinics, camps if available); QGIS print layout template

Steps:

1. Prepare a QGIS template once. Load admin boundaries, main roads, and a basemap. Set a working CRS appropriate for distance and area in the AOI. Save as “FloodBriefingTemplate.qgz.”

2. Bring in observed floodwater. For speed, use Worldview to export the Flood NRT GeoTIFF for the event date and AOI, then add it to QGIS. Interpret it as “observed surface water / flood extent signal,” not a depth map. If the AOI is cloudy or the flood is under vegetation, add DSWx-S1 when available because radar can map water through clouds and at night.

3. Remove permanent water so the map highlights “new water.” Use WorldCover’s water class as a permanent-water mask. Subtract or hide pixels that are normally water, so the briefing focuses on likely flood expansion into floodplains and settlements.

4. Convert floodwater to a clean briefing footprint. Polygonize the flood raster (or threshold it first if needed), dissolve small fragments, and keep a minimum mapping unit that matches the briefing purpose. Label the footprint clearly as “satellite-derived observed water extent, date/time.”

5. Calculate exposed population. Use zonal statistics to sum WorldPop population within the flood footprint and within a buffer (for near-term risk). Report both numbers if helpful: “inundated area” and “nearby within 2 km.”

6. Describe what land types are impacted. Intersect the flood footprint with WorldCover classes to estimate how much flooding overlaps built-up areas and cropland. This makes the map more decision-ready without adding extra layers.

7. Export a one-slide map plus a short stats box. Keep the layout simple: flood extent, key towns, rivers, admin names, and a text box with the 3–5 most important numbers (people exposed, built-up overlap, major roads affected if known). Export PNG for slides and PDF for print.

Outputs: A situation map (PNG/PDF) and a short exposure summary (population and land cover overlap).

Validation & QA: Confirm the CRS and units. Cross-check the flood footprint against rainfall context (IMERG) and at least one operational dashboard view (GloFAS or Flood Hub) to ensure the event is plausible.

Maintenance: Keep the QGIS template and baseline layers current. Re-test the workflow once per season using a past event.

Risks & Considerations: Optical flood layers can misclassify cloud shadow or dark terrain as water. Radar-based water layers can miss narrow water or confuse very rough surfaces in some conditions. Treat both as strong indicators that still benefit from local confirmation.

Audience: Regional tech hubs, NMHS teams, universities, and small analytics groups with hydrology and data skills.

Prerequisites: Earthdata Login; Python and/or QGIS; comfort working with rasters, time windows, and basic automation (scheduled runs, logs, notifications).

Data & Tools:

• GPM IMERG V07 precipitation (Early/Late for monitoring, Final for tuning and after-action analysis).
• SMAP soil moisture (surface and, if needed, root-zone products) to represent antecedent wetness and runoff sensitivity.
• OPERA DSWx-S1 surface water extent (Sentinel-1 SAR) to confirm inundation through clouds and at night.
• Basin and river network boundaries (HydroBASINS/HydroRIVERS or a national hydrography dataset) to make triggers “basin-tuned” instead of generic.
• Terrain: DEM plus a floodplain proxy such as HAND (or a locally accepted equivalent) to reduce false positives outside flood-prone areas.
• Exposure layers: admin boundaries, settlements/buildings, and population (WorldPop or official census surfaces) for prioritization and reporting.
• Tools: QGIS for quick review and map outputs; Python (local or Colab) for data pulls, rolling-window calculations, and alerting; a notification channel (email, Slack/Teams webhook, WhatsApp/SMS gateway).

Steps:

1. Define the unit of action and the “who gets notified” list
   Start by choosing the operational unit that decisions will be made on: basin, sub-basin, river reach, or admin unit. Basin-first is usually best for rainfall and soil moisture because it matches how runoff accumulates. Create a small reference table with ID, name, downstream communities/assets, and recipients. This table becomes the backbone for automation and for consistent messaging.

2. Build a simple event catalog before touching thresholds
   Compile past flood dates and affected areas using whatever is available: partner sitreps, national disaster reports, gauge peaks (if present), and quick-look flood maps. Pull the matching satellite context for those events so the catalog includes “what happened” and “what the data looked like.” For each event, store at least: date range, basin/admin IDs, and a confidence rating (confirmed, likely, unclear). This becomes the truth set used to tune triggers and measure false alarms.

3. Turn IMERG into basin rainfall features that a trigger can use
   IMERG is half-hourly precipitation, which is ideal for rolling totals. For each basin, compute rolling 24-hour, 48-hour, and 72-hour accumulations, plus one intensity feature such as the maximum 1-hour rainfall within the last 24 hours. Use Early or Late for near-real-time monitoring, then switch to Final during reviews to tune thresholds against confirmed events. The first version of the trigger can be as simple as “72-hour basin rainfall exceeds a basin-specific threshold,” but the key is that the threshold is not the same everywhere. Mountain basins, urban basins, and flat floodplains often need different trigger levels even inside the same country.
   Practical access: use GES DISC subsetting for AOI/time downloads (GeoTIFF/NetCDF) for scripted pulls, and Giovanni for quick visual checks and exports when validating events.

4. Use SMAP as the wetness modifier and explain it plainly in outputs
   SMAP answers “how close is the ground to saturation,” which changes how much rainfall is needed to produce flooding. Convert SMAP to a basin wetness class that non-specialists can interpret. A good starting approach is percentile-based: for each basin, compare today’s SMAP soil moisture to a multi-month or multi-year distribution and label it dry / normal / wet / very wet. Then apply a simple modifier to the rainfall trigger, such as lowering the rainfall threshold when soils are very wet, and raising it when soils are unusually dry. This makes alerts feel more “local” and reduces obvious false alarms.
   Practical access: pull an L3 daily SMAP product via NSIDC with Earthdata Login, using the “Customize” option to crop to the area and output format that will load cleanly in GIS.

5. Design the trigger ladder for action, not just detection
   Create two or three alert levels with clear intent:

   • Watch: rainfall building and soils supportive of runoff; prompts increased monitoring and partner check-ins.

   • Warning: rainfall threshold exceeded with wet soils; prompts readiness actions and targeted community messaging.

   • Escalation: rainfall extreme or rapidly intensifying; prompts immediate coordination steps and a request for rapid confirmation layers.
     Keep the logic readable in one paragraph in the SOP, and keep the numeric thresholds in the table. The SOP should also define de-duplication rules so the same basin does not spam recipients every run.

6. Add SAR confirmation with DSWx-S1, and treat it as “evidence,” not a replacement
   When the trigger fires, the workflow should immediately prepare a confirmation task. DSWx-S1 is valuable because SAR can see water through clouds and at night, and the product provides surface water extent at about 30 m with revisit driven by Sentinel-1 acquisitions (often 6–12 days).
   How to use it in practice:

   • Pull the relevant tiles for the event window from PO.DAAC (or scripted access if running at scale).

   • Compare against a baseline water layer to separate “normal water” from “new water.” If a permanent water mask is not available, build a simple baseline from recent DSWx-S1 scenes outside the event window.

   • Clip the resulting inundation extent to plausible floodplain areas using HAND (or a local floodplain mask) to reduce radar dark-surface confusion in places like smooth soils, irrigated fields, or calm wet surfaces unrelated to flooding.

   • Export a partner-ready GeoPackage and a single-page map showing “triggered basins” and “SAR-confirmed water extent” as separate layers.

7. Automate the alerting end-to-end, including the message and the audit trail
   The “operational pipeline” should do more than compute risk. It should also send a clear message and write a record. A solid minimum automation loop is:

   • Scheduled run pulls latest IMERG and SMAP for each basin, recomputes rolling totals and wetness class, and evaluates the trigger ladder.

   • If a trigger crosses from not-fired to fired, the system generates: a short table (basin, rainfall totals, wetness class, level), a small map image, and a permanent link to the evidence folder.

   • The system sends one alert message per basin per level, with a consistent format: location, level, what changed, what action is expected next, when the next update will occur, and the evidence link.

   • The system appends a row to an incident log (timestamp, basin, level, rainfall, wetness, recipients, evidence links).
     This ensures alerts are actually operational, not just analytics.

8. Optional light ML that stays interpretable
   If there is enough historical catalog coverage, train a simple classifier to output a probability of flooding per basin-day using the same features already computed (IMERG rolling totals and intensity, SMAP wetness class, terrain summaries, distance-to-river). Keep it light and transparent: use a small boosted-tree model only if it clearly outperforms the rules and remains calibratable. Select the operating threshold using reliability checks so “0.7 probability” actually behaves like a high-risk bucket in practice.

Outputs: Calibrated basin thresholds (and optional probability model), a daily trigger table and map layer, an alert log, and a repeatable SAR confirmation package.

Validation & QA: Use a time-based split on the event catalog; track misses and false alarms by basin; spot-check a subset of events with VIIRS flood NRT and then DSWx-S1 confirmation when available; verify units and time windows so “24 hours” really means the same thing across datasets and time zones.

Maintenance: Monthly review of thresholds and performance, add new events to the catalog, monitor dataset latency and access changes, and periodically retest the alert delivery channel.

Risks & Considerations: SAR revisit gaps can delay confirmation; radar dark-surface confusion requires masks and local context; IMERG and SMAP resolution limits mean small urban flash floods can be under-represented; dependency on multiple feeds increases failure modes, so the SOP should include a fallback chain to simpler monitoring methods.