Sign inRegisterCheck connection

Station Identifiers and Observation Provenance

Why a public station ID such as KAZMESA12 is part of observation provenance, using a dated 26 April 2005 published HTML snapshot only as history.

Back to Historical weather observations and forecasts

An observation without a station identifier is a number that cannot be joined to a place, a sensor suite, or a later quality-control report. Networks that ingest personal weather stations therefore issue IDs: stable tokens that travel with the packet. The ID is not branding. It is provenance.

The historical TNET Weather page at /weather/KAZMESA12.html published a Weather Display HTML report under the public identifier KAZMESA12. A recovered dump is dated 26 April 2005. That capture is a dated example of a published station HTML product. It is not current Mesa, Arizona weather. Specific logger values from the dump are omitted here so they cannot be reread as a live report.

Historical context

Personal stations in the 2000s uploaded to more than one consumer. A backyard logger might feed a self-hosted website, Weather Underground (or a similar public map), and, for many U.S. operators, the Citizen Weather Observer Program (CWOP) and NOAA’s Meteorological Assimilation Data Ingest System (MADIS). Each ingest used an identifier. The filename and URL on this site used KAZMESA12, the same token neighboring pages listed as a Weather Underground station ID.

The page itself was a WD-generated station HTML: last-reading time, a promised next-update time, current and daily statistics, and a note that the logger sampled more often than the web file. That is a published observation product keyed by ID. It is not an NWS METAR, not an NCEI climate station, and not a MADIS quality-control score sheet.

This URL keeps the identifier in the path because that is the historical backlink. The useful article is why any such ID belongs in the record.

What an identifier is for

A station ID is a join key across files, maps, and years.

  • It ties a website table to a network packet.
  • It ties a packet to a metadata record (coordinates, elevation, sensor type).
  • It ties both to quality-control feedback, if the network issues any.
  • It lets a later user say “this series” instead of “a Mesa backyard sometime in 2005.”

WMO observing practice treats station identity as part of the measurement. Hobby networks implement the same idea with shorter tokens. If the ID is missing, duplicated across two physical sites, or reused after a move without a station-history note, the series is broken even when the thermometer still works.

The configuration article is the narrative metadata. The ID is the machine-readable handle that should point at that narrative.

Different networks, different grammars

KAZMESA12 looks like the common U.S. personal-station pattern used by Weather Underground and similar maps: a country-style prefix, a two-letter state, a place token, and a sequence number (here, Mesa, Arizona, station 12). That pattern is easy for a human to read. It is not a CWOP identifier, and it is not an ICAO airport code. Treating it as Phoenix Sky Harbor (KPHX) would be a provenance error.

CWOP and MADIS use other grammars for the same scientific job. CWOP documentation distinguishes at least three related IDs (CWOP FAQ):

  • Packet / findU ID. Amateur-radio callsign, or a non-ham token such as CWxxxx, DWxxxx, EWxxxx, FWxxxx, or GWxxxx.
  • MADIS NWS ID. A shorter form stored in MADIS netCDF files (for example a letter plus four digits for many non-ham sites).
  • CWOP provider ID. The program’s own account token, often aligned with the packet ID.

NOAA describes CWOP as a public-private partnership that collects citizen observations, makes them available, and returns quality-control feedback. MADIS has ingested CWOP since 1 July 2001. Data are stored by observational timestamp, not by the time a website happened to scrape HTML (MADIS CWOP). CWOP is not Weather Underground; MADIS says so explicitly in its CWOP FAQ.

A station can therefore hold several IDs at once. Honest publication lists each ID with its network. Collapsing them into one unlabeled “station code” is how a Weather Underground map pin gets quoted as a MADIS record, or the reverse.

Why the ID belongs on the HTML, not only in the filename

The recovered 26 April 2005 product is the teaching example: a self-hosted HTML file whose path is the ID. That is better than a generic /weather.html, because a saved copy still names the station. It is not sufficient by itself.

A complete published product repeats the ID inside the page, next to:

  1. Location — locality, and coordinates if known.
  2. Observation time — last reading, with date and zone or a stated local clock.
  3. Next-update or publish interval — a publishing promise, not a sensor sample rate.
  4. Units — temperature, rain, wind, pressure.
  5. Which statistics — instant, ten-minute wind, since-midnight extrema, month and year rain.

The historical file also printed all-time records and a one-line forecast. Records are historical extrema from this logger’s memory. They are not NCEI climate records. The forecast line is a forecast. Neither inherits extra authority from the ID.

Do not copy long recovered tables forward. The scientific remainder is the header contract: ID, time, units, period. The 26 April 2005 snapshot documents that a published station HTML existed under KAZMESA12 on that date. It does not document today’s Mesa atmosphere.

ID as a quality-control handle

Networks that return QC need a stable ID to send the report back to the right operator. MADIS quality-control processing is documented at the program level as checks against nearby data and internal consistency, not as a certificate that a backyard is a climate-reference site. A clean QC period does not freeze siting. Trees grow. A new shed appears. The anemometer moves.

If this site’s historical pages listed KAZMESA12 on Weather Underground, that listing is a historical publication path. It does not mean TNET Weather today operates that station or that the ID is still assigned. IDs are reused, retired, and orphaned when domains lapse. A preservation article should treat KAZMESA12 as the identifier that this URL used, and should send readers who need a live network lookup to the current official map for that network—not to a 2005 HTML file.

When an ID changes because the hardware moved, start a new series or record a station-history break. Keeping the old ID after a relocation is how urban-heat or wind-exposure changes masquerade as climate.

Distinct from the dashboard and the weekly extract

/weather.php is the hub: how stats, forecast, radar, and live views sit together. This URL is the identifier-bearing station HTML—one product, one ID in the path.

/weather/weekrep.htm is a short-period climate extract (weekly or daily-in-a-week). It may mention the same station, but its job is seven (or few) climate rows, not the latest packet.

/published.php recorded where the station sent files. That is distribution metadata. The ID is the token those destinations used.

Practical checklist

  1. Print the public ID in the page body, not only in the URL.
  2. Name the network that issued it (and any second ID for CWOP/MADIS or another ingest).
  3. Keep coordinates and elevation with the ID; they are the ID’s meaning.
  4. Never treat a PWS ID as an airport ICAO or an NCEI station number.
  5. When quoting a 2005 HTML dump, quote the date and the ID; do not update the numbers in place.
  6. After a move or a sensor-suite change, document a break; do not silently keep the old ID as if the series were homogeneous.
  7. Use official NWS products for warnings. An ID on a hobby page does not make the page official.

Modern relevance

Connection-intelligence and weather-research work still join public records by identifier, time, and location. A token such as KAZMESA12 is the 2005 form of that join. TNET’s data sources, quality controls, and methodology page is the modern statement of how public weather and network records are treated as evidence—by provenance, not by a familiar filename.

Observation hub: /legacy/observations/.

Sources