Sign inRegisterCheck connection

Editorial Standards for a Weather-Tool Wiki

Editorial standards for documenting weather-station tools on a wiki: cite software versions, do not paste binaries, and keep field maps dated.

Back to Cumulus weather software guides

A wiki about weather tools is only as scientific as its citations. If the page does not name a software version, it is folklore. If it pastes a binary or a full PHP dump, it is an unlicensed mirror. If the field map has no date, it is a trap for the next parser. This page states those editorial standards. Why a project wiki existed at all—why it beat forum threads, and how it differed from the official Cumulus Wiki—is /projects/wiki. Do not collapse the two URLs.

Historical context

The historical TNET Weather site kept both a wiki project and a reference cluster. The wiki was the medium. The reference hub listed the card fields (inputs, outputs, versions, license, breaking changes). Someone still had to write sentences that would not rot. These standards are that writing rulebook.

They apply to community-tool documentation: banners, WAP endpoints, checkers, calendars. They do not replace the Cumulus Wiki, which remains the authority for how Cumulus itself behaves (last checked 13 August 2026). TNET is not affiliated with that wiki’s maintainers. When a TNET page and a Cumulus Wiki page overlap, cite the Cumulus Wiki for vendor files and keep TNET prose on the consumer.

This site does not restore a writable wiki, does not rehost dumps, and does not offer ZIPs.

Cite versions, not “current Cumulus”

Every factual claim about a file format is a claim about a flavour and a build.

  • Write legacy Cumulus 1 or Cumulus MX, never only “Cumulus,” when behavior differs.
  • Record version and build when the packet carries them (classic realtime.txt fields 39–40) or when the author tested a named release.
  • Record PHP version and extensions (GD, FreeType, calendar libraries) for any consumer script.
  • When you quote a vendor table, add last checked and a link. The Cumulus Wiki’s own realtime.txt page states that MX field notes can lag the code; repeating an undated copy makes the lag worse.

A sentence that says “field 59 is feels-like” without “MX 3.7.0 and later, wiki checked 13 August 2026” is not a citation. It is a guess that will be wrong for Cumulus 1.

Do not update a page by silently rewriting the table. Add a dated note: “Before build n the line ended at field 58.” Silent edits destroy the ability to interpret an old log.

Do not paste binaries

A weather-tool wiki is prose plus tables plus short examples. It is not a file locker.

Do not paste executable PHP, compiled WML (wmlc), font files, ZIP contents, passworded configs, or full realtime.txt captures that identify a living station without a clear historical-example frame.

May quote a single illustrative line of a public packet with date, location, and “historical example, not current weather,” or a five-line header that shows license text already published by the author.

Why this is an editorial rule, not only a legal mood. Binaries on a wiki page cannot be versioned as documentation. They bypass the license field the reference hub requires. They encourage operators to run recovered PHP 5 on a public host. They also destroy readability: a 400-line script is not a field map.

If a reader needs to run code, send them to a maintained repository with a stated license, or describe the algorithm so they can rewrite it. Document the license you found. Do not advise beyond that.

Images belong on a wiki only when they are original diagrams or clearly licensed screenshots that do not impersonate vendor branding. Do not hot-link live station banners as if they were documentation figures; they change, and they are other people’s observations.

Keep field maps dated

A field map is a scientific table. It needs a caption with:

  1. source file name;
  2. software flavour and version range;
  3. date the map was verified;
  4. which columns are observed, derived, or scenario.

Example caption, as structure rather than as a TNET measurement:

Table 1. Consumer fields used by the historical banner script from Cumulus realtime.txt, classic layout through field 58, verified against the Cumulus Wiki on 13 August 2026. Temperature (field 3) is observed; wind chill (field 25) is derived; forecast number (field 49) is a station-program scenario, not an NWS product.

Rules:

  • One map per version range. Do not splice MX-only fields into a Cumulus 1 table without a dividing line.
  • Do not invent indexes. If the consumer only used temperature, humidity, and units, the table has those rows plus a pointer to the vendor’s full list.
  • Mark unknown cells as unknown. Filling them from memory is how ClientRaw maps get applied to realtime.txt.
  • Re-verify after a vendor release, and change the date. A wiki page whose map is five years old should say so in the first paragraph, not in a footer nobody reads.

The WAP reference and the iCalendar child are where specialized maps (MIME types, ICS properties) live. This page only requires that those maps follow the same dating rule.

Evidence families in running text

Editorial voice must keep WMO-style honesty:

  • Observed — logger values (outside temperature, rain today as the program defines “today”).
  • Derived — wind chill, heat index, humidex, apparent temperature, feels-like.
  • Scenario / rule-of-thumb — Zambretti-style forecast fields in the packet.
  • Forecast — a model or official office product, named as such.
  • Historical — a dated snapshot, never relabeled as live.

Do not write “the station says it will rain” about a Zambretti number. Do not write “current” about a Wayback capture. Do not present TNET connection research as if it were a National Weather Service product.

Attribution and the official wiki

  • Credit Steve Loft / Sandaysoft for Cumulus origins, and the MX maintainers for Cumulus MX, without implying TNET endorsement or affiliation.
  • Link cumuluswiki.org for vendor behavior.
  • Credit community script authors by the names on their headers.
  • Never restyle a TNET URL as “the Cumulus Wiki.”
  • Never copy Cumulus Wiki prose into these pages; cite and summarize.

Practical checklist for an editor

  1. Open with the tool’s file contract, not with nostalgia.
  2. Put flavour + version + last-checked date on every format claim.
  3. Cite the Cumulus Wiki or Weather Display docs instead of forking tables.
  4. No binaries, no ZIP, no full scripts.
  5. Caption every table with observed / derived / scenario.
  6. Record license as found; if missing, write “unclear.”
  7. When the vendor changes a file, add a dated breaking-change note rather than rewriting history.
  8. Keep /projects/wiki for the “why a wiki” argument; keep this page for how to write.

Modern relevance

Git READMEs fail in the same ways wikis fail: undated JSON schemas, pasted minified builds, and screenshots of a GUI that has since moved. Editorial standards travel. A public research pipeline that consumes station files needs the same captions TNET now uses on data sources, quality controls, and methodology: named source, freshness, units, identity.

TNET research bridge

Methodology and source quality for TNET’s public weather and network records are described at data sources, quality controls, and methodology. That brief is not a wiki style guide, and this style guide is not a description of TNET forecast assembly. How the service works states the observed / modelled / derived vocabulary used in the current product. The Cumulus hub lists the historical project pages these standards were meant to govern.

Sources