3DGeoServEngine runs imagery and SAR exploitation as event-driven pipelines instead of operator-driven sessions. When a collect lands—via ingest, STAC discovery, or a folder drop—the engine matches it to a declarative workflow, runs change detection and target/anomaly detection, persists structured results, and raises alerts. No one has to be watching.
The exploitation orchestrator subscribes to the in-process event bus. Every stage is a capability call dispatched through the same governed path the in-app GeoAgent uses—so a pipeline step and an analyst’s natural-language request hit the identical validated code.
imagery.arrivedexploit_results linked to the STAC itemmetrics: count, confidence, change %timeline event + exploit.detectionalert rules (threshold + geofence)The starter pipelines fire automatically on arrival and require no code to extend. Drop a YAML file into the pipelines directory to override a built-in by id or add a mission-specific one.
eo_change_atrFor EO/RGB/NAIP/Planet/Sentinel-2/Landsat: change_detection over the prior collect, then atr_detect_batch (ONNX YOLOv8) over the changed pixels. Raises an alert when the detected vehicle count crosses a threshold.
Sensor: optical · Steps: change-detect → ATR · Acts on: vehicle count
sar_ccdFor SAR/Sentinel-1/Umbra/Capella/ICEYE: sar_change_detect (coherent change detection) between registered scenes. Raises an alert when the changed-area percentage crosses a threshold.
Sensor: SAR · Steps: CCD · Acts on: change %
Each step renders its parameters through templates that thread the new path, the prior path, and prior step outputs between stages. Compose the building blocks below into the sequence your mission thread requires; the orchestrator handles dispatch, async polling, cancellation, and result persistence.
Every block is a registered, schema-described capability reachable from a pipeline step, a GeoAgent request, or a direct API call. Optical, SAR, and hyperspectral paths are all first-class.
Pixel-diff, CVA, and IR-MAD change methods over co-registered optical collects, backed by the rasterio/numpy processing service. Outputs a change map and changed-pixel mask for downstream steps.
Amplitude Change Detection (ACD → RGB change map) and Coherent Change Detection (CCD → coherence map + change mask) between registered SAR scenes.
ONNX YOLOv8 detection (atr_detect / atr_detect_batch) over an image or a changed region, with confidence scores feeding alert thresholds.
RX anomaly (hs_anomaly_rx), ACE sub-pixel target (hs_target_ace), and Matched Filter (hs_target_mf) detection; SAM matching against USGS/JPL spectral libraries.
TOA reflectance atmospheric correction (atcorr_toa_reflectance) so cross-sensor and cross-date comparisons are comparable before differencing.
NITF 2.1 RPC image-to-ground mensuration pins a pixel detection to a lat/lon so an alert rule or a report carries an authoritative coordinate.
Beyond coherent change detection, the engine registers SAR scenes, runs interferometric jobs asynchronously, and ingests ground moving-target telemetry.
| Capability | What it does | Output |
|---|---|---|
| InSAR / DInSAR jobs | Async interferometric processing of registered SAR scene pairs | Coherence map, phase map, line-of-sight displacement map (cm) |
| InSAR coherence change detection | Detects coherence loss between scenes | Change mask + coherence raster |
| SAR scene catalog | Register scenes with satellite, pass date, orbit, incidence angle, polarization, bbox | Queryable catalog consumed by pipeline prior-collect resolution |
| GMTI ingestion (STANAG 4607) | Parse ground moving-target report dwell segments and target reports | Position, velocity, heading, target classification per report |
| Subsidence analysis | Time-series displacement from elevation/InSAR inputs | Subsidence raster and statistics |
Three independent arrival paths publish the same event, so the pipeline fires whether data is pushed, discovered, or dropped by hand. A generic async job store governs every run so a failure never wedges the orchestrator.
An S3 upload completing, a manual drop, or a WebDAV sync all publish imagery.arrived on the in-process event bus. The orchestrator subscribes and matches—no polling cron job to forget.
A five-minute background ticker republishes synthetic arrival events for STAC items newer than the last-seen timestamp, catching collects that appear without an explicit upload hook.
Templates match by sensor type, area of interest, and revisit window. Prior-collect resolution skips a run when no valid baseline exists within the revisit cap.
The async job store enforces a 60-minute timeout, recovers from panics to a terminal failure, retains a capped history, and cancels cleanly on context cancellation.
Every provider—exploitation, downloads, conversions—exposes its jobs through a shared read-only aggregator, so an operator sees all unattended work in one place.
The same backend runs as a Wails-free server binary behind systemd, a Windows Service, or a LaunchDaemon. That is what makes the pipeline unattended in production, not just in a desktop session.
A detection becomes operational when it reaches the right person in the right format. The alert fan-out ships today; the report builder is the same API-callable engine that generates analyst documents.
Every exploit.detection enters the alert engine, where threshold and geofence rules can route it through SMS, email, push, HMAC webhooks, the unified timeline, and a live WebSocket. The detection’s geo-location, confidence, and change metrics travel with it.
The report builder produces SITREP, INTSUM, Damage Assessment, Area Study, and Field Survey documents as PDF/HTML. Sections with an AI prompt auto-populate—photo vision enrichment, EXIF reverse-geocode, and an analyst-voice narrative. Wiring a detection to auto-generate a BDA/FSA report is an integration step, not a missing capability.
Explore the analytics layer →Acquire → process → analyze → alert and persist is fully unattended today. The final analyze → report link is a short, well-defined integration the operator assembles—both ends are shipping, API-driven services—rather than a built-in auto-trigger. We will show you exactly where that wire goes in during an architecture review.
The same exploitation surface is reachable however your environment works—unattended, on-demand, or conversational.
| Surface | Endpoint | Use |
|---|---|---|
| Status | GET /api/exploit/status | Orchestrator health and active pipelines |
| Pipelines | GET /api/exploit/pipelines[/{id}] | List or inspect declarative pipeline templates |
| Manual run | POST /api/exploit/run | Trigger a pipeline on demand (outside the event path) |
| Jobs | GET/DELETE /api/exploit/jobs[/{id}] | Poll or cancel async runs |
| Results | GET /api/exploit/results[/{id}] | Persisted metrics linked back to STAC items |
| Live | /api/exploit/ws | WebSocket stream of detections and run progress |
| Conversational | GeoAgent | Run any pipeline capability from a natural-language request through the shared dispatch path |