OmniWatch: Fusing 48 Open Sources Into One Intelligence Dashboard

Situational awareness has always had a plumbing problem. The data is public — earthquake feeds, conflict event databases, vessel and aircraft transponders, wildfire detections — but it lives in dozens of different formats, schemas, and refresh rates. OmniWatch is an attempt to solve the plumbing: a self-hosted platform that normalises 48 public APIs into one event model and puts a map and a local language model on top.

This is an analysis of the design rather than a review of its conclusions. It is also the author's own project, which is disclosed above.

One schema instead of forty tabs

The core engineering decision is a normalisation layer. Every source — USGS earthquake feeds, GDELT conflict events, ADS-B aircraft positions, AIS vessel tracks, radiation monitoring, cyber vulnerability catalogues — is mapped into a single OmniEvent record with a common severity scale of minor, moderate, major, or critical.

That mapping is rule-based and source-specific: a magnitude 5.0–6.9 earthquake maps to major, a VIX reading above 30 maps to critical, a Kp index of 7 or higher maps to critical. The thresholds are documented in the repository, which matters more than the thresholds themselves — severity in a fused system is an editorial choice, and stating the choice is what makes the dashboard interpretable.

Above the event layer sit 37 toggleable map layers across five visual modes (standard, satellite, FLIR, NVG, and CRT), rendered with MapLibre GL. The visual modes are a usability affordance for long monitoring sessions rather than a data feature.

Two refresh rates

The platform runs two polling regimes, which is a sensible split for this kind of data:

• Live tracking, 10-second cycle. Aircraft and vessels, where position changes minute to minute.
• Sweeps, 15-minute default. Everything else, on a configurable interval. A diff engine computes what is new, cleared, or escalated between sweeps, which is the part that prevents the interface from becoming a wall of identical alerts.

The LLM layer, and why the fallback matters

The J.A.R.V.I.S. terminal is an Ollama-backed assistant, using gemma3:27b by default, that reads the active event set and answers questions about it — for example, correlating an aircraft diversion with a nearby conflict event.

Two design choices here are worth separating from the marketing:

1. The model is local by default. Inference runs against your own Ollama instance, so the event context does not leave the machine.
2. There is a rule-based fallback. If the model is unavailable, the server still returns structured severity summaries rather than failing. For a monitoring tool, degradation that keeps working is worth more than a smarter assistant that does not.

A language model's correlation is a hypothesis, not evidence. The value is triage — pointing a human at the two feeds worth reading — and the interface should be honest that this is what it is doing.

What it is not

• Not a replacement for official warnings. USGS, NOAA, and national agencies publish authoritative alerts; OmniWatch aggregates and visualises them.
• Not verified intelligence. Source data can be delayed, incomplete, or wrong. ADS-B and AIS feeds have known coverage gaps, and GDELT's event coding is automated.
• Not a finished product. The repository has been publicly stable since April 2026, has not been independently audited, and is a single-maintainer project. The licence and source-availability claims above are taken from the project's own documentation.
• Not zero-setup in the general case. The documented install is a clone-install-build sequence (a Dockerfile is included), and some optional sources — Finnhub for market data, OpenSky for higher rate limits — require keys.

Why it is still worth studying

The interesting contribution is not the dashboard. It is the pattern: take a set of open, heterogeneous public feeds, normalise them into one schema with documented severity rules, compute deltas between refreshes, and put a local model on top for triage. That pattern — not any individual source — is what makes cheap, self-hosted situational awareness possible, and it transfers directly to environmental monitoring, disaster response, and infrastructure observability.

The project is at github.com/masood1996-geo/OmniWatch, with a live deployment on Hugging Face. The aggregation approach descends from Crucix by @calesthio, as the repository states.