Sign inRegisterCheck connection

A Station Page That Lists Publication Targets and Feeds

/weather-published.php was the station roster of publication targets and feeds—network names, IDs, and banner snippets—not the concept of publishing itself.

Back to Personal weather station guides

A station website needs a page that answers a practical question: where do these observations go, and under which identifiers? That page is a roster, not an essay. The historical URL /weather-published.php sat in the Mesa station’s own navigation beside configuration, live stats, and notebooks. Its job was to list publication targets and feeds—CWOP, a Weather Underground-era map ID, graphic banners—so a visitor or a neighboring webmaster could find the outbound copies.

This article is distinct from /published.php, which explains what publishing means (provenance, hops, QC). Here the subject is the roster as a document type: how to read one, what belongs on it, and why a dated station list must not be mistaken for a live feed. Recovered captures of this URL are historical. They are not current Mesa weather, and old embed snippets are not republished as working code.

Historical context

Weather Display-era station sites used a persistent nav: Basic Stats, Forecast, Day Stats, live views, Doppler, Configuration, Published, Notebooks, Links, Info. “Published” in that row was not a philosophy seminar. It was the outbound-directory page, analogous to a station’s “where to get the data” card.

A recovered capture of this path carried a format stamp of 25 April 2005 and the station-nav chrome of that era. That date is operations metadata. It tells you when the HTML was generated, not when a CWOP packet was observed, and not that the same destinations still receive data. The page mixed three kinds of listing that are worth separating:

  • Network destinations with program names and station IDs.
  • Graphic feeds (banner URLs) other sites were invited to hot-link.
  • Site chrome (repeated nav, copyright, page-access counters) that is not a meteorological product.

This rewrite keeps the first two as a roster problem. It drops the live-site tone, the counter, and any implication that TNET Weather today operates that backyard or still serves those images.

What a publication roster is for

A roster is a catalog of destinations. Each row should be complete enough that a stranger can retrieve the same logical product later:

  1. Network or product name (CWOP, website file, map network, banner).
  2. Identifier in that network’s grammar.
  3. What is sent (current packet, daily statistics, a graphic interpretation).
  4. How to fetch it (URL pattern, not a promise that the URL still works).
  5. Cadence, if known (every minute, every ten minutes, daily).
  6. Date the operator last confirmed the destination was alive.

Without those fields, “we publish to CWOP” is advertising. With them, the page is metadata. It belongs next to configuration and station information, because siting and outbound IDs are how a later reader interprets a number found on a map.

The roster is not the observations themselves. It should not be a second copy of the current-temperature table. Mixing a live gauge into a destination list teaches visitors to treat the roster as a meter.

How to read the historical classes of listing

Network IDs

Recovered text named the Citizen Weather Observer Program and a Weather Underground-era station ID, with “data link” labels. Read those as roster rows:

  • CWOP is a public–private volunteer observing program whose data MADIS ingests and quality-controls. The ID on a station roster is the packet identity that program issued. NOAA documents CWOP’s goals and ingest; MADIS states that CWOP is not Weather Underground (MADIS CWOP; MADIS CWOP FAQ).
  • A map-network token is a different row. It tells you how to find the station on that vendor’s map or history page. It does not tell you that NOAA stored the same packet.

A complete roster prints both IDs and does not let one link text stand for both programs. If a historical page used a placeholder instead of a working URL, the honest modern article says the category of feed existed, and does not invent a current finder link that was not verified.

Banner feeds

The historical page offered HTML snippets that pointed at GIF or PNG banners on the station host. A banner is a derived graphic feed. Listing it on the roster is legitimate: other webmasters needed a URL. Restoring the snippet as copy-paste code is not: the images are not served here as live assets, licensing of old graphics is unclear, and a hot-link tutorial would imply a working service.

What remains useful is the feed type. If you catalog publication today, separate:

  • Machine-readable observations (text packets, APIs, MADIS).
  • Human HTML (the station site).
  • Derived images (banners, gauges) that can go stale independently of the packet.

Cadence on banners was often slower than the logger. A roster that says “updated about every ten minutes” is describing the image clock, not the sensor clock.

Daily statistics sent “throughout the country”

Operator pages sometimes claimed that daily statistics were sent to “a number of other organizations.” Without named organizations, that sentence is not a roster row. A scientific listing names the receiver. Unnamed redistribution is a reminder that PWS data travel, not evidence of a particular ingest.

Distinct from the concept article and from the dashboard

Keep the neighboring URLs in their lanes.

  • /published.php — what publishing means: hops, provenance, QC, why IDs differ.
  • This URL — the station’s outbound directory: which targets, which IDs, which product types.
  • /weather.php — dashboard architecture (stats, forecast, radar, live). “Published” in the nav is a pointer to this roster, not a fourth weather panel.

A reader who lands on /weather-published.php from 2005-era navigation wanted the list. Give them the list’s method, not a reprint of dead image tags.

A roster template that still works

If you maintain a PWS site, a published-data page can be a short table:

| Destination | ID | Product | Cadence | Last confirmed | |---|---|---|---|---| | Operator website | URL | HTML current conditions | FTP interval | Date | | CWOP / MADIS | Packet ID | Surface packet | Packet interval | Date | | Other map or API | That network’s token | Current / history | Vendor interval | Date | | Banner or widget | Image or script URL | Derived graphic | Image refresh | Date |

Rules that keep the table honest:

  • Leave a cell blank rather than guessing an ID.
  • Do not paste a QC score from a year ago as if it were today’s.
  • When a destination dies, mark it ended, with a date; do not delete the row if old papers cited it.
  • Never present the roster as an official warning channel.

Modern relevance

Station software still offers a checklist of upload targets. The scientific need is unchanged: a public card that maps this backyard to those IDs. Researchers who find a temperature on a blog and a temperature in MADIS need that card to decide whether they are looking at one instrument.

TNET does not use this URL as a live destination list. Provenance for public weather and network records used in connection research is described in data sources, quality controls, and methodology. Observed versus modelled versus derived language for TNET’s own products is how the service works. The weather-station hub is the category index for this page.

This restoration does not re-enable banner hosting, does not assert current CWOP or map-network membership, and does not replace NWS alerts.

Sources