Sign inRegisterCheck connection

What a Weather-Software Reference Page Must Contain

A reference hub for Cumulus community tools: the inputs, outputs, versions, license, and breaking changes every project card should document.

Back to Cumulus weather software guides

A weather-software project that other people will run is not documented when it has a screenshot and a download counter. It is documented when a later operator can answer, from one page, what the tool reads, what it emits, which versions were tested, under which license the files travel, and what broke when the vendor file grew a new field. That page is a reference, not a feature tour and not a copy of the running tool. The historical TNET Weather URL /projects.reference was the hub for those cards.

Slash paths such as /projects/checkserver are the tools. Dotted paths under /projects.reference.* are how to cite and configure those tools on paper. Mixing the two produces duplicate articles. This hub stays on the documentation contract.

Historical context

The historical TNET project index mixed packages, galleries, and a “reference” cluster. The cluster existed because community PHP around Cumulus and Weather Display aged faster than the forum posts that described it. realtime.txt gained fields. PHP removed extensions. Hosts disabled GD. A banner that still “worked” could be drawing yesterday’s temperature because nobody had written down the cache rule.

A reference hub is a catalog of cards, not a second wiki homepage. The project wiki explains why documentation needed a durable medium. The editorial standards explain how to write inside that medium. This page specifies the fields every card should carry, then maps the child URLs without taking over their theses.

TNET Weather today does not maintain the old packages, does not rehost ZIPs, and does not claim the original authors’ copyrights. The hub remains because the card format is still the right way to describe a file-consuming weather tool.

The five fields of a project reference card

Every child under this hub should be readable as a filled card. If a recovered page cannot supply a cell, the honest value is “not recorded,” dated, not a guess.

1. Inputs

Name the files, not the theme. For Cumulus consumers that usually means optional realtime.txt (off by default in all flavours), a processed web-tag file, or a homemade realtime log. For Weather Display consumers it means ClientRaw or a named HTML report. State:

  • path as the script expected it (relative to the host, not as a Windows logger path unless the script ran on the PC);
  • delimiter and field count at a stated software version;
  • unit tokens (Cumulus realtime.txt carries wind, temperature, pressure, and rain units in fields 14–17 of the classic map);
  • which clock is authoritative: packet timestamp, filesystem mtime, or both.

Do not paste a vendor field table that the Cumulus Wiki already maintains. Cite the wiki, date the citation, and record only what this tool required from the file.

2. Outputs

Name the product as a scientific object.

  • Image: type (image/png), pixel size, and whether text is observed, derived, or scenario.
  • Text or WAP: MIME type and character encoding.
  • Status line: what “OK,” “stale,” or “down” is defined to mean, in terms of file age and completeness—not in terms of a coloured icon.

An output that omits units is incomplete. An output that prints a Zambretti-style forecast number next to a thermometer value without a label is mixing evidence families.

3. Versions

Record a triple when it is known: tool version, station-software version and build, PHP (or other runtime) version. Cumulus 1 and Cumulus MX share file names; they are not one runtime. A card that says “Cumulus” without a flavour is not a reference.

When the vendor file grew—MX added feels-like and later weekly rain to realtime.txt—the card needs a dated note, not a silently lengthened parser. Breaking changes are a first-class field, not a footnote.

4. License

Write the license the package actually declared: GNU GPL, a BSD-style notice, public domain, or unclear. Index-page copy and file headers sometimes disagreed; the header wins. Unclear is not an invitation to republish recovered PHP. Document the license. Do not give legal advice beyond that documentation, and do not attach a ZIP.

5. Breaking changes and known false modes

A reference that only describes the happy path is a brochure. Record:

  • format drift (new fields, new JSON instead of realtime.txt);
  • runtime drift (GD missing, TTF missing, PHP 8 vs PHP 5);
  • operational false modes that look like weather (stale cache, ISP outage, clock skew).

Each child page below owns one of those false-mode stories. The hub only names them.

How a reference differs from the tool page

| Question | Tool page (/projects/X) | Reference page (/projects.reference.X) | |---|---|---| | What was this for? | History and engineering of the running idea | The card: files, sizes, headers, versions | | How did it fail in the field? | Deep narrative (heartbeat, rendering, live claims) | Documented failure definitions and how to write them down | | May it include code? | Original, safe explanation only; no unlicensed dumps | Field maps and header names; no binaries | | Primary reader | Operator deciding whether the problem still matters | Operator or archivist citing the contract |

If two URLs start answering the same paragraph, the reference page is the one that should shrink to a table and a checklist.

Child reference URLs (map, not a digest)

These children keep their own articles. The sentences here are pointers, not substitutes.

Later wiki-reference children for graph packs and related tools remain historical addresses. They are not filled from this hub.

A filled card, as a pattern

The pattern looks like this. Values are illustrative of structure, not a claim about a recovered TNET build.

| Cell | Example of a complete entry | |---|---| | Target | Cumulus MX, realtime.txt enabled; not ClientRaw | | Input | One-line space-separated file; cite Cumulus Wiki map dated 13 August 2026; require unit tokens and a date+time pair | | Output | image/png, 88×88 (avatar) or a stated banner geometry; Cache-Control max-age matched to upload interval | | Versions | Tool 3.x; MX build recorded from packet fields 39–40 in the classic layout; PHP with GD | | License | As in the PHP header; if absent, “unclear — do not redistribute from this site” | | Breaks | Field count grew after MX 3.7.0; Fine Offset stations update ~48 s, so a 30 s stale threshold is a false alarm |

A card that cannot fill the output row should not claim the tool was “self-explanatory.”

Practical checklist for writing or reading a card

  1. Start from the URL. projects.reference.X documents X; it does not replace /projects/X.
  2. Cite vendor maps; do not fork them. Link Cumulus Wiki realtime.txt or the current Weather Display docs.
  3. Date every field list. “Last checked” is part of the science.
  4. Label evidence families on the output: observed, derived, forecast/scenario.
  5. Record license as found. Stop there.
  6. Name false modes in the same vocabulary the operator will see (“stale file,” not “the station feels down”).
  7. Leave child theses on child pages. If the paragraph is about MIME types, it belongs on the WAP reference, not here.

Modern relevance

JSON endpoints and HTTP APIs did not retire the card. They made it stricter. A consumer of MX JSON still needs a versioned schema, a freshness rule, a unit policy, and a license on any republished adapter. Research ingest of public station files asks the same questions under different headings: source identity, quality control, and provenance.

A reference hub is how a volunteer community approximates an instrument manual. The alternative is a folder of unreproducible PHP.

TNET research bridge

TNET’s public note on data sources, quality controls, and methodology is the modern statement of those same card fields for weather and network records used in connection research. It does not list Cumulus indexes, and this hub does not describe TNET’s forecast assembly.

The Cumulus hub lists the historical project family. How the service works explains observed versus modelled versus derived information in the current product.

Sources