Oberon: Open-Source Earth Observation Monitoring

Earth observation should not require a vendor relationship. The European Space Agency publishes Sentinel-2 L2A imagery for free through STAC catalogs. The spectral indices for vegetation disturbance are documented in decades of remote sensing literature. And yet, if you want automated change detection over a land portfolio today, your options are: manually download tiles and analyze them in a GIS tool, or pay a proprietary SaaS API that does the analysis in a black box.

I built Oberon to fill that gap. It is an open-source, self-hostable pipeline that turns free satellite imagery into ranked, evidence-backed change findings. Zero vendor lock-in. Zero per-scene fees. Full provenance for every detection.

The Problem: Two Extremes, No Middle Path

If you work in land management, conservation, agriculture, or ESG compliance, you need to know when vegetation changes on land you monitor. Deforestation, crop stress, wildfire damage, illegal logging. The signal is in the satellite imagery. The question is how to extract it.

On one end, you have raw STAC catalogs like Copernicus and Earth Search. Free, public, comprehensive. But they hand you raw imagery tiles. You need a GIS engineer to download scenes, assess cloud cover over your area of interest, handle reprojection and resampling, compute spectral indices, threshold for change, and manually filter false positives. For each polygon. Each monitoring cycle.

On the other end, you have proprietary SaaS platforms. They automate the analysis, but behind a paywall. Your area-of-interest data goes to their servers. The change detection algorithm is opaque. You cannot audit why a finding was flagged or not flagged. And the pricing scales linearly with the number of scenes or polygons you monitor.

There was no middle path. No open-source tool that handled the full pipeline and produced trustworthy, auditable results. So I built one.

What Oberon Does

Oberon takes three inputs: an area of interest (GeoJSON polygon), a before window (date range), and an after window (date range). It returns ranked change polygons, spectral evidence, comparative imagery, and a provenance manifest for every finding.

The pipeline runs in seven stages:

• STAC discovery: search the Earth Search catalog for Sentinel-2 scenes covering the AOI, with timeout and retry.
• Scene quality triage: rank candidates by cloud cover over the AOI polygon, not the whole scene tile. Scene-level cloud percentages are misleading because a 30% cloud scene might be clear over your polygon.
• Windowed COG read: read only the AOI-bounded pixel window from the Cloud Optimized GeoTIFF, never downloading the full scene. SCL band masking removes clouds and shadows at the pixel level.
• Median compositing: when the best single scene does not have enough valid pixels (below 70%), automatically blend the top 3 candidates into a composite.
• Spectral baselines: compute NDVI (vegetation health), NBR (burn severity), and NDMI (moisture). These are the primary change indicators.
• Change detection: signed thresholding (only vegetation loss triggers findings for disturbance monitoring), morphological closing at 250m to consolidate fragmented detections, and spatial-variance seasonal filtering to reject uniform leaf-fall.
• Evidence bundles: each finding ships with GeoJSON polygons, before/after/overlay PNGs, and a provenance.json recording every scene ID, band, threshold, and config used.

Here is how fast you can get started:

git clone https://github.com/Farzin312/oberon.git
cd oberon
uv sync
uv run oberon analyze \
  --aoi sample-aoi.geojson \
  --before-start 2024-01-01 --before 2024-03-01 \
  --after-start 2024-07-01 --after 2024-09-01 \
  -o output/

That produces ranked change findings in output/, including before.png, after.png, overlay.png, findings.geojson, and provenance.json. Zero API keys needed.

Three Design Decisions That Make It Different

Most EO tools either wrap a proprietary model or expose a thin API over raw imagery downloads. Oberon was built differently, around three principles that drove every architecture decision.

1. Deterministic Baseline Before AI

Spectral indices like NDVI and NBR have decades of peer-reviewed literature behind them. They are deterministic, explainable, and reproducible. They should be the primary change detection signal.

Oberon includes an optional Clay v1.5 foundation model branch that runs as a parallel scoring layer. But AI must prove it improves over the deterministic baseline before promotion. In the current evaluation, AI ties the baseline on the 12 golden integration test cases. So the default pipeline uses zero language-model calls, and the AI branch stays experimental behind a --use-ai flag.

2. Abstention Over Confident Failure

Most EO pipelines produce a result no matter what. If the AOI is 90% cloud-covered, they still return change findings. They are wrong, but they are confident.

Oberon abstains. When inputs are poor (dense cloud cover, insufficient valid pixels, uniform seasonal senescence), it returns an explicit abstention with the reason. Exit code 0, message prefixed with "Abstained:". This is a valid analysis result, not an error. A monitoring system that says "I cannot tell this cycle" is more trustworthy than one that fabricates findings.

3. Provenance Is Product Data, Not Logging

Every finding includes a provenance.json that records: source scene IDs, bands read, processing configuration, threshold direction, morphological closing kernel size, spatial-variance CV score, seasonal risk annotation, model version, software version, and artifact paths.

A reviewer can trace any finding back to the exact satellite scenes and processing steps that produced it. This is not logging that gets rotated away. It is product data that ships with the finding.

Calibration: 12 Golden Tests, Honest Iteration

I built 12 golden integration test cases covering real-world scenarios: Amazon deforestation, Borneo palm oil expansion, California wildfire, Portugal fire damage, Iowa cropland change, Costa Rica cloud forest. Each test runs the full pipeline against live STAC imagery and checks the findings against expected results.

The first calibration pass scored 1 out of 12. The pipeline was over-flagging seasonal variation as disturbance. Four iterations later, using signed thresholding (only vegetation loss, not gain), morphological closing (250m consolidation), and spatial-variance CV seasonal filtering, it hit 12 out of 12.

Some test cases that initially failed were not calibration issues. Costa Rica cloud forest abstains because December has 9% valid pixels. That is correct behavior. Borneo palm oil has 25% valid pixels due to persistent cloud. That is a scene selection issue, not a calibration bug. Knowing when to stop tuning and ship what you have is part of honest engineering.

The Rust Control Plane

The open-source Python CLI works standalone. But for production monitoring of multi-polygon portfolios, you need a server: portfolio management, API key auth, job queues, a dashboard, alerts.

I built that in Rust. The control-plane directory contains an Axum server with SQLite (WAL mode, foreign keys enforced), SHA-256 API key authentication, a subprocess bridge to the Python pipeline, portfolio and polygon CRUD, a vanilla-JS + Leaflet web dashboard, webhook alerts with retry, and audit middleware that logs every request.

Deploy the full stack with one command:

docker compose --profile server up -d

That gives you the Rust server, Python pipeline, SQLite database, and web dashboard. Open localhost:8000 in your browser.

Where Oberon Fits

Oberon is designed for teams that need self-hosted, auditable Earth observation monitoring:

• Conservation organizations monitoring deforestation in protected areas.
• Agricultural platforms tracking crop health across grower portfolios.
• ESG and compliance teams that need evidence-backed audit trails for land change reports.
• Government agencies that cannot send area-of-interest data to third-party servers.
• Researchers who need reproducible, deterministic baselines for comparison studies.

Try It Yourself

Oberon is Apache 2.0 licensed. Clone it, run it, deploy it, fork it. Three paths to get started:

CLI mode: Zero cost, ad-hoc analysis. Clone, uv sync, run oberon analyze. No server needed.

Self-hosted server: Rust control plane + Python pipeline + web dashboard. One Docker command.

Full Docker stack: docker compose --profile server up. CPU or GPU variants.

The repo includes ready-to-use sample AOIs for Amazon deforestation, Iowa cropland, California wildfire, and Portugal wildfire, each with recommended date windows. Start there, then try your own polygons using oberon aoi to generate a bounding-box polygon from coordinates.

Oberon is 319 tests passing, 12 golden integration cases, and zero language-model calls in the default pipeline. It is the EO tool I wanted to exist and could not find. Now it does.

Star it on GitHub. File issues. Send PRs. The satellite imagery is free. The pipeline should be too.