Glossary

Daily Local Forecast

The once-daily product issued at 12:00 AM Pacific for the current local calendar day. It contains ten hourly forecast points from 9:00 AM through 6:00 PM, a daytime mean temperature, a full-day high, a full-day low, and a top-line daytime sky condition.

• The ten hourly temperatures are the forecast inputs for the daytime mean.
• The high and low cover midnight through 11:59 PM, not only the displayed daytime window.
• The top-line sky condition is selected from the dominant broad class among its own hourly sky forecasts.
• The record is generated and stored once by the Pi timer; viewing the dashboard never creates or changes it.

Internal provenance: daily.local_weatherman_persistence_plus_diurnal. This is the product name shown after Model:; the identifier is retained for technical evaluation.

Rolling Hourly Local Forecast

The hourly product issued at the start of every hour. Each forecast point applies to the exact target hour, not an average across the following hour. It currently exposes 1-, 3-, 6-, 12-, and 24-hour horizons.

• Temperature and sky condition are forecast as separate fields using the same underlying components as the Daily Local Forecast.
• The live product includes the 24-hour horizon, while the rolling backtest evaluates the 1-, 3-, 6-, and 12-hour horizons.
• Every point retains its issue time, target time, product provenance, source inputs, and model details.
• The current live run is excluded from backtesting because its target observations do not exist yet.

Internal provenance: rolling.local_weatherman_persistence_plus_diurnal. This is the product name shown after Model:.

Persistence Baseline

A deliberately simple control and fallback that carries the latest suitable observed value forward. It answers the question, "How well would we do if we assumed the recent local conditions persisted?"

• It is not assumed to be sophisticated or optimal.
• It provides a stable reference for evaluating whether a more complex component adds value.
• It is retained in forecast payloads even when the production product uses a diurnal adjustment or sky-condition rule.
• It is also used when the required history or features for a more specialized component are insufficient.

Internal provenance: baseline.persistence.

Trend-Adjusted Candidate

An earlier experimental component that nudges a recent observation using a bounded short-term trend. It can adjust numeric weather fields only when recent observations show a stable, monotonic movement across enough time; otherwise it falls back to persistence.

It remains available for historical evaluation and comparison, but it is not the current named Daily or Rolling Hourly product. It should not be confused with the current 14-day hourly profile or the sky-condition rules.

Internal provenance: baseline.trend_adjusted.

Local Hourly Temperature Profile

A recent 14-day profile of how the backyard temperature normally changes at each local hour. It is the shared temperature-shaping component for the Daily and Rolling Hourly products.

1. Group recent local observations by local hour.
2. Require sufficient history for the needed hours.
3. Use the profile to shape the future curve while anchoring it to the latest observation.
4. Apply one bounded global scale so the largest adjustment stays within the configured 4 C limit.

The profile does not import ECCC forecast temperatures. Persistence remains the control and fallback when the local history is too short, sparse, or unstable.

Sky Condition Rules

A bounded, explainable component that estimates a broad sky class from recent weather behavior. It considers pressure tendency, temperature-dew point spread, humidity, wind speed, gust behavior, and wind-direction changes over the recent feature window. It is a forecasting component, not a direct cloud measurement.

• Pressure below 1.0 hPa/hour is treated as neutral for sky forecasting.
• Pressure moving 1.0-2.0 hPa/hour is weak falling or rising evidence. A sustained fall at this tier downgrades a clear/sunny result one step toward mixed cloud.
• Pressure moving at least 2.0 hPa/hour is strong rising or falling evidence. It can reinforce a cautious transition, while other signals determine whether a larger change is justified.
• Falling pressure and narrowing temperature-dew point spread support a cloudier transition.
• Rising pressure and a wider spread support a clearer transition.
• Humidity and wind behavior provide supporting evidence rather than a direct cloud measurement.
• The rules remain conservative: pressure can cause one cautious downgrade when the fall is sustained, but pressure alone does not predict rain or force a dramatic cloud transition.
• Forecast presentation is time-aware: clear/sunny conditions use sun wording and icons during the day, and clear wording with moon icons at night.
• New forecasts never issue a sky condition as `N/A`; if evidence is weak, the neutral broad condition A mix of sun and cloud is used and marked as a neutral fallback.

Internal method: sky_condition.pressure_dewpoint_wind_rules. This is an inference component, not a ceilometer, camera, or direct cloud sensor.

Hope Airport Sky Stand-in

Until a backyard sky or light signal is available, the latest observed sky condition from ECCC Hope Airport initializes and anchors the local sky-condition component. This is an observed condition used as a stand-in for the backyard, not an ECCC forecast.

• Only the ECCC observed condition is eligible to seed the forecast.
• The observation must be no more than six hours old at forecast issue time.
• ECCC forecast periods are never copied into Weatherman forecasts.
• If the ECCC observation is missing or stale, local sensor signals are used instead.
• Each payload preserves the source, station, observation timestamp, feature values, and fallback reason.

Hope Airport is being treated as the user's backyard stand-in by design; it is not being presented as the forecast itself.

Daytime Sky Summary

The daily top-line sky condition is the dominant broad class across the stored 9:00 AM through 6:00 PM hourly sky forecasts. For example, several variations of cloudy wording are grouped into the cloudy class before the dominant class is selected.

The summary is calculated from the Daily product's own hourly forecasts. It is not copied from the latest ECCC label and is not calculated from the observed sky conditions after the fact. If the hourly results are tied, the first stored value from the dominant class provides the displayed wording.

Internal method: sky_condition.daytime_hourly_mode.

Exact Target Hour

Rolling hourly temperatures represent the forecast for the target hour itself, not an average over the following hour. A forecast issued at 10:00 AM for the 3-hour horizon targets 1:00 PM.

Backtesting matches that target hour with the corresponding local UV-6 observation window. The target time is preserved separately from the issue time so the system never confuses when a forecast was made with what time it applies to.

High and Low Components

The daily high and low cover the full local calendar day from midnight through 11:59 PM. They combine observations already available at the midnight issue time with forecast points for the remainder of the day.

This is different from the top-line daytime mean, which uses only the ten displayed forecast points from 9:00 AM through 6:00 PM. The high and low therefore include overnight conditions and are not derived from the daytime mean.

Feels Like and Dew Point

These are computed display values, not forecast products. Dew point is estimated from local temperature and relative humidity using the Magnus formula. Feels like uses wind chill in cold conditions, humidex in warm humid conditions, and actual temperature otherwise.

They are presented as context and are not silently inserted into forecast scores or used as invented forecast prose.

Forecast Backtest

A read-only comparison of stored forecasts with later observations. It evaluates what Weatherman actually issued instead of generating a replacement forecast during page viewing.

• Forecast issue time identifies the historical information available to the model.
• Target time identifies the future condition being tested.
• Only observations available after the target time can verify a forecast.
• Missing observations remain unscored rather than being treated as failures.
• The dashboard is a reporting layer; it does not mutate forecast or score records.

Daily Forecast Score

The daily score includes four top-line items when available:

• Mean daytime temperature
• Full-day high
• Full-day low
• Top-line sky condition

Temperature, high, and low use the 2.0 C absolute-error threshold. Sky conditions are compared by broad class rather than exact wording, so terms such as Mostly Cloudy and Cloudy can match. The ten hourly sky points are displayed for context and are not added to the Daily product's top-line score.

The displayed score is the number of accurate available top-line fields divided by the number of verifiable top-line fields. The intended complete Daily score is out of four.

Rolling Temperature Score

Rolling temperature accuracy is reported separately for the 1-, 3-, 6-, and 12-hour horizons. A result is scored only when the matching UV-6 observation is available and the target time has passed.

The current 24-hour live horizon is not part of the current rolling backtest display. This keeps the evaluation focused on the horizons with the intended sample coverage.

Rolling Condition Score

Rolling sky-condition accuracy is reported separately from temperature accuracy. It compares the forecast broad class with the nearest suitable Hope Airport observed class at the target time.

• The score uses broad classes such as clear, partly cloudy, cloudy, and precipitation.
• It does not require identical wording from ECCC and Weatherman.
• A gray minus icon means the result is not verifiable yet; it is not a failed forecast.
• Condition results do not alter the separate rolling temperature score.

Unscored or Not Yet Verifiable

A forecast remains unscored when its target time has not arrived, the matching observation is unavailable, or the available data do not meet the verification requirements. It is not counted as either accurate or inaccurate.

This distinction matters operationally: a missing ECCC observation is a coverage problem, not evidence that Weatherman predicted the wrong condition. The dashboard shows this state with a neutral gray minus icon.

Observation

A value measured or reported by a source, such as the local UV-6 station, the BMP280, ECCC Hope Airport, Fraser River station 08MF005, BC Wildfire Service, or Skyfield's local calculation.

Observed time answers when the source says the condition occurred. Received/fetched time answers when Weatherman obtained or calculated the record. Keeping both prevents delayed feeds from being mistaken for current conditions.

Forecast

A value generated by Weatherman for a future target time. Forecasts preserve their issue time, target or validity time, product provenance, source inputs, raw payload, and fallback details.

Forecasts are stored separately from observations. Historical forecasts are not rewritten when the model improves; this keeps backtests honest and makes later comparisons replayable.

Product Name

The short, human-readable name shown after Model: on the dashboard, such as Daily Local Forecast. Product names describe the whole forecast product.

Provenance

The detailed internal identifier preserved in stored records, such as daily.local_weatherman_persistence_plus_diurnal. Provenance identifies how a value was produced even when the dashboard uses a shorter product name.

Product name answers "what does this forecast mean to a person?" Provenance answers "which stored implementation and component path produced it?" Both are retained because readable names and reproducible technical history serve different purposes.

Issue Time and Target Time

Issue time is when Weatherman created the forecast. Target time is when the forecast applies. A forecast can only be evaluated after its target time and after an appropriate observation is available.

All stored times are UTC text internally, with the relevant local timezone preserved separately. The dashboard converts them to America/Vancouver for human display.

Freshness

Freshness describes how recently a source observation, calculation, or synchronization completed. A stale source may still be historically useful, but it should not be treated as current input without an explicit fallback or warning.

Freshness is separate from validity. A record can be old but historically valid, or recent but rejected/failed. The dashboard therefore displays source freshness, fetch status, and sync status as separate signals.

Data Sources and Authority

The Raspberry Pi is the operational authority. It collects UV-6 observations, BMP280 pressure, ECCC observations, hydrometric data, BC Wildfire Service snapshots, forecasts, recordbook summaries, and Skyfield events. HostGator is a synchronized read-only presentation and backup layer, not the master collector.

The Mac retains a recovery/development copy and must not run as a parallel collector or publisher. The dashboard cannot fetch live data, generate forecasts, or repair records.

Skyfield Astronomical Events

Skyfield calculates deterministic moonrise, moonset, lunar transit, sunrise, sunset, and lunar phase events locally for Hope using a cached JPL ephemeris. The sole active astronomical source is currently Skyfield; retired USNO records remain only as historical provenance.

The Pi precomputes the next local calendar day's daily events before midnight so the dashboard does not normally have a date-boundary gap. Event times are stored in UTC and displayed in America/Vancouver. The ephemeris version is preserved with the result.

Rain Counter and Current Spells

The UV-6 rain value is a cumulative counter. Weatherman reconstructs rainfall from non-negative increases between observations; counter decreases are treated as resets and are not counted as rain.

A wet day has positive reconstructed rainfall. A dry day has none. Current dry and wet spells are mutually exclusive: the active spell has a day count, while the other is displayed as Inactive. Completed-day recordbook spells require adequate observation coverage; the current partial local day is handled separately.