Weather broadcast graphics and alerts automation

Overview

A long-running automation system for a weather channel operator, built in stages across two and a half years and twelve separate paid engagements with the same client, ten of them feeding this system and two written up separately here.

The relationship started on one freelancing platform and moved to another partway through. The client followed, which is the part of it I value most.

It is still running, and you can go and look. Years after the last contract closed, the compositing and posting pipeline is still generating the operator’s graphics and publishing them unattended. Nobody has needed me since.

The operator broadcasts as NRV Weather Center, and its Facebook photo stream is where the output of this system lands. Scroll back through it and you are scrolling through years of graphics this code composited and posted on its own.

To be exact about what is mine and what is not: I did not build that website, and I do not run it. It is the client’s, and it existed independently of me. What I built is the system behind the graphics and the slideshows, and the automated publishing that puts them out. The site is worth linking because it is the only way to see the output in its real setting, not because I had anything to do with the site itself. That is the claim I would rather be judged on than any of the delivery detail below: software nobody has to think about is the point, and this is the longest running proof I have that I can build it.

The problem

The operator needed broadcast graphics generated automatically on a schedule, with nobody opening a design tool. The output had to look produced rather than generated, and it had to keep running without supervision.

What I built

Image compositing that layers imagery from multiple sources into one finished graphic, live forecast and current-conditions data pulled from a weather API and plotted onto it, a full text styling system, aggregation of repeated readings, forward forecasting onto separate graphics, video export, and an alerting system that generates headlines and posts them to social platforms on a schedule.

How the work was actually scoped

I wrote the specification, not the client. The largest of the contracts began with me proposing it and attaching the scope document. The client’s offer came back two minutes later reading, in full, “As discussed.” Across twelve engagements the pattern held: he described an outcome, I wrote what would be built, and he bought that.

The social publishing was set up end to end, not just automated. Posting to a page needs the business assets to exist, be linked and carry the right permissions before a script can touch them. I did that configuration as well as writing the poster, so the client got a working pipeline rather than a script and a list of things he would have to figure out.

Scope roughly doubled, and every increase was agreed rather than absorbed. That contract was offered as a single milestone and delivered as three, through two change requests I raised and he accepted within the same evening each time. Nothing was quietly swallowed, and nothing was billed without being agreed first. There is a version of this project where I take the original number, work twice as long and resent it; that version does not get hired twelve times.

A seven week gap between the second milestone and the third, with the third activated and approved in the same minute. That is what a real testing phase looks like from the developer’s side: the system is with the client, being run against live conditions, and the correct thing to do is wait rather than invoice.

One review arrived two days after a new contract opened, praising the work that came before it. Repeat clients do not write testimonials at the end. They write them on the way into the next thing.

Complexities tackled

It has to run unattended for years, not demo once. Everything is driven by JSON configuration, so new locations, layouts and schedules need no code changes at all. Several instances run concurrently for different locations. The client changes what he needs far more often than he can wait for a developer.

Disk is finite and nobody notices until it is not. A generator producing images on a schedule will fill a disk eventually. The output buffer keeps a fixed number of recent files and rotates the oldest out, which sounds trivial and is the difference between a system that survives a year and one that stops on a Sunday.

Typography is the product. Weather graphics live or die on whether the numbers read at a glance. That is why the styling system covers font, size, weight, italics, underline, glow, outline, colour and alignment, with values rendered together with their units and labels. “Make the wind speed slightly bolder” should never require a developer.

Aggregation, not just display. Several readings for the same measure have to sum into one figure rather than printing three numbers next to each other, and forecasts have to render a configurable number of hours ahead onto their own graphics.

Somebody else’s API decides your uptime. The system depends on an external weather API on a schedule, so partial responses, rate limits and outages are ordinary conditions rather than edge cases.

Outcome

Every milestone across every engagement approved. I closed the final contract myself once the work was delivered and there was nothing outstanding, rather than leaving it open.

Stack

Python, Pillow for compositing, ffmpeg for video export, weather API integration, JSON-driven configuration, scheduled execution.