Under the hood

Technical Methodology

For readers who want to examine the mathematics and decision rules behind Weather Consensus. This is a developing technical reference, not a claim that every equation below has been verified against the currently deployed production code.

Inputs Averages Wind direction Agreement Risk scores Verification

1. Data sources and normalization

Forecast data can come from WeatherAPI.com, Visual Crossing, Open-Meteo, and the U.S. National Weather Service (NWS/NOAA), depending on coverage and availability. Each provider may have different time windows, update schedules, definitions, and missing fields. A source shown in the Forecast Inputs panel is the best indication of what contributed to the selected location and date.

Before comparing numerical forecasts, values must refer to compatible units and time periods. Missing or nonnumeric values should not be treated as zeros.

NWS data are provided by a U.S. government agency. Weather Consensus is an independent third-party product, not affiliated with or endorsed by NOAA/NWS.

2. Arithmetic consensus — the basic idea

The application JavaScript includes a function named calculateDayConsensus(sources) that collects valid numerical values for several forecast fields. A standard arithmetic mean is:

mean(x) = (x₁ + x₂ + … + xₙ) / n

Worked example (illustrative): Three forecasts predict highs of 78°F, 80°F, and 82°F.

(78 + 80 + 82) / 3 = 80°F

The exact aggregation and rounding behavior of each production field still needs a line-by-line audit against the deployed consensus.js, script.js, and Cloudflare Worker. In particular, precipitation probability should not automatically be assumed to use the same arithmetic rule as temperature.

3. Circular wind-direction calculations

Compass bearings wrap at 360°, so a simple mean of 350° and 10° would incorrectly point south. The inspected JavaScript uses vector components:

X = Σ cos(θᵢ) ; Y = Σ sin(θᵢ)

θ̄ = atan2(Y, X), normalized to [0°, 360°)

The implementation rounds the resulting direction to the nearest degree and returns no average when the vectors nearly cancel out (magnitude below 0.000001).

Example: Bearings of 350° and 10° yield a vector mean of approximately 0° (north).

4. Comparing wind directions

The inspected calculateWindDirectionAgreement(directions) compares each unique pair of valid wind bearings. Their smallest circular separation is:

Δ(a,b) = min(|a − b|, 360° − |a − b|)

A pair is counted as agreeing when its separation is at most 45°. The percentage is then:

agreement = round(100 × agreeing pairs / all pairs)

Example: Directions 350°, 10°, and 90° produce three pairs. Only 350°/10° agrees, so the result is round(100 × 1/3) = 33%.

At least two valid directions are required; otherwise this function returns no score. This rule applies specifically to wind direction; it should not be generalized to temperature, rain chance, or overall confidence.

5. Confidence, outliers, and winter risks

The application contains routines for daily consensus, snow/ice risk, freeze risk, icing risk, hourly precipitation, and an agreement overview. It also contains outlier-handling logic. These are separate calculations, not necessarily one universal formula.

Until the current source code and deployed Worker are compared in full, this page intentionally does not publish unverified coefficients, thresholds, confidence-star cutoffs, or activity weights. Publishing plausible but incorrect formulas would undermine the transparency this page is intended to provide.

Agreement measures similarity among available forecasts, not the probability that a forecast is correct. Risk indicators are informational and do not predict exact road-surface conditions.

6. Technical verification and revisions

Documentation status: initial technical draft, October 2026. Circular wind-direction averaging and pairwise direction agreement are documented from an available JavaScript snapshot. Other formulas and thresholds remain to be audited against the live release.

The next revision should document every variable's source field, unit conversions, eligibility rules, precise equation, rounding, outlier policy, fallback behavior, and at least one worked example. It should also record a code revision or commit identifier so the documentation can be matched to a specific deployment.

Safety: Weather Consensus is not an official alert service. For hazardous conditions and safety-critical decisions, consult weather.gov and appropriate local authorities.

← Back to the general Methodology page

Technical Methodology · Draft 0.1 · October 2026