Sign inRegisterCheck connection

Sparklines from Weather Display Time Series

How small-multiples of temperature, pressure, humidity, wind, and rain compress a day of Weather Display observations for station quality control.

Back to Weather Display software guides

A sparkline is a word-sized time series: intense enough to show a day's shape, small enough to sit beside a number. Edward Tufte defined it that way in Beautiful Evidence—a small, intense, simple graphic with typographic resolution, meant to live where a word or a figure would live. For a Weather Display station, that means six or seven thin traces of the quantities the logger actually records: temperature, pressure, humidity, wind mean, wind gust, and rain.

The historical /wds-script.php page described a PHP sparkline utility that read Weather Display's hourly ClientRaw file and drew those traces. This article does not rehost that package, its ZIP, or its banners. It is a guide to the scientific job those graphics were for: compressing a day of observed samples so an operator can see stuck sensors, missing packets, unit mistakes, and physically implausible jumps without opening a full chart page.

What a station sparkline is for

A large plot is a destination. A sparkline is a quality-control strip. Placed in a table, one row per variable, it answers questions that a single "now" value cannot:

  • Has temperature been flat for hours in a way that looks like a frozen packet rather than a still night?
  • Did pressure drop as a step, as a ramp, or as a gap?
  • Is humidity pegged at 100% or 1% while temperature still moves?
  • Do wind mean and gust still stand in the right relationship, or has one channel died?
  • Is rain a few tips, a clogged-zero, or a one-sample spike?

Those are observed questions. A sparkline of a model forecast is a different object and should not be mixed into the same row without a label. A sparkline of last month's daily means is historical. The WDS-style graphic was aimed at the recent hour or the recent day of station files, which is the QA window where a personal station usually fails.

Tufte's weather graphics in Beautiful Evidence and related notes treat small multiples as comparison: many thin series, same idea of time, so the eye can scan. The station analog is one day, several instruments, shared time axis. The scientific value is the set, not the ornament around one trace.

The file is a sample, not a movie

Weather Display's clientrawhour.txt is documented in the WDLive configuration material as last-hour data, generated from a stated WD version onward. A sparkline built from that file is a plot of whatever the application chose to write, at the interval it chose to write. That interval is not automatically the sensor's radio packet rate, and it is not the browser's image refresh.

If the file holds one point per minute for 60 minutes, the sparkline has at most 60 samples. Refreshing the PNG every five minutes does not create new physics; it republishes the file. If the logger missed ten minutes, the honest graphic shows a hole. If the publisher interpolates across the hole, the graphic invents a slope.

Daily files and archive exports can feed a 24-hour small multiple. The same rule applies: the x-axis is the timestamps in the series, not the width of the image.

Resampling without hiding gaps

Sparklines are small, so they invite aggressive resampling. Resampling is legitimate when it is named. It is a QA failure when it is silent.

Downsampling. Taking every nth point, or a bucket max/min/mean, is a derived series. For temperature QA, keep min and max as well as a mean or a spike disappears. For rain, a mean of tips is the wrong reduction; rain is a count or a depth increment. For gust, the useful downsample is often the bucket maximum.

Upsampling. A smooth curve through five points is not a 60-point observation. Do not spline across missing timestamps.

Missing values. Loggers often encode missing as a sentinel (a large negative, a blank, or a repeated last value). Sentinels must become gaps before plotting. Quality-control work on weather data treats those sentinels as missing, not as extreme weather. Stephen Few's guidance on time-series display makes the same visual point: a missing value should appear as a break, not as a line that implies a known path.

Axes, units, and small multiples

A sparkline often omits tick marks. That is acceptable only if the scale is still recoverable. Tufte notes that sparklines take quantitative context from nearby numbers. For weather, those numbers are not optional.

Each trace needs:

  • Quantity name (air temperature, not "temp" if indoor and outdoor both exist).
  • Unit (°C or °F; hPa, inHg, or kPa; % relative humidity; m/s, kt, mph, or km/h; mm or in of rain).
  • End value, and preferably the period min and max, printed as type-sized figures.
  • Time span ("last 60 minutes" or "00:00–24:00 local, n samples, k missing").

Shared time across the small multiple is what makes the set diagnostic. If temperature is a 60-minute file and rain is a 24-hour file, do not stack them as if they were one experiment. Either resample both to a common window, or label the windows.

Independent y-scales are normal for different quantities. They are dangerous for the same quantity in two units, or for two stations. A temperature sparkline in °F next to one in °C will look like a different climate. Convert first, or do not compare. Pressure in inHg and hPa on adjacent rows without conversion will hide a storm-scale fall on the inch scale because the ink range is tiny.

Wind mean and gust may share a y-scale. That is one of the few cases where a common axis is itself the QA test: gust should lie above mean for the same interval if both sensors are alive. Rain should use a baseline at zero and must not borrow temperature's scale.

What QA looks like in the traces

The following patterns are reasons to inspect the logger, not to redraw the art.

Flatline with a living neighbor. Temperature stuck while humidity and pressure still move often means a frozen channel, not a still atmosphere.

Step then flat. If timestamps skip, it is a gap, not a front.

Pegged humidity. Relative humidity stuck at the top or bottom of the reporting range while temperature cycles is a sensor or ventilation problem.

Gust below mean, or gust identical to mean for hours. Suggests a parser mapping error or a dead gust channel.

Rain spike of implausible depth in one sample. Suggests a funnel dump, mm read as inches, or a counter reset. Flag it; do not smooth it away.

Pressure in the wrong century of values. Mixing hPa numbers with an inHg axis, or the reverse, still makes a pretty line.

These are observed diagnostics. They do not replace official climate series, and they do not validate a forecast.

Do not rehost the old graphic utility

The historical WDS page offered language banners, remote-fetch modes, crontab generation of static PNGs, and a downloadable archive. Those choices are context only: pre-rendering images reduces load; remote fetch turns your site into a proxy. This page does not distribute that code or those images.

A modern equivalent is ordinary: parse a versioned ClientRaw hour or archive file with a documented field map, treat missing as missing, plot small multiples with explicit units, and state the publish interval. Template chrome is a web-tag problem. An old parser bookmark is a versioning problem.

If you still have historical WDS PNGs, label station, time span, and generation time. A 2009 sparkline is a historical figure, not a live instrument.

Place in TNET research

Atmospheric time series—precipitation, moisture, wind, pressure, temperature—are the weather evidence families a connection outlook has to interpret as observations, not as decorations. Compact, honest traces are how you see whether those observations are complete. The public overview of those families is evidence families. The Weather Display hub indexes the publishing tools that produced the files.

Checklist

  1. State the file, the time span, and the sample count.
  2. Convert sentinels to gaps; never plot −999 as weather.
  3. Do not interpolate across missing timestamps.
  4. Print units, end value, and period min/max beside each trace.
  5. Share a time axis across the small multiple; do not mix hour and day silently.
  6. Use scientifically correct reductions (rain sums, gust maxima, temperature min/mean/max as needed).
  7. Keep forecast traces off the observation strip.

Sources