A weather-station template does not only paint a page. It also knows, or thinks it knows, every other page it can include: sidebar links, footer credits, forecast slots, and script download headings. When that knowledge is dumped as an HTML list, the result looks like a sitemap. It is really a snapshot of the template’s include graph.
The historical TNET Weather page at /tws-sitemap.php was that snapshot. The tws- prefix marked TNET Weather Station template files, distinct from the earlier curated map at /sitemap.php. This article explains why a personal weather site often ended up with two HTML sitemaps, what a generated list can honestly claim, and why neither list is a live directory of the modern site.
Historical context
Weather Display sites in the 2000s commonly ran PHP template packs: shared header, menubar, footer, and a content slot. Community packs associated with CarterLake and later Saratoga Weather popularized that pattern. Operators then forked the files, renamed them, and added local scripts. On this host, many of those local files used a tws- filename so they would not collide with stock template names.
A recovered capture of /tws-sitemap.php still read “Below is a site map of the TNET Weather Station Web pages,” but the list had drifted from /sitemap.php. It pointed at tws-credits.php, tws-sitenews.php, tws-forecast.php, script-download headings, SoftWX preprocessing notes, WXSIM, and a footer line that named a local web generator version. Comment-wrapped entries showed pages taken offline without being deleted from the template. That is generation-plus-edits, not a second hand-written encyclopedia.
TNET Weather restores the URL as an article about that workflow. It does not rehost the generator, and it does not claim the listed paths are a current station menu.
How a station template produced a map
A typical PHP weather template built navigation from includes, not from a database of articles.
- One file defined the sidebar groups (Local Weather, Live Content, Information, Projects).
- Individual pages were PHP files that included that sidebar.
- A sitemap script included the same list, or walked a hard-coded array that was supposed to match the sidebar.
- Web tags or local configuration supplied station name, units, and “live” labels so the map looked branded.
The map was therefore a derived document. Its source of truth was the template, not the climate record. If the operator added a rain-detail script and forgot the sitemap array, the tool existed and the map lied. If the operator commented a webcam out of the sidebar but left it on the sitemap, the map advertised a camera that the menu no longer offered.
That is why generated HTML sitemaps aged badly. They were easy to create on the day the template was installed and expensive to keep honest after every experiment.
XML sitemaps later solved a different problem: telling crawlers which URLs to fetch. The Sitemaps protocol is a machine list of loc, lastmod, and optional priority. It has no slot for “this is a parser, not a thermometer.” A TWS HTML sitemap tried to be both a human outline and a dump of template knowledge. It did the second job more reliably than the first.
Why two HTML sitemaps existed
/sitemap.php and /tws-sitemap.php look redundant until you ask who maintained each file.
The curated map (/sitemap.php) was the operator-facing catalog: a nested list grouped the way a person wanted to explain the site—about, observations, live gadgets, NOAA HTML, notebooks, published IDs, configuration. It could omit experiments. It could keep a heading for a page that was conceptually important even if the template had renamed the file.
The template map (/tws-sitemap.php) was the generator-facing catalog: whatever the current includes, TWS-prefixed scripts, and project hubs knew about. It picked up new forecast wrappers, credits, bots notes, and download sections because those files were already in the template tree. It also inherited the template’s clutter: duplicate parser links, commented galleries, and “offline” items that still occupied a list entry.
Two maps existed because the jobs diverged. Curation answers “what should a stranger understand about this weather site?” Generation answers “what does this template currently link?” When a site ran for years, those answers stopped coinciding. Keeping both URLs was clumsy, but collapsing them without choosing a job produced a list that was neither a scientific catalog nor an accurate include dump.
A third sitemap—XML for crawlers—would have been the honest machine file. Many PWS sites never added one. They treated the HTML template dump as good enough for Google and for humans. It was not good enough for either once comments and dead scripts accumulated.
Drift, comments, and offline pages
Generated maps fail in predictable ways. Those failures are the reason this URL is worth keeping as an explanation rather than as a directory.
Comment residue. Template authors commented out a gallery, a guestbook, or a rain report instead of deleting the link. A sitemap that still prints the heading teaches a later archivist that the page existed, which is useful history, and teaches a visitor that the page is offered, which is false.
Rename without redirect. forecast.php becoming tws-forecast.php is a typical TWS fork. If the curated map still points at the old name and the generated map points at the new one, inbound links split. The scientific subject (a local forecast product) did not split; the identifier did.
Version furniture. A footer that prints a generator version is provenance for the website, not for the thermometer. Putting that string on a sitemap is fine if it is labeled as software. Treating it as a station ID is a category error.
Project accretion. Cumulus script hubs, WD sparkline utilities, and latitude converters are tools. A generated sitemap will list them because they are files. A curated sitemap should list them under Tools, not under Local Weather.
The human sitemap article is the place to sort families. This page is the place to remember that a template will not sort them for you.
What a generated map is not
- Not a live inventory of TNET Weather products.
- Not a crawl budget document.
- Not proof that every listed script is licensed for redistribution.
- Not current Mesa weather.
- Not a substitute for the legacy hub, which is the organized modern entry to the restored footprint.
If a backlink expected “the TNET site map,” the honest landing is an explanation of the two-map problem plus a pointer to the hubs that actually index restored articles.
Practical checklist
If you generate a sitemap from a weather template:
- Decide the job: human catalog, crawler XML, or include dump. Do not use one file for all three.
- Build the human catalog by family (observations, tools, about), not by filename prefix.
- When you fork
sitemap.phptotws-sitemap.php, 301 the old path or keep one canonical HTML map. - Strip commented and “offline” entries from the public list; keep them in a dated changelog if you need history.
- Do not advertise a script download from the sitemap unless the license is verified.
- Date the generated map. An undated include dump is indistinguishable from a current menu.
Modern relevance
Long-lived sites accumulate two indexes: the one editors maintain and the one software emits. TNET’s restored weather footprint is the editorial index. The legacy hub is the primary modern destination from this URL: it is the map a human should use now, instead of a TWS include list from a recovered template.
How TNET distinguishes observed, modelled, and derived information in public research is how the service works. Source identity for records used in that research is data sources, quality controls, and methodology. Those pages do not parse TWS PHP, and this page does not describe TNET internals.
Related historical pages: the site-history hub, the TWS site-news wrapper, and credits as citation.