Sign inRegisterCheck connection

Weather Display as a Station-to-Web Publishing System

Weather Display as a station-to-web publishing system: logger, files, web tags, ClientRaw packets, upload cadence, and the quality of published observations.

Back to Weather Display software guides

Weather Display is station software: it talks to a logger, stores observations, and publishes a website by writing files and uploading them on a timer. The scientific object is that pipeline, not a gallery of add-on ZIPs. If the files are late, truncated, or written in mixed units, the website is not displaying weather. It is displaying a publishing failure.

The historical TNET Weather page at /weatherdisplay.php was a project index for Weather Display scripts, complete with version tables, click-tracker downloads, and donation lines. That catalog is not reproduced here. TNET does not redistribute those packages. Official behavior of the software belongs to Weather Display's own documentation, last checked 13 August 2026.

Historical context

Personal weather stations in this era typically used a hardware logger or console, a PC running station software, and a remote web host. Weather Display, written by Brian Hamilton, occupied the middle box. It decoded a wide range of stations, produced graphs and NOAA-style reports, and FTP'd a mix of HTML, images, and compact text files to the public site.

Community PHP then took over on the host: templates, AJAX updates, rain-detail tables, sparklines. The historical TNET page documented some of those add-ons and pointed at the Weather Display product site, forum, and user map. The durable subject is the publishing system those add-ons assumed: logger to files to website, with a known cadence and a known set of file contracts.

This article does not become a ClientRaw field dictionary. Field-level documentation belongs with the notebook that historically listed those fields and with Weather Display's own clientrawdescription.txt. It also does not become a parser diagnostic. That job is the ClientRaw Parser article.

The publishing pipeline

Treat Weather Display as four stages. Failures should be named by stage, not as "the website is wrong."

Stage 1: Logger to PC

The station hardware samples temperature, humidity, pressure, rain, wind, and any extra sensors the operator installed. Weather Display reads those values from a logger, a console port, or a helper that multiplexes a single Davis-class logger to more than one program. This stage produces observed values in the station's native units, plus whatever the software derives immediately (dewpoint, wind chill, trends).

A derived value is not an extra observation. Heat index, for example, is a calculated apparent temperature; the U.S. National Weather Service documents the operational heat-index method as a regression on Steadman's physiological work, not as a sensor reading. If the website prints heat index, it is printing a derived quantity that Weather Display (or a later PHP script) computed from temperature and humidity.

Stage 2: Files on the Weather Display computer

Weather Display turns the in-memory station state into files. The families that matter for a website are different contracts:

  • Custom web pages with web tags. The operator writes an HTML or PHP template using tags such as %temp%. Weather Display replaces the tags with values in the units the operator chose, then uploads the processed file, leaving the template intact. Official setup is described in Weather Display's weather web page help and the custom-tag list.
  • Real-time ClientRaw packets. Compact text files (clientraw.txt and its extra, daily, and hour companions) intended for frequent upload so that AJAX templates or Weather Display Live can refresh without republishing the whole site. Enabling them is a Control Panel / real-time FTP setting, documented in the Weather Display FAQs.
  • Report HTML. Climate tables, averages/extremes, and daily NOAA-style reports. These are bulkier, update less often, and were the input to community rain-detail and climate-extraction scripts.
  • Graphs and webcam frames. Binary images on their own cadence.

Each family has a different freshness expectation. Treating a once-daily NOAA report as a live observation is a category error. Treating a three-second ClientRaw timestamp as a climate normal is the opposite error.

Stage 3: Upload cadence

Weather Display uploads by FTP (or a related copy) on intervals the operator chooses. Two quality issues dominate this stage.

Partial files. If the software overwrites clientraw.txt or testtags.php in place, a browser or PHP parser can read a truncated file during the transfer. Community template setup, including Saratoga's Weather Display instructions, recommends renaming on the server after upload so that visitors only ever see a complete file.

Mixed intervals. A site might upload ClientRaw every few seconds, processed tags every minute, and climate HTML once an hour. The page that combines them must not imply they share a single observation time. A honest page shows the timestamp that belongs to each file.

Bandwidth and host limits are operational, not meteorological, but they affect data quality. Operators who set an aggressive cadence on a capped connection produce gaps that look like calm weather.

Stage 4: Website interpretation

On the public host, PHP includes, AJAX readers, and image scripts interpret the files. This stage can introduce new derived values (unit conversions, compass labels, sparklines) and new failure modes (cached pages, timezone mismatches, scripts aimed at an older HTML layout).

The scientific rule is simple: the website may display observed values from the files, derived values it calculates, or forecast text it pulled from a National Weather Service product. It must not relabel a forecast as a station observation, and it must not relabel yesterday's climate row as current conditions.

Web tags versus ClientRaw

Operators often ran both systems at once. They are not duplicates.

Web tags are a template language. They are processed by Weather Display on the PC, so the file that arrives on the host already contains numbers and strings. The host can include that file with very little parsing. The cost is that every layout change requires Weather Display to reprocess and re-upload the page, unless the operator splits static PHP chrome from a small tags file (the testtags.php pattern used by Saratoga templates).

ClientRaw is a compact packet of fields in a fixed order, uploaded frequently, parsed on the host or in the browser. It is efficient for live dashboards. It is also opaque without a field map: position 4 is not self-describing. That opacity is why a named-field parser became a diagnostic instrument, and why a separate article exists for it.

A publishing system that only uses web tags can still be scientifically adequate. A system that only uses ClientRaw can still be scientifically adequate. A system that mixes them needs a policy for which file wins when they disagree.

Quality of published observations

A published PWS page is a data product. Its quality is not the marketing quality of the hardware. It is the combination of siting, calibration, software settings, and upload integrity.

Units. Weather Display writes values in the units the operator configured. A parser that assumes Celsius when the file is Fahrenheit will invent a heat wave. ClientRaw packets and tag files both require the reader to honor the station's unit choice rather than a national default.

Timestamps and clocks. The PC clock, the logger clock, and the web host timezone are three different clocks. Stale uploads look like frozen weather. A page should show the observation time from the file, not the time the PHP script ran.

Completeness. Missing rain-collector dumps, a wireless anemometer dropout, or an extra sensor that Weather Display still lists as a numeric placeholder all publish as numbers. Quality control is the operator's job: compare against neighboring official observations, and against programs such as the Citizen Weather Observer Program that provide independent QC feedback through NOAA MADIS. TNET is not that QC service.

Format drift. Community scripts that parsed dailynoaareport*.htm already had to account for a 2007 layout change. Any long-running site should treat vendor HTML as a versioned interface. When the interface changes, the script is wrong, not the atmosphere.

Hazards. Lightning maps, storm scripts, and advisory includes on a PWS site are not official warnings. For life-safety decisions, use National Weather Service alerts and local emergency authorities. TNET is not a warning service.

What the historical add-ons were doing

Without restoring their ZIPs, it is still possible to name the jobs they sat on:

  • Sparkline utilities derived compact graphs from Weather Display data already on the host.
  • Rain-detail pages parsed uploaded NOAA-style daily reports into yearly or seasonal tables, which is a climate-presentation job, not a live-observation job.
  • Template add-ons assumed a Saratoga or CarterLake-style PHP site and a known path to WD files.

Those jobs remain legitimate. The implementations do not belong on this page as downloads. Maintained Weather Display PHP templates and setup notes are documented at Saratoga Weather (last checked 13 August 2026).

Practical checklist for a Weather Display website

  1. Draw the four stages on one page in the station notebook: hardware, WD PC, upload, web host.
  2. List every uploaded file with its interval and its role (live packet, processed tags, daily report, image).
  3. Enable atomic rename on FTP if the host supports it, so parsers never read a partial clientraw.txt or tags file.
  4. Record units and station name in Weather Display's NOAA/clientraw setup. Avoid characters that break community AJAX parsers; Saratoga's setup notes flag hyphens in station names for clientraw.txt time parsing.
  5. Show observation time next to live values. If the timestamp stops moving, the publishing system has failed even if the last numbers look plausible.
  6. Separate forecast includes from station observations in the template. NWS text is a forecast or advisory product, not a Davis-class sensor.
  7. When a table breaks after a WD update, compare a dated copy of the vendor HTML to the parser. Do not "fix" it by editing live numbers.
  8. Use official WD docs first for current tag names and real-time FTP settings; use community templates second.

Modern relevance

Weather Display still exists as commercial station software with current Windows, and historically other OS, builds; the vendor site remains the authority for supported versions (last checked 13 August 2026). The publishing model it taught—files as the interface between logger PC and website—is still the model behind many Cumulus, WeeWX, and custom MQTT stations. Only the transport (SFTP, APIs, object storage) has changed.

What aged out is the assumption that a public PHP script may fetch anyone's ClientRaw URL, that Flash-based Weather Display Live is a durable viewer, and that click-tracker ZIPs are a distribution channel. What did not age out is the need to know whether a number on a weather page is observed, derived, or forecast, and which file it came from.

TNET research bridge

Published station files are one evidence family among others: they are observations with siting and software metadata attached, not official analyses. TNET's public explanation of evidence families is the modern place to see how atmospheric observations sit beside network measurements and other inputs in connection research, without disclosing how those families are weighted.

Continue in the Weather Display hub, the ClientRaw Parser for packet diagnostics, and station configuration as metadata for siting and sensor-suite context.

Sources