This page explains every tile, every trigger, and the color / scoring logic in one place. It is designed so that a first-time user can understand the dashboard at a glance, while still being precise and traceable to OM references where applicable.
Important: this tool is an advisory monitor. It does not replace SOP, captain’s judgement, or official operational documentation.
The dashboard is a network monitor built around METAR/TAF. Every row is an aerodrome. The system parses the raw strings and computes a few consistent “signals” (visibility, RVR, ceiling, weather codes, gusts) plus an overall severity score.
base.txt). In tiles they appear first and are visually highlighted.Note: Some OM concepts require runway condition, runway in use, RWYCC, or SNOWTAM data. This system runs with zero manual inputs, so those parts are treated conservatively and marked as advisory.
You will see color in two places: (a) the row alert pill (OK/MED/HIGH/CRIT), and (b) tile border glow. The color represents a computed severity state driven mainly by the score.
Base airports are highlighted with a subtle pulse. This is not a different severity; it is a priority indicator.
The score is a simple, deterministic sum of points from: Visibility, RVR, Ceiling (CIG), weather codes, and wind gusts. It is capped at 100.
CIG (Ceiling) is derived as the lowest of any BKN, OVC, or VV layer in the report.
Layers like FEW and SCT are not a ceiling and are ignored.
Example: BKN008 → ceiling 800 ft.
| Signal | What is measured | Points added |
|---|---|---|
| Visibility (VIS) | Parsed in meters (METAR: explicit, TAF: minimum across all visibility groups) | ≤150:+35, ≤175:+30, ≤250:+26, ≤300:+24, ≤500:+18, ≤550:+16, ≤800:+12 |
| RVR | Minimum RVR found in RVR groups (both METAR + TAF) | ≤75:+28, ≤200:+22, ≤300:+18, ≤500:+12 |
| Ceiling (CIG) | Lowest BKN/OVC/VV in feet | <500ft:+22, <800ft:+12 |
| Weather codes | Presence of selected WX tokens | TS:+22, FZFG:+18, FG:+14, SN:+10, RA/DZ:+8, BR:+6 |
| Wind gust | Maximum gust (G) in knots | ≥25:+4, ≥30:+6, ≥40:+10 |
Final alert state is derived from the score, then optionally escalated by the wind/snow “pillars” so that clear operational hazards cannot be hidden by a single low score dimension.
Each tile is a fast summary of a specific condition. Tiles show the number of affected airports and a prioritized list of IATA/ICAO codes. Clicking a tile on the dashboard filters the table to the airports that trigger it.
Trigger: METAR indicates FZFG and METAR visibility ≤ 150 m.
Why it matters: highlights a “high consequence” combination: freezing fog + extreme low visibility. This is also pinned to the top in sorting.
OM reference: OM-A 8.3.8.2 (Icing) – Clean Aircraft Concept (policy context).
Trigger: overall score ≥ 70, or escalated by wind/snow pillars.
Why it matters: multiple hazards / minima-adjacent values are present. Treat as “needs attention now”.
OM reference: this is an internal dashboard severity layer (not a single OM paragraph), but it is built from OM-relevant observables.
Trigger: worst-case visibility < 300 m or minimum RVR < 300 m (computed from METAR + TAF).
Why it matters: 300 m is a key operational reference band (e.g., CAT II minimum RVR).
OM reference: OM-A 8.1.4 (Approach & landing minima; CAT II RVR ≥ 300 m).
Trigger: TS appears in METAR or TAF.
Why it matters: TS implies convective risk; company policy is avoidance. “Overhead / approaching” cannot be reliably inferred from raw strings, so treat this tile as a strong caution flag.
OM reference: OM-A 8.3.8.1 (Thunderstorms avoidance / warnings).
Trigger: gust ≥ 25 kt in METAR or TAF.
Why it matters: gusts drive handling risk and performance margins. Crosswind limit checking is handled by the separate XWIND tile (estimated).
OM reference: gust tile is an operational highlight; crosswind limits are per OM-B 1.3.1 (see XWIND).
Trigger: snow-related tokens present (SN, SHSN, BLSN, and combined groups containing SN) in METAR or TAF.
Why it matters: contamination, braking, and operational limits can tighten rapidly. Prohibitive heavy precipitation is flagged separately under TO PROHIB.
OM reference: OM-A 8.3.8.7 (Heavy precipitation – takeoff prohibited) as policy context.
Trigger (policy inference from METAR/TAF tokens):
+SN, +GS, +SG, +PL, FZRA/+FZRA, GR/+GR.Why it matters: these are OM-defined “do not take off” weather elements. The system can only see the tokens, not local tactical context; treat as a strong stop signal for investigation.
OM reference: OM-A 8.3.8.1 (TS) and OM-A 8.3.8.7 (Heavy precipitation – TO prohibited).
Trigger: reference VIS/RVR < 550 m. If < 400 m, an additional “LVP required” tag is shown. If RVR < 125 m, a hard-stop tag is shown.
How it is computed: if any RVR group exists, RVR is used; otherwise worst-case VIS is used.
OM reference: OM-A 8.1.4.4 (Take-off minima; LVP below 400 m; absolute minimum 125 m with required visual aids).
Trigger: estimated crosswind component exceeds the company limit (OM-B 1.3.1), based on a best-runway estimate.
How it is computed:
data/runways.json (if available).Why it matters: a fast, network-wide “heads-up” that some airports may be outside crosswind policy limits. Always confirm against the actual runway in use and actual condition/RWYCC.
OM reference: OM-B 1.3.1 (Crosswind limitations including gusts).
Trigger: token VA present in METAR or TAF.
Why it matters: OM policy requires avoidance of medium/high contamination and visible ash. METAR/TAF tokens alone do not represent ash polygons, but any VA mention is treated as a high-importance signal.
OM reference: OM-A 8.3.8.6 (Volcanic ash).
WORST VIS is computed as the minimum of: (a) METAR visibility, and (b) the minimum visibility found in any TAF visibility groups. This is intentionally conservative for planning/monitoring.
LVTO uses RVR if any RVR groups exist. If not, it falls back to worst-case VIS. This matches the principle that you must still consider visibility minima even when RVR is not reported.
XWIND is advisory. Without runway-in-use data, the system computes crosswind for available runways and picks the best. It is meant to surface potential crosswind issues quickly, not to replace actual performance / runway selection logic.
The dashboard is static HTML. Data is refreshed by GitHub Actions, which updates data/latest.json and then redeploys Pages.
If schedules are paused or rate-limited, the site can appear stale until the next successful run.