A weather station that can only be read as a graphical dashboard is a station that disappears on a slow link, a text browser, a screen reader that hits unlabeled widgets, or a handheld that cannot load the chart library. A text bulletin solves that in one move: it encodes the observation as a linear record a person can read aloud, archive, or parse. The scientific requirement is the same as for any other observation product. The sentence must carry temperature, wind, rain, and pressure with units and a timestamp that names the clock. Without those pieces, the bulletin is a fragment, not a record.
The historical URL /get-text.php served that text-oriented view of the original Mesa, Arizona station. A recovered capture from 23 January 2005, 00:56 local is used below only as a dated example of bulletin structure. Those figures are not current weather.
Historical context
Personal weather sites in the mid-2000s routinely published a heavy current-conditions page: styled tables, radar thumbnails, high/low grids, and system statistics. They also needed a thin counterpart. Text browsers such as Lynx, early phones and PDAs, and assistive technology that follows source order all need a sequence of labeled facts rather than a layout inferred from columns.
The original weather-station site kept several such surfaces. This URL was the text bulletin. A related handheld view lived at /pda-view.php. The recovered capture is one dated bulletin, not a live feed, and it is not rebuilt here as a dashboard.
What a complete observation sentence must contain
A professional METAR is the canonical example of a complete text observation: location, time, wind, visibility, weather, sky, temperature, dew point, and altimeter, in a grammar that implies units. A backyard bulletin does not need METAR code. It does need the same information contract.
Minimum viable bulletin:
- Station identity and location — enough to know which instrument produced the line.
- Timestamp with timezone or offset — clock time without a zone is not an observation time.
- Air temperature and unit — degree Fahrenheit or degree Celsius, stated, not assumed.
- Wind speed, unit, and direction — calm must be stated as calm (or zero with a unit), not omitted.
- Rain and the period — “no rain today” is a complete claim only if “today” has a timezone and a reset rule.
- Pressure, unit, and tendency if you have it — inches of mercury or hectopascals (millibars), not an ambiguous token.
Secondary fields—humidity, dew point, derived indices, solar, UV, cloud-base estimates—may follow. They are optional for a bulletin. They are not a substitute for the six items above. Derived indices (wind chill, heat index, humidex, apparent temperature) must be labeled as derived so they are not read as thermometer data.
Written as one sentence, the contract looks like this:
Station {id}, {location}, {timestamp with zone}: temperature {T} {temp unit}, wind {speed} {wind unit} from {direction}, rain {amount} {rain unit} since {period}, pressure {P} {pressure unit}, {tendency}.
That sentence is usable by a screen reader, a Lynx session, a PDA, and a later analyst who never saw the original stylesheet. A table that omits units in the header and relies on CSS column context is not.
Accessibility and low bandwidth are the same design
Screen readers and Lynx both walk HTML as a sequence. If a grid shows temperature first but the markup emits an access counter first, the bulletin is lying about what the page is. Emit identity, time, then observation fields, then optional extras.
A gauge that shows 40 without adjacent “40.0 °F” is invisible to a text client. The bulletin is that adjacent text, promoted to the whole page. WCAG’s rule that information must not depend on layout or color alone is the same rule as meteorology’s: a quantity includes its unit. “Thirty point one” is not pressure; “30.1 inHg (1020 hPa), steady” is.
Station hosts on modest links and visitors on early cellular fail the same way when the only conditions page pulls maps and widgets. A kilobyte-scale bulletin remains the fallback. The weather station archive collects the related instrument pages; this URL is the text-product sibling, not a second graphical dashboard.
A dated Mesa bulletin, used as structure rather than as weather
The recovered snapshot is labeled 23 January 2005, 00:56, for a private station in Mesa, Arizona. In that capture the station reported temperature 39.9 °F (4.4 °C), wind 0 mph from the north, no rain that calendar day, and pressure about 30.1 inHg with a millibar equivalent, tendency steady. Humidity, dew point, derived indices, near-zero nighttime solar and UV, and a sky note of night overcast were also present, plus a separate forecast line that is not an observation.
Those values are a historical example of bulletin structure. They are not current Mesa weather and not a live tool.
Observation versus forecast. The snapshot’s forecast sentence (partly cloudy, overnight lows, light wind) is a different evidence family from the thermometer. A bulletin may carry both, but readers who quote “the station said” need to know which clause was measured.
Unit tokens must be real units. Pressure is commonly inHg or hectopascals (hPa; millibars are numerically equal for this purpose). A nonstandard or mixed token makes the record harder to reuse even when the logger value was fine. High/low tables, sun and moon times, logger version, and indoor cabinet readings in the same capture are station diary, not the minimum observation. A low-bandwidth bulletin can omit them.
What an observation record must contain
The bulletin is a compact observation record. The same completeness test applies whether the destination is a text page, a logger file, or a research ingest:
| Field | Why it is required | |---|---| | Location / station ID | Otherwise the numbers are unattributed | | Time with zone | Otherwise they cannot be aligned with other records | | Variable name | Temperature is not heat index | | Value | The reading | | Unit | The reading’s scale | | Period or statistic | Instant, 24-hour total, daily maximum, and so on |
WMO observing practice treats those elements as part of the measurement. NWS METAR practice encodes them in a single line so a human or a parser can recover them without the original web layout. A backyard get-text.php is the informal version of that line.
TNET’s public research distinguishes observed, modelled, and derived information. A text bulletin is useful to that discipline only when it is honest about which clause is which. The 2005 Mesa snapshot is observed (temperature, wind, rain, pressure) plus derived (wind chill, heat index, humidex, apparent temperature) plus a forecast sentence. Mixing those without labels would make the bulletin unusable as evidence. The evidence families brief is the current explanation of that distinction.
Practical checklist
Emit station ID, location, and timestamp before any numbers. Put units in the text of every quantity. State rain as an amount and a period. Label derived indices as derived. Keep forecast language in a separate sentence. Keep the page linear: no essential fact that exists only as a CSS column or a chart. Treat the 2005-01-23 Mesa capture as historical. Do not present this URL as a live meter.
Modern relevance
Phones got faster. The need for a complete, linear observation record did not. Archives, APIs, and assistive technology still fail when the only published form of current conditions is a widget. A text bulletin remains the simplest honest product a station can offer, and the simplest product a later researcher can quote.
If you are tracing what belongs in an observation versus a modelled or derived field, start with the evidence families behind a connection outlook.
Sources
- World Meteorological Organization, Guide to Instruments and Methods of Observation (WMO-No. 8): community.wmo.int
- National Weather Service, METAR decode key: weather.gov (PDF)
- W3C, Web Content Accessibility Guidelines (WCAG) 2.2: w3.org/TR/WCAG22
- TNET, The evidence families behind a connection outlook