ARGUS

ARGUS — Geospatial Intelligence for Everyone

Inspiration

Situational awareness has always been a privilege. The kind of real-time, multi-source geospatial picture that emergency managers, disaster responders, and military planners rely on costs millions of dollars and lives behind locked government intranets.

When a wildfire ignites near populated areas, responders are correlating wind data from one tab, flight restrictions from another, and seismic activity from a third — manually, under pressure, losing time. We asked a simple question: what if that picture already existed, and it was free?

That's ARGUS.

What We Built

ARGUS is a real-time geospatial intelligence platform that fuses live data streams into a single, unified operational picture rendered on a 3D globe.

Live data feeds:

✈️ OpenSky + ADS-B — real-time global flight tracking
🌍 USGS — live seismic activity worldwide
🛰️ CelesTrak — satellite orbital paths
🌦️ NOAA GFS — atmospheric data (temperature, wind, pressure)

Visual intelligence modes: Normal, Night Vision (NVG), FLIR thermal, and CRT — because context changes what you need to see.

Architecture split by purpose:

Local (Next.js + CesiumJS) — interactive 3D globe, real-time HUD, layer controls
VPS (Docker + PostGIS + TiTiler + Python) — heavy GRIB2 processing, spatial correlation queries, historical storage

Atmospheric data flows: NOAA GFS → GRIB2 → Cloud-Optimized GeoTIFF → PostGIS → TiTiler tiles → Cesium overlay

How We Built It

We used Claude Code (Anthropic) as the primary coding agent, with human orchestration driving every architectural decision. The concept, stack design, and feature priorities were ours — Claude executed the implementation at speed.

Stack:

Frontend: Next.js 16, React 19, CesiumJS, Zustand, TypeScript
Backend: Python, PostGIS (PostgreSQL + spatial extensions), TiTiler
Infrastructure: Docker Compose on VPS, proxied API routes for CORS handling
AI Tooling: Claude Code for architecture + code generation

The hardest design decision was the local/VPS split. CesiumJS demands GPU responsiveness — you can't run it well on a server. But GRIB2 atmospheric file processing (200MB+ files) is brutal on a client machine. So we separated concerns cleanly: the browser handles visualization, the VPS handles heavy compute.

Challenges

GRIB2 parsing is a nightmare. NOAA's atmospheric data format is dense, poorly documented outside meteorological circles, and requires a full Python stack (cfgrib, xarray, rasterio) just to extract useful values. Getting wind vectors to render as actual overlays on the globe took three full iterations.

CORS on public APIs is inconsistent. Several feeds have partial or broken CORS headers. We solved this by routing all external feed requests through local Next.js API proxy routes — cleaner architecture anyway.

Data volume vs. responsiveness. At scale, streaming all live flights globally while rendering atmospheric tiles and seismic markers simultaneously creates real render budget pressure. Zustand's selective subscriptions and Cesium's primitive batching kept it smooth.

What We Learned

Public geospatial data is shockingly rich — the bottleneck isn't data availability, it's synthesis
The split-compute architecture (interactive local, heavy VPS) is the right pattern for real-time geo applications
AI-assisted development at this scale works best when the human owns the what and the AI owns the how fast

What's Next

Spatial correlation engine: correlate flight anomalies with seismic events and atmospheric pressure in real-time
Historical replay for incident reconstruction
Alert system for configurable thresholds (flight deviations, seismic magnitude, wind shear)

ARGUS is live at argusweb.bond

Want me to tighten any section, punch up the tone, or add/remove anything before you paste it in?