Sign inRegisterCheck connection

Weather-Photo Galleries as Observation Logs, Not Social Albums

Organize a Coppermine-era sky archive as an observation log: capture time, viewing direction, and weather labels on each still, not a social album.

Back to Personal weather station guides

A weather-photo gallery is an observation log that happens to use JPEG files. The index is where that log is organized: every still needs a capture time, a viewing direction, and a weather context, or the album is only a scrapbook. Visitors who bookmarked /gallery/index.php were looking at Coppermine Photo Gallery’s album list on the historical TNET Weather site. This page keeps that address. It does not restore Coppermine, does not replay recovered thumbnails, and does not treat “last comments” as meteorology.

The scientific job of an index is collection-level: which albums exist, what each album is allowed to contain, and which fields every file must carry before it is listed. The job of a single still is citation. That record-level problem belongs on the single-image observation page.

Historical context

Mid-2000s personal weather sites often bolted a PHP gallery onto the station host because the logger already wrote files and the operator already had FTP. Coppermine Photo Gallery was a common choice: albums, categories, user galleries, “last uploads,” and a login. A recovered capture of this URL showed Coppermine 1.3.3 chrome—album list, login, last comments, most viewed, random files. Those controls are social-gallery furniture. They are evidence of the software, not of the sky.

The original albums, thumbnails, comments, and view counters are not rehosted. Incoming links wanted the gallery home. The restoration keeps the home and replaces the furniture with the catalog rules a sky archive actually needs.

Coppermine is named here as historical software. TNET does not distribute it, does not run it at this path, and does not claim authorship of recovered gallery assets.

Why a sky archive is not a social album

A social album optimizes for browsing. Newest first, most viewed, random, and comment threads are ranking devices. They answer “what is popular?” They do not answer “what was the sky in this direction at this time?”

An observation log optimizes for retrieval and comparison. The visitor (or the operator, a year later) must be able to find:

  • stills from one camera or one viewing direction;
  • stills inside a stated time window;
  • stills that share a weather label (clear, overcast, precipitation visible, blowing dust) without treating that label as an official cloud observation.

“Most viewed” is not a quality flag. A sunset that was clicked often is still one JPEG at one time. “Random files” is the opposite of a time series. “User galleries” that mix family photos with sky stills break the collection: the index can no longer promise that every listed file is a weather observation.

The index may still group files into albums. The album title has to be an observing category, not a mood. Useful album names look like “North sky, 15-minute stills,” “Gauge-yard context,” or “Retired camera CAM02.” Useless names look like “Nice shots” or “Misc.”

The metadata a weather still needs before it is listed

The index should refuse to list a file that cannot support a later citation. Minimum fields:

| Field | Role | |---|---| | Capture time | Instant the exposure was made, with timezone | | Camera or album ID | Stable token; not a filename that gets reused | | Viewing direction | Azimuth in words or degrees, or “unknown” | | Scene in one line | What the lens is allowed to show (sky, instruments, named horizon) | | Weather context | Optional operator note, labeled as a note, not as METAR | | File identity | Original filename plus a checksum if you migrate storage |

Capture time is not FTP modification time. A batch upload stamps every file with the same second. Capture time is not the gallery’s “date uploaded” column. Coppermine’s upload clock is a website event. The observation is the exposure.

Viewing direction is what makes two stills comparable. A north sky and a west horizon are not the same series. If the mount was panned, the index must not keep the old album name as if the azimuth were fixed. Retire the album or mark a mount-change date. Reusing an album the way a social gallery reuses a folder is how a time series quietly changes instrument.

Weather context is a caption aid, not a substitute for the logger. “Rain visible in frame” is an observed remark about the image. “0.24 in today” belongs in the station tables, and only if that total has its own timestamp. Do not print a temperature on the album tile. A number next to a thumbnail implies the air and the frame were simultaneous. That coincidence is a clock-sync problem for the single-image page, not a reason to decorate the index.

Album structure that preserves observations

Organize first by instrument and direction, then by time. A year album that mixes every camera is convenient for a New Year’s post and hostile to analysis.

A workable tree:

  1. Camera ID (or “handheld” if that is honest).
  2. Mount period if the camera moved.
  3. Calendar period (month is enough; day folders if cadence is high).
  4. Stills, named so lexical sort is time order when the filename carries a sortable timestamp.

The index page shows that tree as albums and counts. Counts are inventory: how many files are in the collection. They are not climate statistics. Do not turn “273 files” into a weather claim, and do not reprint recovered Coppermine counters as if they were current.

Access control is not an observing category. If some albums were private, the public index should say that a private set exists and is not listed, rather than showing locked thumbnails that invite guessing. Recovering a forgotten Coppermine password is a preservation problem, not a gallery feature; that workflow is on the archive-access page.

What the index must not do

It must not present comments as observations. A guest remark that “it looks like virga” is not a cloud type.

It must not autoplay a random still in the hero. Random playback is a shuffled sequence. Time-ordered playback is a different product, and it belongs on a slideshow that discloses order, not on the catalog.

It must not label the gallery “live webcam.” A Coppermine album of uploaded JPEGs is a historical collection. A station webcam with a stated interval is an instrument on a different URL. The index may mention that instrument. It must not impersonate it.

It must not host other people’s photos under the station identity. If a neighbor’s camera was ever ingested, the album must say so or the files must not be listed.

It must not restore Coppermine login, registration, or e-card features. Those are account surfaces on old PHP. They are out of scope for an observation catalog.

Practical checklist

  • Every listed still has capture time and timezone, or it is in a holding album named “time unknown.”
  • Albums are named by camera, direction, or mount period, not by popularity.
  • Direction changes close a series; they do not silently continue it.
  • No temperature, rain total, or forecast icon on the album tile.
  • No “most viewed,” “random,” or comment count as a scientific sort.
  • Public index does not claim a live camera and does not restore Coppermine accounts.
  • Inventory counts are file counts, dated if shown, never treated as climate.

Modern relevance

Phone libraries and object storage made Coppermine look optional. The catalog problem did not go away. A folder of HEIC files named IMG_4588 is a worse observation log than a 2005 PHP album that at least had captions, if those captions carried time and direction. Operators who keep sky stills beside a modern logger still owe the same index: identity, time, direction, and an honest weather note.

Cloud-object browsers that sort by upload time recreate Coppermine’s “last uploads” mistake. EXIF DateTimeOriginal (when present and trusted) is closer to capture. Overlay clocks are closer still if they were burned in at capture and the camera clock was set. None of those clocks should be invented in the index if they are missing in the file.

TNET does not operate a photo gallery at this path. Anyone who followed /gallery/index.php for an album list gets the rules that list required.

TNET research bridge

Collection metadata is provenance: which instrument, which place, which time system, which files belong together. That is the same discipline TNET applies to source identity in data sources, quality controls, and methodology. Distinguishing an observed still from a caption, a comment, or a derived slideshow is the vocabulary on how the service works. The weather-station hub groups this catalog with other instrument pages.

Sources