Forecasting data design: stations, models, formats and direct access

This report explains where the numbers on the forecasting page come from and how they are stored. A household in Cumberland Center, Maine, compares free weather forecasts from the National Oceanic and Atmospheric Administration (NOAA) with what its own and nearby weather stations measured, checks whether the stations are still accurate, estimates solar production and forecasts two weeks of heating cost. The model data is read in cloud-native formats, which let a program fetch just the small piece it needs instead of downloading whole files. Reading one year of hourly temperature at the house took 19.3 megabytes (MB) and one second, against roughly 9 gigabytes (GB) in NOAA's traditional files. Checking the stations against two independent references found that the house station has drifted about 2 degrees Fahrenheit (degF) colder since December 2025, and that one volunteer station (E4229) records missing readings as zeros, so it was removed from all analyses. Every forecast is checked against what actually happened. Solar production forecast for tomorrow missed by 7 kilowatt-hours (kWh) on a typical 47 kWh day, against 17 kWh for the normal, and was clearly better than the normal for 5 days. A gas bill forecast a month ahead missed by 24% on average, barely worse than the 22% with the weather already known, so the gas usage model, not the weather forecast, limits it. Household electricity use depends more on habits than on weather: the forecast for tomorrow missed by 7.6 kWh of a typical 42 kWh day, and most of its advantage over the normal comes from tracking the household's recent level of use. The report closes with the one open design decision: keep reading the data through its publisher's helper library, or write our own access code. It recommends keeping the helper library until a concrete reason to switch appears.

The report is written for several audiences at once. Each section starts with In plain terms, for readers who are not developers or scientists, followed by For developers, with the technical detail. Terms are explained where they first appear, and Appendix B collects every term and acronym with a link to more information. Click any figure to open it full size. The list below links to every figure, table and code listing.

The weather site has two pages about forecasting. The first, Forecasts and Model Checks (forecasting.html), shows results. This page, the design report (forecasting_design.html), explains where those results come from.

The project asks four practical questions about one house in Cumberland Center, Maine:

1. Solar: how much sunshine reached the house each day, and did the solar panels make as much electricity as that sunshine should have produced? A shortfall points to snow on the panels or an equipment fault. And how well can production be forecast days ahead?
2. Station checks: are the local weather stations still telling the truth? Each station is compared with two independent estimates of the weather at the same spot, so a sensor that slowly goes wrong (called drift) shows up.
3. Forecast accuracy: how good are the free government weather forecasts for this house, and for how many days ahead are they better than simple guesses such as "tomorrow will be like today" (persistence) or "it will be a normal day for the date" (climatology)?
4. Heating outlook: how cold will the next two weeks be, and what will heating cost? The answer is a range, for example "$51 to $64, most likely $57", rather than a single number. And how close would a forecast made weeks ahead have come to each actual gas bill?
5. Electricity: how much electricity will the house use in the coming days, how much will the solar panels cover, and how much of daily use does the weather explain at all?

One rule runs through every analysis: each forecast is shown next to a check of how well that kind of forecast has done in the past. A forecast without a track record is hard to trust.

The data comes from three kinds of sources. Weather stations measure what actually happened (observations, or "ground truth"). Weather models are large computer simulations run by the National Oceanic and Atmospheric Administration (NOAA), the weather agency of the United States (US), that estimate the weather on a grid of squares covering the country, both for the past (an analysis) and the future (a forecast). PRISM, the Parameter-elevation Regressions on Independent Slopes Model, is a set of daily weather maps from Oregon State University, built from thousands of stations, that serves as an independent reference. Three NOAA models appear throughout: the High-Resolution Rapid Refresh (HRRR), the Global Forecast System (GFS) and the Global Ensemble Forecast System (GEFS), described in section 2.2. The two reference stations are the house's own station, ZASTMET, and the official station at the Portland International Jetport (KPWM). Solar production is modelled with the European Commission's Photovoltaic Geographical Information System (PVGIS). Household records (gas and electric bills, solar production, the thermostat) turn weather into money (Figure 1).

This report has a second goal: the project is a hands-on way to learn cloud-native data formats, a newer way of storing large scientific data on the internet so that a program can read just the small piece it needs. Section 3 explains these formats from the ground up, and sections 4.4 to 7 weigh the one design decision still open.

dynamical.org, the non-profit that republishes NOAA's model data, offers a small helper library (the "wrapper") that finds and opens its datasets in one call. The project could instead read the storage directly with its own code. Both give identical numbers; they differ in effort, in what the project learns, and in who has to keep the code working when dynamical.org changes something. This is decision D7 (Phase 1M). The owner decided to keep the wrapper until further notice; sections 4.4, 4.5 and 6 lay out the facts so the decision can be revisited.

Section 2 describes the data: the weather stations and the weather models. Section 3 explains the data formats, first how cloud-native formats differ from traditional ones, then each format in turn. Section 4 describes the methods: the data pipeline, how stations are checked, how each forecast is checked against what happened, and the two ways of reading dynamical.org. Section 5 gives the results: what the station checks found, how cloud-native access compares with the traditional route, and how good each forecast has been. Section 6 weighs the direct-access option, and section 7 states the recommendation.

A weather station is a set of sensors on a pole: a thermometer and humidity sensor inside a vented shield that keeps direct sun off them, a wind cup and vane, a rain gauge, and sometimes a sunlight sensor. Stations differ a lot in quality. An official airport station is professionally maintained and has a fan that pulls air past the thermometer, so sunshine cannot warm it. A consumer station costs a few hundred dollars and relies on still air moving through its shield on its own, so on sunny, calm days it can read a degree or two warm. Any sensor can also drift: its readings slowly shift over months as parts age or the shield gets dirty.

The project collects six stations within about 22 km of the house and analyses five of them. Two, the airport (KPWM) and the house station (ZASTMET), are the "truth" that forecasts are scored against. E4229, a volunteer station of the Citizen Weather Observer Program (CWOP), is still collected but has been left out of every analysis since 2026-10-27, because its readings are faulty (section 5.1.3). The other three are volunteer stations used for comparison and quality checks (Table 2).

Table 2. The weather stations.

Three older stations (E1248, G5907 and BARDHAM) went offline and are no longer collected (Figure 2).

How station data reaches us. Station data arrives the traditional way: as small text files and web responses that a script downloads every day and stores row by row in the project's database (MariaDB). The volunteer stations send their readings to the Citizen Weather Observer Program (CWOP). NOAA's Meteorological Assimilation Data Ingest System (MADIS) service checks those readings for obvious errors, and the Gladstone Weather Network publishes them with quality statistics; fetchweather.sh downloads them from there. The airport's hourly reports (called Meteorological Aerodrome Reports, or METARs) come the same way. The house station posts to ambientweather.net, whose web Application Programming Interface (API) the project reads directly. The house station is not part of CWOP, so NOAA's models never see it, which makes it the cleanest independent test of those models (Figure 3).

A weather model is a computer program that splits the atmosphere into a 3-D grid of boxes and steps the physics of air, water and sunlight forward in time, a few minutes per step. It starts from the best estimate of the weather right now, built from millions of observations (stations, balloons, aircraft, satellites, radar). NOAA runs several models on supercomputers at its National Centers for Environmental Prediction (NCEP) and publishes the results free of charge. dynamical.org, a non-profit, reformats them into cloud-native stores (section 3), which is how this project reads them.

The project uses three NOAA models and one observation-based map product (Table 3):

Table 3. Weather models and map products used.

Models produce three kinds of output, and the difference matters:

• Analysis. The model's best picture of the weather at a moment that has already happened, made by blending a short forecast with the observations that arrived since. It is not a measurement, but it covers every grid square, including places with no station. HRRR's hourly analyses since 2014 form an hour-by-hour weather history of the whole country.
• Forecast. A run starts at a fixed time (the run time or initialization time, for example "12 UTC on 27 October") and steps forward. Each output is labelled by its lead time, how far ahead of the run time it is ("24 hours ahead"), and its valid time, the moment it describes (run time plus lead time). Forecasts get less accurate as lead time grows; measuring how fast is the job of the forecast accuracy charts.
• Ensemble forecast. One forecast gives one answer, but small errors in the starting picture grow until, after a week or so, they dominate. An ensemble runs the model many times (GEFS: 31 members) from slightly different starting points. Where the members agree, confidence is high; where they spread apart, the future is genuinely uncertain. The heating outlook turns that spread into a range: "8 in 10 chances the cost lands between $51 and $64."

PRISM is different from all three: it is not a physics model and makes no forecasts. It is a statistical method that spreads station measurements across the map, using how temperature and rain change with elevation, slope and distance from the coast. Its output is a daily map of what did happen, plus normals: the average day for each date over 1991-2020, which serve as the "climatology" baseline. PRISM revises each day's map several times over six months as late station reports arrive (Figure 4).

Every model output is a set of variables (temperature, humidity, wind, sunlight, rain and many more), each stored as a grid of numbers. A few details matter for using them correctly:

• Height. Temperature is reported at 2 m above the ground, the height of a station thermometer, and wind at 10 m.
• Instant or total. Temperature is an instant value at the valid time. Rain and sunlight are amounts over a period (an hour, or since the run started); dynamical.org converts them to rates so every hour can be read on its own.
• Map projection. The Earth is round and grids are flat. HRRR uses a Lambert conformal projection, a cone-shaped flattening suited to mid-latitudes, with squares measured in metres. GFS and GEFS use a plain latitude and longitude grid. The project converts the house's latitude and longitude to the right square in each.
• One square, not one spot. A model value describes the average of a whole grid square: 3 km by 3 km for HRRR, roughly 20 km by 28 km for GFS here. A backyard thermometer can differ from it for real reasons, such as a hill, a lake or a parking lot.

A data format is the agreed layout of numbers inside a file, so that the program that wrote them and the program that reads them understand each other. The weather data here comes in six formats (sections 3.2 to 3.8). They fall into two families.

Traditional formats were designed when data lived on a local disk or was copied whole from a server. To use them you download the entire file, then open it. That works for one file, but weather model output is published as one file per model run per forecast hour, each covering the whole country with hundreds of variables. Answering "what was the temperature at my house every hour last year?" means downloading thousands of large files to keep one number from each.

Cloud-native formats are designed for object storage, the internet-scale file storage run by providers such as Amazon's Simple Storage Service (S3), where every file (called an object) has a web address. They rest on one feature of the web: a program can ask a server for just a slice of a file, say bytes 5,000 to 9,000, instead of the whole thing (an HTTP range request; the HyperText Transfer Protocol, HTTP, is how browsers and programs fetch web content). A cloud-native format arranges its contents so that a small, predictable part (the index or metadata) says exactly where every piece of data sits, and the data itself is cut into many separately compressed pieces (chunks). A reader fetches the index, works out which chunks it needs, and fetches only those.

An everyday comparison: a traditional file is like a book without a table of contents that you must photocopy in full to read one page. A cloud-native store is like a library catalog plus numbered shelves: look up the page, walk to the shelf, copy only that page (Figure 5).

The main ideas, each with its traditional counterpart (Table 5):

Table 5. Main ideas of cloud-native formats and their traditional counterparts.

What it costs. Cloud-native layouts are tuned for an expected kind of question. A store arranged as long time series for small areas is fast for "one place, many hours" and slow for "the whole country, one hour", because that touches many chunks. Each web request also has a fixed delay, so very small chunks waste time; formats group them into larger objects (shards) to compensate. And the tools are younger than the traditional ones.

The table below pairs each traditional format with the cloud-native format that replaces it in this project. Sections 3.3 to 3.8 explain each one in detail (Table 6).

Table 6. Traditional formats and the cloud-native formats that replace them here.

Figure 6 contrasts the two ways of storing a large grid.

The project touches six kinds of data containers. Four come from outside: a catalog that says where datasets live, a versioned repository, the grids of numbers inside it, and NOAA's original forecast files. Two are our own: tables of numbers per weather station, and the map images PRISM provides. Each container is built so a program can find and read a small piece without downloading the whole thing; that single idea is what "cloud-native" means here (Figure 7).

STAC (SpatioTemporal Asset Catalog) is a set of small web documents that describe datasets: their names, dates covered, variables, licence, and the address of the actual data. A program reads the top page, follows the link for the dataset it wants, and gets the address of the repository. It is a table of contents with machine-readable links.

Two terms: JSON (JavaScript Object Notation) is a plain-text way to write structured data, easy for both people and programs to read; a link in STAC is a web address with a label saying what it points to (a child dataset, a licence, the data itself). The traditional counterpart is a folder listing on a web or File Transfer Protocol (FTP) server, or a THREDDS catalog: a person, or a script written for that one site, has to know how the folders and file names are laid out. STAC is a shared standard, so the same code can browse any STAC catalog, from satellite pictures to weather models (Figure 8).

Icechunk gives a folder of data files the behavior of a database: changes are saved all at once or not at all, every save gets an ID, and any earlier save can be reopened. dynamical.org saves a new version roughly every hour as model runs arrive. Our own grid cube on lamp is an Icechunk repository too, so the same version history applies to our copy.

Some terms: a commit is one saved change; a snapshot is the complete state of the data after a commit, with its own ID; a branch is a named pointer to the latest snapshot (usually main); a tag is a permanent name for one snapshot. The traditional counterpart is a folder of files that gets overwritten: if the power fails halfway, or someone reads while files are being replaced, they get a mix of old and new, and yesterday's version is gone. Icechunk borrows its ideas from Git, the version-control system programmers use for code, and from table formats such as Apache Iceberg that bring database-style transactions to object storage (hence the name) (Figure 9).

Inside the repository, each weather variable is a grid of numbers with three directions: time, north-south and east-west. For HRRR temperature that is 105,810 hours by 1,059 by 1,799 cells. The grid is cut into tiles of 90 days by 135 km by 135 km, and groups of 120 tiles are packed into one stored object with a small index at the end. To read one place for one year, a program reads each object's index, then just the few tiles it needs. Numbers are rounded slightly (to about 0.1 degrees Celsius (degC) for temperature) and compressed.

Some terms: an array is a grid of numbers with several directions, called dimensions (here time, north-south and east-west); a chunk is one block of the grid, stored and compressed on its own; a shard is a bundle of chunks stored as one object to save web requests; a codec is one step that encodes or compresses the bytes on the way in and reverses it on the way out; metadata is the description of the data (its shape, type, units and chunk layout) rather than the data itself.

The traditional counterparts are NetCDF (Network Common Data Form) and HDF5 (Hierarchical Data Format version 5), the standard scientific formats for decades. They also cut data into chunks, but keep everything in one large file with its index spread inside it. That suits a local disk but needs many back-and-forth requests over the internet, and only one program can safely write the file at a time. Zarr instead stores each chunk (or shard) as its own object with its own address, plus one small metadata file.

The shape of the chunks decides which questions are fast. dynamical.org makes each chunk a long time series for a small area, because most users ask about places over time (Figure 10):

Figure 11 shows how the HRRR temperature array is cut into shards and chunks.

NOAA publishes its model output as GRIB2 files: one file per model run and forecast hour, holding many whole-country maps one after another. A "virtual" dataset does not copy those maps; it keeps a list of where each map sits inside NOAA's files and reads it from there when asked. That makes new runs available sooner, but each read pulls a whole map, so it is slow for a single location's history.

GRIB stands for GRIdded Binary. It is the World Meteorological Organization's standard for exchanging model output, and edition 2 has been in use since the early 2000s. To save space it packs numbers tightly: instead of storing each temperature as a full-precision number, it stores small whole numbers plus a recipe (a reference value and scale factors) to turn them back into temperatures. A message is one map of one variable at one height and one time. A virtual dataset holds addresses that point into someone else's files, not copies of the data (Figure 13).

Parquet is a file format for tables that stores each column separately and compressed, with a summary at the end saying what range of values each column holds. Our tables are split into folders by data source, station, year and month, so a question about one station and one month opens one small file, and a program can skip files whose summaries rule them out without reading them.

Some terms: a row is one record (one reading at one time); a column is one field across all records (every temperature). Traditional tables, a CSV (comma-separated values) text file or a database such as MariaDB, store data row by row, so averaging one column still means reading every field of every row. Parquet stores each column together. It reads only the columns asked for, and similar values side by side compress very well. It also records the smallest and largest value of each column in each block, so a question about "September 2026 only" skips blocks that cannot match.

The catch: a Parquet file is written once and replaced, not edited row by row. That suits history and analysis, while a database suits constant small updates. This is why the station readings stay in MariaDB, and the analysis tables built from them are Parquet (Figure 14).

Figure 15 shows the partition folders and the inside of one of these files.

PRISM publishes each day's map as a GeoTIFF image whose pixels are values (solar energy, temperature, rain) instead of colors. "Cloud optimized" means the image is cut into square tiles with a table of where each tile starts, plus smaller preview copies, so a program can fetch one tile. PRISM wraps the image in a zip file, though, and zip compression hides the tile positions, so we download the whole 2.7 MB file and read our station points from it.

Some terms: a raster is a picture made of a grid of cells (pixels), here each holding a number rather than a colour; GeoTIFF is the long-standing Tagged Image File Format (TIFF) picture format plus tags that say where on Earth each pixel lies; a tile is a square block of pixels; an overview is a smaller, coarser copy of the whole picture for zoomed-out views.

A plain GeoTIFF often stores its pixels in strips (whole rows across the map), may keep its table of contents at the end of the file, and has no overviews, so a program usually downloads the whole file. Older PRISM downloads used the BIL (band interleaved by line) format: raw numbers plus a separate header text file, also downloaded whole. A COG is still a valid GeoTIFF that any older tool can open; it simply orders its contents so that one small read at the start reveals where every tile is (Figure 16).

Figure 17 shows what a PRISM daily download contains.

Every day, lamp checks for new data from two outside sources, NOAA model data (through dynamical.org) and PRISM. It keeps a copy of the model grid around the stations, pulls each station's values into small tables, combines them with the house's own weather station and solar records, and draws the charts on the forecasting web page. Each step uses a library designed for one format, so every piece of data stays in the format best suited to how it is used (Figure 18).

No station is perfect, so each one is compared with two independent references at the same location:

• The HRRR analysis: NOAA's best estimate of the weather each hour on a grid of 3 km squares, made by blending a weather model with all available observations. Comparing a station with the HRRR square it sits in shows its offset (how much warmer or colder it reads, on average).
• PRISM: daily maps of high and low temperature from Oregon State University, built from thousands of stations and adjusted for terrain.

A steady offset is normal, because a 3 km square is not the same as one spot in one backyard. What matters is a change in the offset, which means something changed at the station.

Every forecast on the results page is checked against what actually happened, once that is known. Five analyses do this, one for each thing the house cares about: temperature, solar production, heating degree days, the gas bill and electricity use. They share one method, described first, then each analysis in turn. Table 11 summarises them.

Table 11. The forecast checks: what is forecast, what it is checked against, and the baselines it must beat.

Four ideas recur in every check.

• Lead time is how far ahead a forecast was made. A forecast for tomorrow made today has a lead of one day. Forecasts get worse as the lead grows, so every score is broken down by lead.
• Error measures. The bias is the average error with its sign: a positive bias means the forecast ran high. The mean absolute error (MAE) is the average size of the error, ignoring its sign; it is the main score, and smaller is better (0 is perfect).
• Baselines. A forecast is only useful if it beats a simple guess that needs no model. Persistence guesses that the future will be like the latest observation ("tomorrow will be like today"). Climatology, or the normal, guesses the average for that date over 1991-2020. The skill score compares the two: skill = 1 - MAE of the forecast / MAE of the baseline. A skill of 1 is a perfect forecast, 0 is no better than the baseline, and below 0 is worse (Murphy 1993).
• Ranges. An ensemble forecast gives a range, here the band that should contain the actual value 8 times in 10 (from the 10th to the 90th percentile, p10 to p90). Its coverage is how often the actual value really fell inside; the target is 80%.
• Uncertainty. A score is an average over a limited sample, so the dated results reports give a 95% confidence interval (CI) for each one. It comes from a moving-block bootstrap#Block_bootstrap): the scored days are resampled in runs of 7 consecutive days, 2,000 times, and the middle 95% of the recomputed scores forms the interval. Whole weeks are drawn because weather errors persist for several days; gas bills are drawn in runs of 3. A forecast is clearly better than a baseline when the lower end of its skill interval is above zero.

A useful way to read the solar and gas checks is to split the error into two parts. Even with perfect knowledge of the weather, turning weather into kWh or therms is not exact: panels get snow and shade, and a house uses gas for hot water and cooking as well as heat. This is the usage-model error, measured by feeding the observed weather into the same calculation (the known-weather floor, or lead 0). The rest of the error, the gap between a forecast's score and the floor, comes from forecasting the weather (Figure 21).

The temperature check asks how good the NOAA forecasts are for this house, and for how many days ahead. Every stored run of the two models is compared with the house and airport stations hour by hour, and with PRISM for the daily high and low.

Production is estimated in three steps:

1. Take the day's sunlight on flat ground.
2. Convert it to what this tilted array should make, using the European Commission's Photovoltaic Geographical Information System (PVGIS) model of the exact system, month by month.
3. Scale it by how the real array compares with that model.

With known weather, the sunlight comes from PRISM's measured value or from the HRRR analysis (NOAA's estimate of what happened). This measures the usage-model error. With a forecast, the same chain starts from the sunlight that HRRR or GFS predicted days earlier, and the result is scored against what the SolarEdge inverter recorded.

The forecasts are also compared with the two baselines:

• Persistence: the last full day's production.
• Normal: production in average 1991-2020 sunlight for the date.

The house heats with a gas boiler, so cold weather means gas.

• Heating degree days (HDD) measure the cold: how far a day's mean temperature falls below 65 degrees Fahrenheit (degF), or 18.3 degC.
• Usage model: fitted on three years of gas bills, it turns degree days into therms of gas (one therm is about 29.3 kWh of heat).
• Forecast: NOAA's Global Ensemble Forecast System (GEFS) runs its model 31 times with slightly different starting points. The spread of the runs gives a range for the coming 35 days.

Two checks follow:

1. Degree days: every daily GEFS run since October 2020 is compared with the degree days observed at the airport, in heating seasons (October to April).
2. Gas bills: gas is metered only once a month, so the gas forecast can only be checked one bill at a time. - For each bill, every GEFS run from the 35 days before the meter read is replayed. - Days before the run use the degree days that were observed; days from the run on use that run's forecast. - The usage model, fitted only on earlier bills, turns the result into therms, which are compared with the bill. - The same days are also filled with normal weather, and with persistence (the last observed day repeated). - At 0 days before the meter read the weather is fully known, so that point is the usage-model error alone.

The electricity check asks how much electricity the house will use in the coming days, how much of it the solar panels will cover, and how good such forecasts have been.

The "actual" is the household's daily use, however it is supplied:

• Before the panels (until January 2026): the utility's billing meter measured all of it.
• Since the panels went in: use is what came from the grid, plus what the panels made, minus what went back to the grid.
• Recent days: the utility's data is downloaded by hand and lags by weeks, so for recent days the SolarEdge monitoring system's own figure is used. It is scaled up by 3%, the amount it reads below the meter.

The usage model is a change-point model, the standard way to relate a building's energy use to the weather. It comes from the Princeton Scorekeeping Method (Fels 1986), which is unrelated to the PRISM weather maps despite the shared name:

• Base load: a fixed amount of use per day.
• Heating: an extra amount for each degree the day's mean temperature falls below a balance point.
• Cooling: an extra amount for each degree above a second balance point (air conditioning).
• Weekends: a small extra amount.

Temperature explains only part of daily use; habits matter as much. The forecast therefore adds the household's recent level: how far above or below the model use has run over the past four weeks. Every past GEFS run since October 2020 is replayed through this model and scored against what the household actually used.

Three baselines apply:

• Persistence: the last day's use.
• Normal: the model fed 1991-2020 weather.
• Normal plus the recent level: this one shows what the weather forecast adds on top of simply knowing the household's habits.

Net grid use is use minus solar production: what the house draws from the grid, or sends to it when the number is negative. Its forecast combines the use forecast with the solar forecast of section 4.3.3, and covers the days with solar forecasts.

The wrapper is a small helper library from dynamical.org. Given a dataset name, it reads the catalog, works out where the data lives, opens the repository with the right settings, and returns the data ready to use. It retries when the catalog is briefly unreachable, checks that the catalog makes sense, and handles the extra setup that virtual datasets need. It is about 800 lines of code (Figure 22).

Going direct means writing those steps ourselves: read the one catalog entry we need, connect to storage, open the repository at a known version, and open the arrays. Each step is a few lines with the underlying libraries. The work is not in the normal path; it is in deciding what to do when something is missing, slow or changed (Figure 23).

Each station's average offset from PRISM, by year, is summarised below (station minus PRISM, in degrees Fahrenheit; a positive number means the station reads warmer). The subsections then take the stations one at a time (Table 14).

Table 14. Station offsets against PRISM by year, with verdicts.

KPWM is the official National Weather Service station at the airport, 19 m above sea level near the coast. It is an ASOS (Automated Surface Observing System), the standard US airport station. Its thermometer sits in a shield with a fan that pulls outside air past it (an aspirated shield), so sunshine cannot warm it, and technicians maintain and calibrate it. It reports once an hour, just before the hour (at :51), plus extra reports when the weather changes quickly. It is the most trustworthy station here and the one used for heating degree days, the gas usage model and the heating outlook.

Two cautions. First, because it reports only hourly, its daily high and low can miss a short peak between reports, so they read slightly less extreme than a station sampling every 5 minutes. Second, NOAA's models and PRISM both use KPWM as an input, so KPWM agreeing with them proves less than ZASTMET agreeing with them.

ZASTMET is the owner's own station at the house, an Ambient Weather WS-2902. It is an all-in-one sensor unit on a pole: thermometer and humidity sensor inside a stack of white plates (a passive radiation shield, with no fan), wind cups and vane, a rain gauge that counts small tips of a bucket, and a light sensor for sunshine and ultraviolet (UV) light. It is solar powered and sends its readings by radio to a console indoors, which posts them to ambientweather.net every few minutes. The project reads them from there, one reading every 5 minutes.

Ambient states the thermometer is accurate to within 2 degF and the light sensor to within 15%. Both limits show up in our data:

• Sunshine reads low. The light sensor measures brightness and converts it to solar power with a fixed factor. Against PRISM's satellite-based sunshine it reads about 27% low (PRISM is 1.37 times the house value, over 484 days), so the solar charts scale it before use.
• Sunny-day warmth. Without a fan, the shield warms in strong sun and light wind. In 2024 and 2025 the house's daily highs ran 1.4 to 1.8 degF above PRISM, while its lows were close.
• Temperature drift since December 2025. Compared with the HRRR analysis, the house station read about 0.5 to 1 degF warmer through 2024 and most of 2025. From December 2025 it has read 0.3 to 1.4 degF colder: a swing of about 2 degF. The airport station, compared with the same HRRR grid over the same months, did not move, so the change is at the house station and not in the model. PRISM shows the same thing: the house's highs fell from 1.8 to 0.6 degF above PRISM, and its lows from 0.0 to 0.8 degF below.

Figure 24 shows the monthly offset against the HRRR analysis.

Each point is one month; the station was offline from mid-September 2024 to May 2025, so those months are missing: the axis jumps from 9/24 (September 2024) to 5/25 (May 2025). Possible causes worth checking at the station: a dirty or cobweb-filled shield, a sensor that is aging, a change in mounting height or surroundings (new shade, a nearby surface that warms or cools), or a low battery. A side-by-side check with a trusted thermometer for a few days would settle it. The station checks chart on the results page tracks this offset every day.

CWOP stations belong to private volunteers who share their readings with NOAA. They fill the gaps between official stations, but quality varies and nobody checks the hardware. Their main use here is to compare with each other and with PRISM, and to show what a faulty station looks like.

• E4229 (Cumberland, 64 m): no longer used. Two serious problems led to its removal from every analysis on 2026-10-27 (its readings are still collected). Since 2020 its daily highs have run about 5 to 7 degF above PRISM, and in 2020-2021 its lows ran 6 to 8 degF above too (before 2020 both were within about 1 degF). That suggests the sensor was moved, re-shielded or sits in a warm spot. Since 2022, about one reading in eight has temperature, dew point and humidity all exactly 0 while pressure keeps reporting: these are placeholders for missing readings, not real cold. They drag daily lows down by more than 30 degF and pull daily and weekly averages cold. Five readings of -90 degF in 2024 are also errors. The main site's charts had already dropped it in July 2026; the forecasting PRISM checks, the data quality report and the analysis notebook dropped it on 2026-10-27.
• E4279 (Gray, 96 m, Davis Vantage Pro2). A well-known hobbyist station design (Davis Vantage Pro2). Its lows ran 1.3 to 4.2 degF below PRISM in 2017-2022 and are within 0.7 degF since 2024. MADIS notes its dew point has larger errors than usual. It was offline from February to November 2025.
• G5290 (Yarmouth, 30 m). Daily lows run 1.7 to 2.7 degF below PRISM, and MADIS flags its temperature as reading cold. Its low site near the coast may collect cold air on calm nights (cold air pooling), a real local effect rather than a fault, but it makes the station unrepresentative of the wider area.
• G5544 (Freeport, 55 m). Temperature agrees with PRISM to about 0.5 degF and MADIS passes all its sensors, but its average wind speed over the last year is 0.04 mph: the anemometer is stuck or fully sheltered.

The traditional way to get NOAA model data is to download NOAA's files: one per model run per forecast hour, each covering the whole country with every variable. A year of hourly temperature at the house means thousands of files. The cloud-native form is arranged as time series, so the same year is a handful of small reads, with no NOAA server to queue behind, and a version history that makes results repeatable (Figure 25).

All five forecasts beat both simple guesses at short lead times, and each stops being useful at a different horizon. Temperature and sunshine forecasts are clearly useful for about 5 days (on average for about a week), and the cold (degree days) for about two weeks. For the gas bill and for household electricity, the weather forecast is not the main source of error: the usage model and household habits are. The subsections give the numbers, as of the 2026-10-27 page build.

Forecasts for the next few hours miss the hourly temperature at the house and the airport by about 2 degF (1.1 degC). Both models beat "same as yesterday" by a wide margin on day 2. GFS is clearly better than the normal (95% bootstrap interval of skill above zero, section 4.3.1) through day 5 for both highs and lows; on average it stays ahead to day 6 for highs and day 8 for lows (Table 16).

Table 16. Temperature forecast error, last 90 days (degF; 1 degF = 0.56 degC).

The array averaged 47 kWh a day over the scored period.

• Tomorrow: the GFS forecast missed by 7 kWh on average (15%). Guessing the normal missed by 17 kWh, and repeating the last day by 22 kWh.
• Lead time: the error grows steadily with lead time. GFS is clearly better than the normal through day 5, better on average through day 7, and worse from day 8 (Table 17).
• HRRR: NOAA's 3 km model is no better than GFS for daily solar totals on days 0 and 1.
• Floor: even with the actual sunlight known, the production model misses by 4.3 kWh (PRISM sunlight) or 5.7 kWh (HRRR analysis). So about 3 of tomorrow's 7 kWh of error come from forecasting the weather, and the rest is the usage-model error.

Over all 271 days since the array started, including the winter snow days, the floors are 4.5 kWh (PRISM) and 7.7 kWh (HRRR analysis). With smooth daily conversion factors, the known-weather model explains production with r = 0.970 and a typical daily error of 7.8% (excluding the 7 snow days).

Table 17. Solar production forecast error by lead day, 2026-07-29 to 2026-10-24 (kWh per day; mean production 47 kWh per day).

"Days scored" counts run-day pairs: four runs a day each forecast the same day.

Over six heating seasons, the GEFS forecast of next week's total degree days missed by 10 HDD on average, against 27 for the normal and 41 for persistence. At current prices 10 HDD is about $4 of heating.

• Daily forecasts: they are clearly better than the normal through day 13: there the lower end of the 95% bootstrap interval of their skill (section 4.3.1) is above zero. Their average stays slightly ahead to about day 26, but by too little (skill at most 0.05) to tell apart from the normal.
• Raw ranges: too narrow, holding the actual week only 55% of the time.
• Calibrated ranges: they held it 81% of the time (77% for the following week), close to the 80% target, while staying about a third as wide as the range of normal weather.

Forty-six bills, from October 2021 to August 2026, were scored (Table 18).

• All bills, weather known: the usage model misses by 22% per bill on average. Most of that comes from summer bills, which are small and in 2026 about double the model's base use.
• All bills, a month ahead: forecast 29 to 35 days before the meter read, when almost the whole bill is still in the future, the error rises only to 24%. Normal weather gives 29% and persistence 39%.
• Winter bills (starting November to February, 15 bills): the usage model alone misses by 6%, and a month-ahead forecast also by 6%, against 11% for normal weather and 21% for persistence.

In dollars, at each bill's own rate, a month-ahead forecast is off by about $28 per bill, against $37 for the normal. The GEFS forecast clearly beats both baselines beyond a week. The usage model, not the weather forecast, limits the bill forecast.

Table 18. Gas bill forecast error by days before the meter read (mean absolute error per bill, % of billed therms).

The house uses about 42 kWh a day on average. The current model, fitted on the past year, has three parts:

• Base: 39 kWh a day.
• Cooling: 1.5 kWh for each degree the daily mean rises above 60 degF (15.6 degC), the largest weather effect, from air conditioning.
• Cold: 0.8 kWh for each degree below 38 degF (3.3 degC), and 2.2 kWh more on weekends.

Temperature explains only part of the day-to-day swing (r = 0.61), and the typical scatter around the model is 10 kWh a day.

The forecast results, over every GEFS run since October 2020 (Table 19):

• Tomorrow: the forecast misses by 7.6 kWh, against 9.5 kWh for the normal and 9.1 kWh for repeating the last day.
• Weather versus habits: most of that gain comes from the recent level. The normal plus the recent level misses by 8.0 kWh, so the weather forecast adds about 0.4 kWh a day in the first week and nothing beyond two weeks.
• Even with the weather known: the model with the actual temperature still misses by 7.5 kWh (9.1 kWh without the recent level). For the current day, repeating yesterday (7.4 kWh) is as good as any model.
• Weekly totals: for a typical week of 293 kWh, the coming week's forecast misses by 37 kWh (12%), against 51 kWh for the normal and 52 kWh for persistence.
• Range: the 80% range held the actual day 83% of the time.

Net grid use, over the 88 days with solar forecasts (2026-07-29 to 2026-10-24), averaged a draw of 3.5 kWh a day (Table 20). Tomorrow's net forecast misses by 9.9 kWh, against 17.1 kWh for normal weather. It is clearly better than the normal through day 4, better on average through day 5, and worse from day 7. That is the horizon of the solar forecast: cloud cover, not household use, limits the net forecast.

Table 19. Household electricity forecast error by lead day, every GEFS run 2020-10-01 to 2026-10-27 (kWh per day; mean use 42 kWh per day).

The known-weather row uses the observed temperature; its MAE columns score the same days.

Table 20. Net grid use forecast error by lead day, 2026-07-29 to 2026-10-24 (kWh per day; GEFS use minus GFS solar).

Doing it ourselves means understanding every step, which is the learning goal of this project. It removes a middleman whose choices we do not control, reads only what we need, and makes the cloud-native pieces visible rather than hidden behind one function call (Figure 26).

We would own code that someone else currently maintains for us. When dynamical.org changes how their catalog or storage is described, their library is updated by the people making the change; ours would break until we noticed and fixed it (Figure 27).

Both read the same data at the same speed. The wrapper is less work and is kept current by the data's publisher; direct is more work and teaches more. Because the data is identical either way, the choice can be changed at any time with a single setting (Figure 28).

Switching is roughly two to three days of focused work, mostly testing and the side-by-side comparison, plus a little ongoing attention whenever dynamical.org changes their catalog. Running costs (time, data, money) do not change: the service is free and the amount downloaded is the same (Figure 29).

Figure 30 shows how the work could be scheduled if the decision is reopened.

Some caveats apply. The references used to check stations are not fully independent: NOAA's HRRR model and the PRISM maps both use the airport station, and probably some volunteer stations, as inputs. PRISM revises each day's map for six months, so recent comparisons can shift slightly. The house station's record is short (since 2024, with an eight-month gap). The access timings were measured once, on one day, from one server, and would vary with network conditions. The solar forecast checks cover only 90 days of late summer and autumn, with no snow, so winter scores may differ. The production model's share of the PVGIS model is fitted on the same days it is checked on, which flatters the known-weather floor slightly. The gas checks rest on 46 bills, only 15 of them in winter, so the winter percentages can move by a few points as bills are added. The electricity model uses the airport's temperature, not the house's, and cannot see appliances or visitors; the net grid scores cover the same 90 autumn days as the solar scores. None of these changes the conclusions, but they limit how precisely the numbers should be read.

Four conclusions follow from this report:

1. Cloud-native formats make this project practical: a year of hourly data at one place is a one-second read instead of a multi-gigabyte download (section 5.2).
2. Station data needs continuous checking. The house station has drifted about 2 degF colder since December 2025, and E4229 was removed from all analyses for recording missing readings as zeros (section 5.1).
3. Every forecast on the results page is shown with its own track record, which is what makes it usable for decisions such as the heating outlook. Temperature and sunshine forecasts are clearly better than the normal for about 5 days and degree days for about two weeks. For solar production about half of tomorrow's error is the weather forecast and half the production model. For gas bills the usage model, not the weather forecast, is the limit. Household electricity follows habits more than weather: tracking the recent level of use matters more than the temperature forecast, and net grid use is predictable only as far ahead as the sunshine (section 5.3).
4. For the open design decision, the helper library is the right choice for now (below).

Stay on the wrapper, as decided. It works, it is maintained by the publisher, and switching would not change a single number. Revisit when there is a concrete reason: a problem the wrapper causes, a feature it lacks, or time set aside for the learning exercise (Figure 31).

Model data: NOAA, republished by dynamical.org under the Creative Commons Attribution 4.0 (CC BY 4.0) licence. Daily maps and normals: PRISM Group, Oregon State University. Station data: the National Weather Service (KPWM), volunteers of the Citizen Weather Observer Program via the Gladstone Weather Network and NOAA MADIS, and the Ambient Weather Network (house station). Solar production model: PVGIS, European Commission Joint Research Centre.

The first table spells out every acronym on this page. The second explains the other terms, in alphabetical order.