Note 03August 20265 min read

Two sources feed the RRFS and HRRR pages, chosen per field. The first is weatherzarr.com, WeatherMapMaker's rolling Zarr archive, proxied publicly over HTTPS so no credentials are needed. Where it carries a field this is strictly better than the GRIB: the publisher has already paid the download-and-decode cost, and this site reads only the chunks it touches. The output was verified pixel-for-pixel identical to the GRIB path for the same cycle. The second is the NOMADS GRIB2 itself, the fallback for fields the archive does not publish — at the time of writing the archive carries three of the ten fields the site renders from it (2-metre temperature, dewpoint and precipitable water), so radar, gusts, wind, precipitation, CAPE and ceiling still come from GRIB.

There is one thing about those stores worth writing down for anyone else who reads them.

The axes are slices, not coordinates

The stores' latitude and longitude arrays are wrong for Lambert models, and this project deliberately ignores them.

The RRFS and HRRR sit on a 1799 by 1059 Lambert Conformal grid. On a Lambert grid, rows are not parallels and columns are not meridians: true latitude and longitude both vary in two dimensions, so the coordinate of a cell is a 2-D field, one latitude and one longitude per point. The publisher writes 1-D latitude and longitude axes instead, and they are exact slices of that 2-D field — the latitude axis is the grid's west-edge column, the longitude axis is its south-edge row.

Read a store as a rectilinear lat/lon grid, as any generic Zarr or xarray tool will, and every feature is misplaced. Measured against the true coordinates, the error is about 413 km on average and up to about 848 km at the corners. It also clips the domain's northern reach: the grid truly extends to 52.6 °N, and the latitude axis stops at 47.8 °N, because the west edge of a Lambert grid curves well south of its middle.

The values are fine. They are the correct native Lambert array, in south-row-first order, exactly as the GRIB decodes. So this project reads the data and applies its own Lambert transform — the same one the GRIB path uses — and never touches the stores' coordinates. Which is also why the two paths come out pixel-identical: the same array through the same projection.

Not every store has the problem

The NDFD stores from the same archive are different, and the difference shows what "correct" looks like. They carry real 2-D latitude and longitude arrays and the full Lambert parameters in their GRIB attributes, so the projection is read from the data rather than assumed. The sphere radius was pinned by reprojecting the grid and matching those stored coordinates: 6,371,200 m reproduces them to 0.0000 km, 6,371,229 m is off by 26 m, and WGS84 by 6.3 km. That last one is the trap — a Lambert grid on an ellipsoid looks like a Lambert grid on a sphere until you check.

Near enough to look right

The general lesson is that a grid must be read off its own file and then checked, because the errors that matter are the ones that still draw a plausible map. Every grid on this site is validated the same way: reproject every point and compare against wgrib2's own per-point coordinates. Lambert CONUS comes out exact; the polar stereographic and Mercator grids within 70 to 90 metres, which is the precision of wgrib2's three-decimal printout rather than projection error.

Three cases from doing that:

• RRFS Alaska and Hawaii are 1649 by 1105 and 321 by 225, exactly the shapes of their NDFD namesakes, and it is tempting to reuse those entries. But the RRFS is on the 6,371,229 m sphere where the NDFD is on 6,371,200 m, and the spacings differ in the third decimal. Reusing the NDFD Alaska grid for the RRFS puts it 1.21 km out — 41% of a cell: far enough to be wrong, near enough to look right.
• NBM Alaska really is NDFD Alaska's grid — same sphere, same shape, parameters differing in the last digit — and reusing it would have cost 80 m rather than 69, inside the comparison's own resolution. It gets its own entry anyway, because reading each grid off its own GRIB is exactly the habit that catches the case above, which looks equally similar and is not.
• RRFS North America is on a rotated lat-lon grid, and a rotated grid states its corner in rotated degrees — already the projection's own coordinate system. Projecting that corner from WGS84 rotated it a second time and put the origin 169 degrees out, a 1,564-cell offset, and the result was still a plausible-looking map.

Why a reader should care

A map that is 413 km out is obviously wrong the moment you look at a coastline; a map that is 1.2 km out is not, and it is the one that would have shipped. Everything on this site that reads a number back to you depends on the georeferencing being exact. The city labels are sampled from the model grid at each city's position, and the pointer readout inverts the pixel under the cursor. They share one index function, so a city's number is read off the same index the pixel under it was drawn from — verified bit-identical across every grid family before anything else changed. If a grid were placed wrong, the label and the pixel would disagree with each other and with the town they sit on.

They do not, and the test is the terrain. Volcano at 69 °F and Waimea at 74 against 79 to 85 on the Hawaiian coasts, with Kona warmer than Hilo. Fairbanks at 73 and Eielson at 75 in the Alaskan interior against Kodiak, Unalaska and Seward at 54 or 55 on the water. Barranquitas at 73, Adjuntas at 75 and Cayey at 76 up in the Cordillera Central against 81 to 86 right round the Puerto Rican coast. Georeferencing that is wrong does not produce that.