Sign inRegisterCheck connection

Parsing WD NOAA-Format Daily Reports into Tables

Parse Weather Display NOAA-style daily HTML into tables: what the form contains, provenance versus NCEI, and CSS restyling versus changing numbers.

Back to Personal weather station notebooks

Weather Display can emit an HTML climatological summary that looks like a NOAA monthly form: one row per day, columns for mean temperature, maximum and minimum with times, degree days, rain, wind, and dominant direction. Parsing that file into a structured table is a presentation and quality-control problem. It is not a way to mint an official climate record. The HTML is a station-generated imitation of a NOAA-style form, not an NCEI product and not an NWS Climatological Report (CLI).

Historical context

The historical TNET notebooks published a PHP script that opened dailynoaareport.htm, found heading lines such as “MONTHLY CLIMATOLOGICAL SUMMARY,” and reprinted the numeric rows with CSS classes. The recovered script is evidence of the workflow. It is not redistributed here. The useful remainder is: what those columns mean, how to parse them without altering values, and how to label provenance so a visitor does not confuse a backyard logger with the Climate Reference Network.

Provenance: say this first

Three different objects share overlapping language:

  1. NWS Climatological Report (Daily), product CLI. An official text product for a designated climate site, issued on a defined schedule, with observed values, records, normals, and departures (NWS climate product instructions; live examples via forecast.weather.gov product CLI).
  2. NCEI station data and U.S. Climate Normals. The archive and the 30-year normals (1991–2020 as of 2026) used to compute official departures (NCEI Climate Normals).
  3. Weather Display “NOAA” HTML. A file the logger builds from that personal station’s daily statistics, laid out to resemble a classic monthly climatological summary. Useful for the site owner. Not a substitute for (1) or (2).

If your page title, filename, or CSS class says “NOAA,” add a visible sentence: this table is computed from the local Weather Display station, not from NOAA/NCEI. Changing the stylesheet does not change that fact.

Input

Typical inputs:

  • A WD HTML or text report (often dailynoaareport.htm or a monthly summary page).
  • Declared units in the header (WD pages often state °F or °C, inches or millimetres, mph or knots).
  • Station metadata: name, elevation, latitude, longitude, as printed in the file.
  • The civil month the table claims to cover.

Official CLI reports, if you are teaching contrast, contain observed maximum and minimum temperature, precipitation, the normals period, departure from normal, and often record values and times. WD’s imitation focuses on the station’s own daily line: mean, high, high time, low, low time, heating degree days, cooling degree days, rain, average wind, high wind, high wind time, dominant direction.

Those columns are a reasonable monthly dashboard. They are not automatically comparable to the airport ASOS ten kilometres away.

What a NOAA-style daily climate line contains

Read each column as a defined statistic, not as “weather.”

Day. Calendar day of the month in the station’s local civil date. Incomplete months have trailing blank days; blank is not zero.

Mean temperature. Usually the average of that day’s maximum and minimum as the logger defines them, not a true 24-hour integral unless WD is configured that way. Know which.

High / low and times. Extremes inside the logger’s day boundary (often midnight–midnight local). Time-of-extreme is only as good as the archive interval.

Heating and cooling degree days. Scenario indices against a base temperature (commonly 65°F in U.S. practice). They are derived, not observed. Changing the base silently changes the column.

Rain. Depth for that civil day in the file’s unit. A wet hour that straddles midnight will split across rows. Storm-total rainfall is a different quantity.

Average wind, high wind, time, dominant direction. Speed unit must match the header. Dominant direction is a summary of the day’s direction distribution, not the direction at the time of the high gust unless the software says so.

Departure from normal. Present on official CLI products when a normals set exists for that NWS climate site. A PWS HTML file often omits true departures because the backyard station has no NCEI normal. If you compute a departure yourself, you must name the normals source and period. Otherwise you invented a climate.

Process: parse without changing the numbers

Conceptual steps:

  1. Confirm file type. Look for the monthly-summary heading, station name, and a dash rule before the first data row. If you received an NWS CLI via forecast.weather.gov, you are in a different parser.
  2. Capture metadata. Date line, name, elevation, lat/long, unit sentence. Store them on the table object.
  3. Find the table body. Start after the header dashes; stop at the closing dashes or the first empty day row.
  4. Split rows on whitespace with a column budget. WD’s fixed-width-looking HTML is often space-separated once tags are stripped. Require the expected column count. If a gust time contains a space (3:15 PM), join time tokens before you assign rain to the wind column.
  5. Type each cell. Numbers as numbers; T as trace if the file uses it; -- or blank as missing. Do not coerce missing to 0.0.
  6. Keep native values. If the file says 57.6°F, store 57.6 and unit F. Do not round to 58 to “look cleaner.”
  7. Emit a list of day records plus metadata. HTML is an output skin.

Restyling belongs in CSS: fonts, zebra rows, width, dark mode. Restyling does not include dropping the degree-day columns, converting °F to °C at one-decimal precision and writing it back, or filling blanks from a neighboring station.

Output

A structured month:

  • source: weather-display-station-html (not ncei, not nws-cli)
  • station_name, location, month
  • units: temperature, rain, wind
  • rows[]: day, mean, high, high_time, low, low_time, hdd, cdd, rain, wind_avg, wind_high, wind_high_time, dom_dir
  • quality: missing-day count, parse errors

You may render that object as a table that looks like NOAA’s classic summary. The object’s source field must still say it is the station’s.

CSS restyling versus changing the numbers

| Allowed | Not allowed without a new, labeled derived column | |---|---| | Colors, fonts, captions, responsive layout | Silent unit conversion written into the cell | | Hiding a column behind a “show degree days” toggle, with the data still in the object | Deleting rain on days you “don’t believe” | | Highlighting the monthly extreme as already present in the file | Replacing a missing day with the airport’s high | | Linking to NWS CLI for the official climate site | Titling the page “NOAA monthly climate” without qualification |

If you add departures, add columns named departure_from_1991_2020_normal and cite the normals table. That is a derived product. It is honest only when the PWS siting is close enough to the normals station that you state the mismatch.

Troubleshooting

Column values look shuffled after the time fields. The high-time token split on the space in 12:00 AM. Use a time-aware tokenizer.

The last days of the month are zero rain and zero wind. You treated blank end-of-month rows as data. Stop at the first empty day.

Your table disagrees with NWS CLI for the city. Expected. Different instruments, different exposure, different day boundaries, different quality control. Do not “correct” the PWS toward CLI.

Degree days disagree with a degree-day calculator. Check the base temperature and whether the logger uses daily mean versus hourly integration.

HTML tags sit inside numbers. Strip tags before split, but keep the text. Do not parse with a brittle character offset from a 2006 template.

You want the official series. Download NCEI or read the NWS CLI. Do not FTP dailynoaareport.htm into a climate paper.

Modern relevance

Provenance—the difference between an official climate product, a station imitation, and a derived departure—is the same discipline TNET applies to public weather and network records. See data sources and methodology. For packet-level WD files rather than monthly HTML, use the ClientRaw tutorial and the field-family reference. Historical rendered examples on this site include /parse_noaa.php; treat those pages as station-era artifacts, not as NCEI.

Notebooks hub: /legacy/notebooks/.

Sources

  • National Weather Service. Daily Climatological Report (CLI) content and issuance: NWS Instruction 10-104 (climate products). Live CLI products via forecast.weather.gov.
  • NOAA National Centers for Environmental Information. Official station archives and U.S. Climate Normals: ncei.noaa.gov.
  • Weather Display. Station HTML climate reports are vendor-generated; see weather-display.com and your WD documentation for the current filename and units.