SARFinder

SARFinder

When a flood or an earthquake happens, the first question is always the same: has a radar satellite already looked at this place, and when will it look again? SARFinder answers it. It sits at sf.earthobservatory.sg and gives the lab one place to search the Sentinel-1 acquisition plan, request processing over an area of interest, and watch the resulting products land.

Search that knows what is coming

The catalogue is not only what has been acquired. Scheduled jobs keep the Sentinel-1 acquisition plan, datatake status and SAR-MPC disclaimers current, so a search covers future passes as well as past ones — the difference between no data and data in eighteen hours.

From a drawn polygon to a running job

An area of interest becomes an Airflow submission. The backend reconciles what it dispatched against what actually ran, so the job list reflects the cluster rather than the last thing the UI was told. Finished ARIA-SG products are read out of S3 with their thumbnails and tiles, and event detection groups them against the disaster they belong to.

Alerting

GDACS alerts are ingested and matched against coverage, which is what turns the platform from something you visit into something that tells you to look.

Stack

Django 5.1 and DRF on Python 3.11, PostgreSQL and Redis, Celery worker and beat on the database scheduler, and GDAL, geopandas, shapely and rasterio for the geometry and raster work — all of it in Docker, with no supported bare-metal path. The frontend is React with CRACO (CesiumJS needs the webpack customisation), TanStack Query for server state, React Router v6, and Cypress end to end.

Ten Django apps carry the rest: the scene catalogue, S3 access, accounts, usage analytics, eco-integrity tiles, admin job triage, feedback, and emergency-response uploads.