Sign inRegisterCheck connection

Cumulus Banner Variants as a Visual Style Guide

A gallery of Cumulus banner variants—day/night, metric/imperial—is a style guide for contrast and units, not a download of skins or a second generator.

Back to Cumulus weather software guides

A banner gallery is a set of pictures of status images: the same Cumulus station rendered in more than one palette, unit system, or density. The historical TNET URL /projects/phpggbanner/gallery collected those variants so an operator could see what a 468×60-class strip looked like before wiring a generator. This article treats the gallery as a visual style guide—day versus night, metric versus imperial, dense versus sparse—and explains why showing examples is not the same as offering downloads.

The generator article covers the tag-to-GD mapping and cache honesty. Here the subject is appearance as a scientific choice: contrast, unit labels, and the difference between a documented look and a redistributed skin pack.

Historical context

Personal weather sites of the 2000s published sample banners the way webrings published sample buttons. Visitors compared a “day” strip to a “night” strip, a compact numeric layout to one with a wind barb or a small plot. The Cumulus-host gallery sat next to the PHP GD project so the samples and the renderer shared a family, not so that TNET could keep shipping PNG assets in perpetuity.

Those sample files, if they still exist in archives, are other people’s pixels and often other people’s fonts. TNET does not rehost the historical ZIP, the skin folders, or a click-to-download wall of banners. A restored URL can still describe the taxonomy the gallery used and the reading rules that taxonomy implies.

What a variant is

A variant is not a different station. It is a different rendering contract applied to the same observation packet.

Hold the packet fixed: outside temperature, a named wind value, unit tokens, packet time. Change one axis of the rendering at a time:

  • Palette. Light panel versus dark panel. This is usually driven by a daylight flag such as Cumulus <#isdaylight> (realtime field 50 in the classic layout: 1 = daylight, 0 = not) or by a clock, not by the temperature itself.
  • Unit system. Metric versus imperial strings already present in the packet (C/F, m/s or km/h versus mph, hPa/mb versus in, mm versus in). The gallery’s job is to show that both systems remain readable at the same type size.
  • Density. Three scalars plus a name versus temperature-only. Density is a layout family, not a new data source.
  • Accent. A thin colored rule, an icon, or a wind-direction glyph. Accents that replace a unit string are not accents; they are missing labels.

If two gallery tiles differ in the numbers, you are no longer looking at style. You are looking at two times, two stations, or a stale cache. A style guide must say which.

Day and night are lighting, not weather

A night banner that tints the whole strip blue does not mean the air is cold. A day banner that uses a warm gold panel does not mean it is afternoon at the station. Palette is a presentation choice. Weather is in the numerals.

That distinction matters because Cumulus already has a daylight flag and a separate temperature field. Binding palette to <#isdaylight> is coherent if you document it: “dark chrome after local sunset.” Binding palette to temperature (“red above 25 °C”) turns the background into a second, unlabeled scale. Readers then have to decide whether the red panel or the printed 24.8 C is the observation. Print the number; keep the panel neutral enough that the number wins.

Night palettes fail more often than day palettes for a mechanical reason: antialiased gray type on a near-black JPEG becomes a smudge after forum software recompresses the file. A gallery should include a compressed night example, not only the PNG the generator emitted. If the night tile is unreadable after a typical JPEG pass, the style is not ready for signatures.

Daylight itself is not a global constant. <#isdaylight> is a station-location calculation in Cumulus, not a camera. A banner that switches chrome at civil twilight while a webcam still shows sun is not a bug in the webcam; it is two different definitions of “day.” Label the chrome rule if you show both.

Metric and imperial are labels, not skins

Cumulus realtime files carry unit tokens as their own fields. A metric tile and an imperial tile of the same layout should differ only in those tokens and in the numeric magnitudes that go with them. They should not differ in which variables appear, in type size, or in whether the unit is present.

A gallery that shows 22.4 on the metric tile and 72 F on the imperial tile is teaching the wrong lesson: that imperial readers get a unit and metric readers are expected to know. Both tiles need the unit string. Both tiles need the same decimal policy (Cumulus realtime uses a decimal point for script consumers; processed tags may follow locale unless modified).

Do not use flag icons, map outlines, or “US / UK / EU” badges as a substitute for <#tempunitnodeg>. Geography is not a unit system. A station in Canada may publish °C; a station in the United Kingdom may still use mph for wind. Paint what the packet says.

Rain is the layout that breaks first when units change. 1.2 mm and 0.05 in are the same kind of quantity at very different glyph widths. A gallery row for rain should prove that the imperial form still fits the box without clipping the unit. If it does not fit, drop rain from the 468×60 family rather than shrinking type.

Why a gallery is not a download

Three different objects get confused at this URL:

  1. A style guide—pictures plus notes on contrast, units, and density. That is what this page is.
  2. A generator—code that reads Cumulus tags or realtime.txt and emits a PNG. That remains the phpggbanner project.
  3. A skin pack—background PNGs, fonts, and maybe a PHP file in a ZIP. That is a software distribution. TNET does not rehost it.

Showing an example does not grant redistribution rights in the example. Fonts embedded in a sample banner may be licensed only for the original author’s site. Background photographs may be the station owner’s. A gallery tile is evidence of a look, the way a figure in a paper is evidence of a method. It is not source code and it is not a parts kit.

If you are building your own renderer, treat the gallery as acceptance tests:

  • Night tile remains readable after a moderate JPEG recompression.
  • Metric and imperial tiles keep identical structure and both show units.
  • A missing-value tile does not print 0.0 for a lost sensor.
  • A stale-packet tile does not wear a LIVE badge.
  • The avatar-sized crop of the banner (if anyone will crop it) is not treated as a substitute for the 80×80 avatar, which has its own density rules.

Those tests are about observation integrity. They are not a theme contest.

How to read a gallery you did not curate

Incoming links to this path often came from forum threads that said, in effect, “which banner looks best?” That is a fair visual question and a poor scientific one. When you look at someone else’s tiles:

  • Treat every number as historical unless the page states the packet time and the station.
  • Do not digitize pixels. If you need the series, ask for the tag file, realtime.txt, or the Cumulus logs.
  • If only one unit system is shown, do not infer the other by mental conversion from a screenshot; conversion belongs in software with explicit factors, not in a gallery caption.
  • A photogenic night banner is not quality control. Siting bias, a stuck anemometer, and a cached PNG all photograph well.

TNET’s own public research has to separate how evidence is grouped from how it is drawn. The grouping is evidence families. The service explanation—what is observed, modelled, or derived—is how the service works. A banner gallery is a small case of the same split: the look is derived; the numerals, if honest, are observed (or software-derived at the station) at a stated time.

The Cumulus hub lists the related projects. For the extra-file pattern that often fed these renderers, see the TNET web-tags project.

Sources