Sign inRegisterCheck connection

Weather Notebooks as Reproducible Mini-Methods

Weather notebooks were reproducible mini-methods (parse, convert, calculate, include) published so other operators could verify work that opaque dashboards hid.

Back to Personal weather station notebooks

A weather notebook, on the historical TNET Weather site, was a small public method: a defined input, a process another operator could repeat, and an output that could be checked. Notebooks existed because live dashboards hide their work. If a page shows 72° and a green gauge, the visitor cannot tell whether the number came from a ClientRaw field, a converted unit, a cached include, or a typed-in default. A notebook shows the steps.

This hub maps that idea and the series that lived under /notebooks.php. It does not steal the child articles' theses. Each child URL remains the place for its own method—field dictionary, parser snippet, include architecture, official-text case, or conversion functions.

Historical context

Personal weather websites in the PHP era were assembled from vendor files plus homemade includes. Operators learned in public. A working climate table was posted as a page of explanation, not only as a ZIP. The historical notebooks index listed entries by name: an included-file template website, Weather Display ClientRaw descriptions, a NOAA-report parser, PHP calculation helpers, a "fact" include system, a ClientRaw parse example, and an NWS statement preserved as a teaching text.

That mix looks miscellaneous until it is read as a methods shelf. Some notebooks transform station files. Some transform units and compass points. Some transform site architecture. One preserves an official warning product so that operators can see the difference between a PWS page and a National Weather Service statement. The hub's job is to show how those genres fit, and why publishing them as notebooks rather than as opaque widgets was the scientific choice.

The leftover "random weather facts" block on the old index was decoration. METAR belongs in official aviation documentation, not as a footer factoid. This article does not recycle that padding.

Numbering was itself a cataloguing method. Low nb-000n pages were short, single-function notes. nb-0100 was a schema dump large enough to be a reference. nb-0200 was a multi-file include demonstration with its own index. The numbers are identifiers, not a curriculum order. A reader can enter at the genre they need.

Why notebooks instead of dashboards

A dashboard optimizes for glance value. A notebook optimizes for verification.

Defined input. A notebook names the file, product, or value it consumes: clientraw.txt, a Weather Display dailynoaareport*.htm, a wind direction in degrees, an NWS text product. If the input is missing, the method should fail in a visible way, not invent a pleasant number.

Defined process. Unit conversion, field split, HTML table extraction, or include assembly should be describable in order. Another operator should be able to repeat it on a dated copy of the input and get the same output.

Defined output. An array of named fields, a labeled HTML table, a compass point, a shared header across pages. The output is a data product with units and a timestamp policy.

Troubleshooting. The useful notebooks said what breaks: empty file, format change after a vendor update, PHP not enabled, wrong path. That section is the quality-control manual.

Opaque Flash gauges, plugin viewers, and "live" images without captions fail this test. They can still be useful displays. They are not methods. When the plugin dies, the method—if it was written down—still works on the text file.

A map of the historical series (without the child theses)

The notebooks are a cluster, not a single tutorial. Read them as genres.

Official text, preserved as a document

/nb-0001.php historically held a National Weather Service statement associated with Hurricane Katrina in August 2005. The hub-level point is genre, not the storm narrative: some notebooks exist to keep an official forecast/warning product distinct from station observations. A PWS site that reprints NWS language is hosting a government text, not a Davis-class measurement. TNET is not a warning service. Current life-safety information comes from the National Weather Service and local emergency authorities, not from a historical notebook.

Calculations and conversions

/nb-0002.php and the related /weather/notebooks/php-calculate.php sit in the conversion genre: take a numeric input (wind direction, a unit) and return a labeled or converted output. Hub-level thesis only: derived values must be labeled as derived. A compass point is not an extra wind sensor. A Fahrenheit column computed from Celsius is not a second observation.

Include architecture as a publication method

/nb-0200/ (including index.php and sample.php) demonstrated building a multi-page station site from shared PHP includes so that a header or menu could change once. /nb-0003.php belonged to the same family in miniature: a reusable "fact" include. The hub point is architectural reproducibility. A twenty-page weather site that duplicates chrome will drift; an include system is a method for keeping the publication layer consistent while the observation files update underneath.

Parse methods

/nb-0004.php addressed splitting Weather Display ClientRaw files in PHP on the local host. /nb-0005.php addressed parsing WD NOAA-style daily HTML into a table. These are file-contract methods. They share a spirit with the scripts hub—parsers as instruments—but they were published as inspectable notebooks rather than as packaged downloads. Format drift in vendor HTML is the expected failure mode; the notebook is where that failure should be documented.

Schema notebooks

/nb-0100.php historically listed ClientRaw field positions for a dated Weather Display version. That is a schema document. It is the companion to a parser, not a parser. Field maps expire when the vendor adds columns; a notebook that pins a version and a date is doing scientific citation.

The ClientRaw Parser article is the diagnostic-instrument discussion. The schema notebook is the dated dictionary. This hub should not merge them.

Contrast with packaged scripts and live tools

The scripts article treats PHP utilities as a tooling layer with licenses and security lessons. Notebooks overlap in subject and differ in rhetorical contract:

| | Notebook | Packaged script | Live dashboard | |---|---|---|---| | Primary object | A method another person can verify | A file to install | A glanceable display | | Success | Repeatable output from a named input | Runs on a host | Looks current | | Failure mode | Documented mismatch | Silent blank page | Frozen gauge that still looks fine | | License problem | Pasting large recovered PHP | Redistributing ZIPs | Plugin binaries |

When a notebook historically contained a full PHP listing, preservation has a copyright and safety problem. The right modern form is: state the input/process/output, describe the workflow, and point to maintained collections such as Saratoga Weather when operators need runnable template code. Do not treat this hub as a pastebin of recovered scripts.

What a new notebook should contain

Operators who still publish methods—whether in PHP, Python, or a spreadsheet—can use the old series as a quality bar.

  1. Title the operation, not the vibe. "Split ClientRaw on spaces and map field 4" is a title. "Cool weather hacks" is not.
  2. Pin versions. Station software build, file name, date of the example input.
  3. Label observed versus derived versus forecast. A notebook that converts NWS text into icons is processing a forecast product.
  4. Show a worked example with units. One line of input and the resulting array beats a page of enthusiasm.
  5. Say what you will not do. No remote fetch of strangers' files, no visitor-IP logging, no claim of official warning authority.
  6. Link the schema. A parse notebook without a field map is a guess.
  7. Record the failure you actually hit. "WD changed daily NOAA HTML in 2007" is worth more than a generic troubleshooting list.

Practical checklist for readers of this hub

  • If you need why PWS sites used PHP at all, start with the scripts tooling layer.
  • If you need ClientRaw as a live packet to diagnose, start with the ClientRaw Parser.
  • If you need field positions, use the schema notebook, remembering it is dated.
  • If you need site-wide includes, use the /nb-0200/ method pages.
  • If you need official hazard text, leave the notebooks and use current NWS products.
  • If you need runnable maintained templates, use Saratoga, not a recovered listing.

Modern relevance

The word "notebook" now suggests Jupyter. The historical TNET notebooks were the same scholarly instinct in PHP: show the work. Reproducible conversion, parse, and include methods still matter when the runtime is Python, a static site generator, or a cloud function. Opaque mobile apps have made the problem worse, not better: more stations publish, fewer publish their field maps.

A methods shelf also ages more gracefully than a dashboard. When Flash Weather Display Live disappeared, the ClientRaw file did not. When a PHP 5 include broke, the description of header-menu-footer assembly still taught the architecture. Preservation of this hub is preservation of that habit.

TNET research bridge

Reproducible mini-methods are how operators—and later researchers—keep observed, derived, and forecast values from collapsing into one green number. TNET's public note on how the forecasting approach is structured is the modern counterpart: it explains how independent evidence families are combined into a connection outlook without publishing proprietary formulas or weights.

Continue in the notebooks hub, the include-architecture notebook, and the ClientRaw schema notebook.

Sources