ClimateVision: A FastAPI and PyTorch Stack for Satellite Change Detection

The gap ClimateVision tries to close between Earth Engine and an alert

Google Earth Engine gives you a petabyte-scale archive and a JavaScript or Python client to query it. What it does not give you is a segmentation model, a tiling pipeline, an HTTP contract, or a place to store which organisation asked about which region. ClimateVision is an attempt to supply that missing middle layer for three specific tasks: deforestation, arctic ice melt, and flooding. The README names conservation NGOs and researchers as the intended users, and the feature list backs that up with NGO registration, region subscriptions, and threshold-based alerts over email or webhook. That is a coherent audience. A small conservation group with a GIS analyst but no ML engineer can plausibly take a bounding box, POST it, and get a mask back. The scope is deliberately narrow: three active analysis types, two planned (drought and wildfire), and a fixed set of spectral bands per task. Narrow scope is the right call here. A platform that tried to cover every land-cover task would need a model zoo and a labelling pipeline, and neither appears in the material.

How the inference path is assembled: Earth Engine, tiling, U-Net, Siamese

The architecture visible in the README has four stages. First, Google Earth Engine fetches Sentinel-2 or Landsat scenes for a bounding box and date range, applying cloud masking and normalization. Second, the pipeline tiles the result into 256x256 patches. Third, PyTorch models run inference: a U-Net for semantic segmentation and a Siamese network for change detection between two dates. Fourth, FastAPI exposes the result, and the React dashboard renders it on a map with confidence gauges and Recharts analytics. The band selection is task-specific rather than uniform. Deforestation uses B02, B03, B04, and B08, which is blue, green, red, and near-infrared, the standard vegetation combination where NIR reflectance separates forest from cleared ground. Arctic ice uses B11 (short-wave infrared) instead of B08, and flood detection uses B03, B08, and B11. Those choices are consistent with how water and ice behave spectrally, and they imply the tiling step must select bands per analysis type rather than slicing a fixed stack. ONNX export is listed for production inference, so there is a path away from the PyTorch runtime, though the README does not state whether the API serves the ONNX graph or the PyTorch checkpoint by default. That is a detail worth checking in the code before you plan a deployment.

Getting a prediction out of the API in one request

The README's quickstart is three commands and one HTTP call. Clone the repository, install dependencies with pip install -r requirements.txt, then start the server with uvicorn climatevision.api.main:app --reload --host 0.0.0.0 --port 8000. The prediction endpoint takes a JSON body with four keys: bbox as a four-element array in longitude and latitude order, start_date, end_date, and analysis_type. The README's example uses bbox [-60.0, -15.0, -45.0, -5.0] with a 2023 date range and analysis_type set to deforestation, which corresponds to a swath of the Brazilian Amazon. Interactive OpenAPI documentation is served at http://localhost:8000/docs, so you can inspect the full request and response schema without reading source. The dashboard runs separately: cd frontend, npm install, npm run dev, then visit http://localhost:5173. Note the split: the API and the dashboard are two processes with two package managers, and nothing in the README describes a combined production build. For tests, the contributing section gives pytest tests/ as the command, and pull requests are expected against the develop branch rather than main. That branch convention matters if you plan to vendor a fork.

The accuracy table is the weakest part of the repository

The performance table lists forest segmentation IoU and change detection F1 as in progress. Inference time is given as roughly 45ms per 256x256 tile on CPU, and API response time as under 100ms. Those two numbers are throughput figures, not accuracy figures, and they are the only quantitative claims in the README. For a change-detection platform aimed at conservation alerts, the missing metrics are the ones that decide whether the tool is usable. A deforestation alert with a high false positive rate wastes a field team's week; a high false negative rate means a clearing goes unreported. Without a published IoU or F1 on a held-out test set, you cannot reason about either. The README does point to MLflow tracking under logs/ for experiment history and says benchmarks will be updated as training runs complete, so the infrastructure for producing those numbers exists. Whether the logged runs contain usable checkpoints is something you have to check yourself. Treat the 45ms and 100ms figures as hardware-dependent claims from the maintainers, not as verified measurements.

Where the design breaks down: cloud cover, seasonality, and the wrong task

Deforestation detection in the tropics runs into cloud cover constantly. The README states that the pipeline applies cloud masking, which is standard, but masking removes pixels rather than recovering them. A one-year window over the Amazon may leave few usable composites for a given tile, and the README does not describe compositing strategy, gap filling, or how the model handles partially masked tiles. Seasonality is a second problem: a forest that loses leaves in a dry season can look spectrally similar to a cleared area, and a single-date U-Net has no way to distinguish the two. The Siamese network is the intended answer to change detection, but the README does not specify the time gap between the pair of dates it compares. Flood detection has a different failure mode. Water and flooded land share spectral signatures, and the distinction depends on context the model may not have at 256x256. If your question is about drought or wildfire, ClimateVision is simply the wrong tool today: both are marked Planned, with no active model. And if you need sub-weekly alerts on a small area, the Earth Engine query and tiling overhead may dominate the 45ms inference time, which is measured on tiles, not on end-to-end requests.

How it differs from using Google Earth Engine's own classifiers

The obvious alternative is to stay inside Google Earth Engine and use its built-in supervised classifiers, such as random forests or SVMs trained on labelled points, or the community land-cover products already in the catalog. The difference in approach is fundamental. Earth Engine classifiers operate on per-pixel spectral values and hand-engineered indices; they are fast to set up, run server-side without you hosting anything, and are well understood. ClimateVision instead ships convolutional models that learn spatial context across a 256x256 patch, which should help with texture-dependent classes like flooded land versus permanent water, and it gives you a local REST API and a dashboard you control. The cost is that you now own model weights, a PyTorch or ONNX runtime, a tiling pipeline, and a FastAPI process. You also take on Earth Engine authentication and quota management on top of that. For a team that already has an Earth Engine workflow and only needs a threshold on NDVI or NDWI, adding ClimateVision is more moving parts than the problem requires. For a team that needs a spatial model and an alerting interface, the extra layer is the point.

Licence, maintenance, and what a fork actually costs you

ClimateVision is MIT licensed, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are retained. That is the permissive end of the spectrum, and it means you can embed the API in a paid service without a copyleft obligation. It says nothing about the data. Sentinel-2 and Landsat access through Google Earth Engine is governed by Earth Engine's own terms and by the individual data providers' policies, and the MIT licence on this repository does not extend to either. On maintenance, the repository is not archived and the last push is dated 2026-08-28. There are no retrieved releases, but the citation block gives version 0.2.0, so the project is pre-1.0 and the API surface should be expected to move. The contributor table lists ten contributors with merged pull requests, and the contributing guide asks for PRs against develop. If you fork, you inherit the requirement to track that branch, plus the two-package-manager split between the Python backend and the React frontend. Upgrading means re-testing both. There is no changelog in the material, so pinning to a commit hash is the safer approach than tracking main.

Editorial conclusion

Adopt ClimateVision if you want a working scaffold for tiled Sentinel-2 inference behind an HTTP API and are prepared to train or supply your own weights, because the README lists forest segmentation IoU and change detection F1 as in progress. Do not adopt it if you need validated accuracy figures or a dry-season deforestation baseline today; the repository publishes neither. Before committing, check the wiki and logs/ directory for MLflow runs, confirm which checkpoint the predict endpoint loads, and verify your Google Earth Engine credentials and quota cover the bounding boxes you intend to query.

Official sources

1. Climate-Vision/ClimateVision on GitHub
2. Issues
3. License: MIT
4. README