Sign inRegisterCheck connection

One-Shot Conversion of Cumulus and Weather Display-Era Files

Why convert1 existed: a one-shot migrator for units, date-time, and CSV/XML between Cumulus and Weather Display-era files. This page does not rehost a converter.

Back to Cumulus weather software guides

Station software families do not share a file schema. Weather Display and Cumulus both write current-conditions packets, daily summaries, and monthly logs, but the field order, unit storage, and date notation differ. The historical path /cumulus/convert1.php on tnetweather.com named a one-shot migrator: a utility an operator ran when moving a dataset from one family to the other, or when exporting a log into CSV or XML for a new tool. This article explains why that job existed and what a conversion must preserve.

It does not rehost a converter, provide a field-by-field recipe that would recreate one, or distribute recovered PHP. Parsing an already-Cumulus XML file is parse_xml.php. The Cumulus XML schema as a current-conditions export is cumulus-xml.php. Those pages read or describe one dialect. Convert1 translates between dialects.

Historical context

Operators who changed software, merged a Weather Display archive into a Cumulus site, or fed a graph pack that expected CSV needed a translation step. Doing that by hand in a spreadsheet destroyed timestamps and silently converted inches of rain into millimetres twice. A named convert1 script on the historical TNET Weather site was the obvious URL for “run this once against these files.”

The original interactive tool is not restored. A public converter that accepts arbitrary uploads is also a poor idea: it becomes a place to park other people’s climate records and a parser attack surface. The durable content is the conversion contract.

Cumulus and Weather Display remain independent products. TNET does not maintain either vendor’s file format. Current field lists come from their documentation—for Cumulus, the realtime.txt and webtag wiki pages (last checked 13 August 2026).

Why a migrator is one-shot

A live parser sits in the publication path: every web hit reads realtime.txt and draws a banner. A migrator sits in the archive path: it reads a finite set of historical files, writes a new set, and stops. That distinction matters.

  • Live parsers must be fast, defensive, and idempotent. They should not rewrite the only copy of a dayfile.
  • Migrators must be explicit about lossy steps (two-digit years, integer rounding, unit defaults) and must leave the source files untouched.
  • Running a migrator on a schedule against files that are still being appended creates duplicates and clock collisions. “Convert1” as a name already says once.

If you need ongoing interchange—Cumulus extra XML for a website, an AWEKAS pull file—that is a publisher, not convert1. Publishers emit a current snapshot. Migrators rewrite history.

The three translation problems

Units

Cumulus realtime.txt carries unit tokens in-band (wind, temperature, pressure, rain, later cloud-base units). Weather Display packets and many WD-era CSV exports encode numbers whose unit is a station setting outside the file. XML dumps may put the unit in a child element (community webtag XML).

A converter that copies 72.1 from one file to another without reading the unit has not converted. It has laundered an ambiguous number into a new schema. Required behavior:

  • read the source unit;
  • write the destination unit that the target software expects;
  • apply a single, tested conversion function per quantity;
  • refuse to guess when the source unit is missing.

Temperature (C/F), pressure (hPa, mb, inHg), rain (mm, in), and wind (m/s, km/h, mph, kt) are the usual four. Derived fields (wind chill, heat index, humidex) should be recomputed by the destination software after native values are loaded, or copied only if the destination documents the same formula. Silent recomputation inside convert1 without a label produces a third climate series.

Date and time

Cumulus date fields follow the Windows (or MX host) short-date separator and can use two-digit years (realtime.txt field 1). Time may be local civil time without an offset. Weather Display logs and NOAA-style climate tables use other conventions. XML may store a locale sentence (17:40 on 05 September 2009 in the wiki XML example). CSV exporters often pick ISO 8601 without saying so.

A one-shot migrator has to:

  • parse with an explicit format, not strtotime guesswork;
  • expand two-digit years with a documented pivot;
  • attach a timezone from station metadata (not from the web server that happens to run PHP);
  • write a destination timestamp the target software will re-read the same way.

Ambiguous 05/06/07 is a data-loss event. If the source format cannot be proven from a header or from a documented station setting, stop. Do not emit a “converted” monthly log that shifted every summer day by one month.

Day boundaries matter for rain-today and daily extremes. A timezone shift that moves 00:10 local across midnight will split a rain total. That is why convert1 is an archive operation with operator review, not a background cron.

CSV versus XML versus positional text

Three serializations appear in this cluster:

| Serialization | Typical role | Failure mode | |---|---|---| | Positional text (realtime.txt, ClientRaw-class packets) | Current conditions | Wrong index map; version drift | | CSV / monthly logs / dayfile-style rows | Climate archive | Header mismatch; decimal comma vs point | | XML | Named current dump or interchange | Encoding, missing elements, DTDs |

Cumulus forces decimal points in realtime.txt even when the PC locale uses commas—an explicit script-friendly choice in the wiki. WD-era CSV opened in a European Excel can re-export commas as separators and as decimals. A converter must treat locale as an input parameter.

XML as a destination is not automatically better. Named elements help if the names are documented. They do not remove unit or clock problems. XML as a source still needs the safe parse bounds (no external entities, size cap, missing ≠ zero). Convert1 should read a DOM or a CSV reader after those checks, then write new files—never “fix in place.”

Positional maps are version-sensitive. Classic Cumulus 1.9.4 realtime.txt field counts are not MX field counts (feels-like and later rain fields were added). A converter built for 2008 packets will drop or shift columns on a 2020s file. Record source version/build (Cumulus fields 39–40 in the classic layout) in the conversion report.

What convert1 must not do

  • Must not be offered as a public upload form on a live weather domain.
  • Must not invent METAR groups or AWEKAS line files as a side effect. Those are different contracts (projects.metar, awekas.php).
  • Must not treat a successful XML well-formedness check as a successful climate migration.
  • Must not overwrite dayfile.txt or monthly logs without an operator-held backup.
  • Must not claim that TNET still runs the historical PHP.

Practical migration checklist

  1. Inventory source files: current packet, daily summary, monthly logs, any homemade realtime log. Note software name and version.
  2. Write the intended destination schema (which Cumulus or WD files, which units, which timezone).
  3. Convert a short fixture first—one known day with a known rain total and a known min/max temperature—and diff by hand.
  4. Preserve source files unchanged. Write outputs to a new directory.
  5. Emit a conversion report: rows in, rows out, skipped rows, unit mapping, date format, timezone.
  6. Load the result into the destination software’s own import path if it has one, rather than dropping files where the logger still writes.
  7. After a trial month, compare monthly rain and extreme temperatures against the old software’s reports. Disagreement is a converter bug until proven otherwise.

That procedure is quality control on an archive, not a forecast. TNET’s public note on source identity, native units, and schema drift for weather records used in connection research is data sources, quality controls, and methodology. How observed, modelled, and derived information are distinguished in that research is conceptual on how the service works. The Cumulus hub lists related historical pages; this tnetweather.com URL stays the migrator essay.

Modern relevance

Operators moving from legacy Cumulus 1 to Cumulus MX, or from WD to MX, should prefer vendor-documented import tools when they exist. A community convert1 from the PHP era is a lesson in unit and clock hygiene. JSON extra files and HTTP APIs change the serialization; they do not make Fahrenheit into Celsius.

If you only need to read current Cumulus XML, stop here and use the parse and schema articles. If you need a live network upload, that is AWEKAS or another ingest, not a one-shot converter.

Sources