Satellite-Based Water Change Detection: Monitoring Anomalies
Water change detection is one of the most critical applications of modern remote sensing. As climate volatility increases, the ability to accurately quantify surface water extent and soil moisture levels has become a priority for hydrologists, agricultural practitioners, policymakers and urban planners alike. Utilizing multi-spectral (Sentinel-2) and Synthetic Aperture Radar (Sentinel-1) data, we can now map hydrologic anomalies (droughts or floods) with unprecedented precision.
In the DaFab project, the water change detection workflow is used to enrich satellite data with additional parameters that indicate flood or drought in the scenes. It helps in optimizing the search, automating the selection of the past flood or drought events visible in Sentinel-1 / Sentinel-2 images and finally monitoring, analysing the affected areas from the generated water masks.
From AI Outputs to Searchable Knowledge
The role of SKIM in DaFab system architecture
Introduction: Turning a Copernicus data scale archive into something you can search
Copernicus has grown into an archive where the limiting factor is rarely the availability of pixels, but the ability to find the right ones. To do so, users still have to start from copernicus product descriptors (e.g. Sentinel-2 tile, date, processing level, etc…) and only later test whether the data contains the signal of interest. DaFab system addresses this gap by generating secondary, AI‑derived metadata at scale and exposing it as a discovery surface, so that users can begin with a thematic question instead of beginning with file selection (e.g. “How many agriculture parcels are there ?” in smart-agriculture thematic and “Where can I find water anomalies ?” for water-analysis one).
Multi-Cluster Workflow Execution with Karmada and Argo Workflows
In our previous DaFab post, we introduced the overall multi-site orchestration vision. This entry focuses on a specific architectural building block: integrating Karmada with Argo Workflows to enable multi-cluster and multi-site workflow execution driven by rule-based placement. The key outcome is that workflow steps can be dispatched to different Kubernetes clusters (sites) based on explicit rules that reflect data locality and computing resource availability goals, without changing how users author workflows.