A personal weather website can show its own logger. It cannot, by itself, show a neighbor’s logger. The historical URL /SWN/SWN-page.php solved that gap as a shared current-conditions include: one HTML fragment that listed many partner stations with the same fields, so each member site could drop the same module onto a page instead of scraping every neighbor by hand.
The path token SWN names that module. Recovered dumps described an affiliation of personal weather websites in the southwestern United States. That historical label is not independently verified here as a currently operating official organization, and this article does not invent a trademark or a live mesonet. The function is a networked conditions include. The Wayback tables that once filled this address are historical snapshots, not current Mesa weather, and they are not reprinted here.
Historical context
In the 2000s and early 2010s, hobby stations published HTML and compact text files from Weather Display, Cumulus, and similar software. Operators wanted a regional strip—temperature, humidity, wind, rain, pressure—without each site maintaining a private database of everyone else. The practical answer was a server-side include a partner could embed by path.
This URL lived in a directory named SWN. That is a clue. A directory-scoped include can carry its own CSS, images, and member list beside the fragment. Partner sites then pointed at a stable path rather than copying markup. Two other addresses on this host served the same family of module: a restyle sandbox at /SWN_new/SWN-page.php and a root alias at /swn-page.php. Three URLs does not mean three networks. It means one include was versioned and aliased the way PHP sites versioned everything else.
Recovered captures of this directory copy are dated snapshots. One member roster carried an April 2012 stamp; a conditions collection window on another capture ran across a December 2014 evening in Mountain Standard Time. Those dates belong in an archive note. They do not belong in a “now” column.
What a networked include actually is
Call the object by its engineering name. An include is not a forecast model, not a quality-controlled mesonet ingest, and not a climate archive. It is a publication fragment: a host renders rows from whatever member files it can read, then other sites include that fragment. Each row is supposed to be one station’s observation record.
The include therefore has two jobs that are easy to confuse:
- Membership. Which stations are listed, under what labels, with what outbound links.
- Observation rows. For each member, which values, at which time, in which units.
Membership can change when a site goes offline or a URL dies. Observation rows must still obey a contract, or the table becomes a collage of incomparable numbers. The contract is short: identifier, time, units. A single-station current-conditions page needs the same three pieces. A networked include needs them on every row, because the reader is comparing stations, not reading one backyard.
The data contract: identifier
An identifier answers “which instrumented place produced this row?” On a hobby include the token was often a place name plus a link to the member site. That is weaker than a network ID, but it is still an ID if it is stable and unique inside the table.
A later reader should be able to say whether “Mesa” means the historical TNET Weather station, a different Mesa logger, or a city-average. Collapsing a row into an unlabeled temperature fails that test. So does reusing a display name when the underlying site has changed hardware.
When the same station also published to public networks, the include ID and the network ID were different grammars for the same scientific job. A Weather Underground-era map token, a CWOP packet ID, and a website place-name are not interchangeable. What it means to publish is the provenance article; this page only insists that the include row name a station at all.
The data contract: time
A networked table is almost never simultaneous. Each member uploads on its own timer. FTP can stall. A site can be marked offline. The honest include therefore stamps each row with the time of that station’s last successful observation or last successful harvest—not with the time the HTML page was generated.
Recovered dumps of this module sometimes showed a collection window: a start time and an end time spanning tens of minutes. That window is a feature, not a defect. It tells you the include is a harvest, not a synoptic observation. Treating every temperature in the table as “valid at 01:55 MST” would be a false precision.
Staleness rules follow from the same fact. A row without a time is not current. A row whose time has stopped advancing while the rest of the table still updates is a publishing failure at that member, not a meteorological calm. An “Offline” placeholder is more honest than a frozen number with no clock.
Time zone belongs in the contract. Mountain Standard Time on a Mesa host is not UTC, and a California member may have been harvested in the same clock while sitting in a different zone. If the include does not say which zone a stamp uses, the stamp is ambiguous.
The data contract: units
A shared table that mixes Fahrenheit and Celsius in one column, or millibars and inches of mercury in one pressure cell, is not a table. It is a unit error waiting to be quoted. The include’s job is to declare the unit for every plotted field and to keep that unit consistent across rows—or to convert explicitly and label the conversion as derived.
Typical fields were temperature, humidity, wind speed, today’s rain, and barometer, with a conditions word and sometimes dew point, gust, and pressure trend. Those names are the schema; Wayback numbers are not. Dew point is often calculated from temperature and humidity; a pressure “trend” compares earlier samples. A Chandler-style fire-danger word is derived, not an official warning. Official hazards come from the National Weather Service and local authorities.
Unit mistakes are the include’s most common scientific failure. Rain in millimeters looks like a desert if the table assumes inches; knots look like a gale if the column says miles per hour. The fix is a column header that states the unit, and a harvest that refuses to recast silently.
Observed, derived, and harvested
Keep the evidence types separate.
- Observed values are what a member’s sensors (and station software) reported: temperature, humidity, wind, rain, pressure, when those came from instruments.
- Derived values are calculated from those reports: dew point, heat index, pressure trend, empirical fire-danger indices.
- Harvested structure is the include itself: which members were reachable, which were offline, and over what collection window the fragment was built.
- Historical is any recovered table. A 2014 row is an archive object. It is not today’s weather.
The include is allowed to show derived columns. It is not allowed to let them impersonate sensors. A conditions word such as “Clear” or “Mist” is usually a software category, not a human synoptic observation. Treat it as a label from the member’s publisher.
Practical checks for anyone who still reads a shared strip
If you inherit a partner include, or you are tempted to quote one, ask four questions of each row:
- Who? Is there a stable station name or ID, not just a city?
- When? Is there an observation or harvest time, with a zone?
- In what units? Does every numeric column declare them?
- What kind of value? Observed, derived, or a placeholder such as offline?
If any answer is missing, do not treat the row as a comparable observation. Compare it with a neighbor only after those four match. Prefer official datasets when the claim is climatological. A hobby include is a convenience view of published personal stations. It is not MADIS quality control, and it is not an NWS METAR.
What still applies
The web stack moved from PHP includes and FTP drops to JSON widgets and APIs. The contract did not. Any map pin or “nearby stations” strip that omits ID, time, or units is the same failure this URL was built to avoid. TNET’s public statement of how weather records are treated as evidence is data sources, quality controls, and methodology. That page does not reconstruct this include, and this include is not a live TNET product.
The weather-station hub groups neighboring instrument articles. How TNET distinguishes observed, modelled, and derived information is how the service works. Neither page is a substitute for an official warning.
Sources
- NOAA / NCEP MADIS, Citizen Weather Observer Program: madis.ncep.noaa.gov/madis_cwop.shtml
- TNET, Data sources, quality controls, and methodology
- TNET, How the service works