A demo for the Palisades and Eaton fires near Los Angeles in January 2025: GOES-18 ABI Fire/Hot Spot Characterization from 2025-01-07 to 2025-01-20 (UTC), as a cloud-native mirror (virtual Zarr in Icechunk, organized with Portolan). The cube references NOAA’s public S3 files in place, so no pixels are copied and reads need no credentials. The time range may be extended.
Fire detections from the Advanced Baseline Imager (ABI) on NOAA's GOES
satellites, as virtual Zarr cubes. Each collection covers one satellite and one
scan sector. The first collection is GOES-18 CONUS. Every pixel of every scan is in the cube:
fire, clear land, cloud, water and the pixels the algorithm could not process.
The cube holds byte-range references and metadata. The pixel data stays in
NOAA's public noaa-goes18 bucket on AWS S3.
Demo. The cube covers only a short part of the GOES-18 record. The collection's description and
extentgive the dates. The time range may be extended.
NOAA and NESDIS produce the data and remain the authoritative source. This catalog is a mirror of it.
One collection so far, goes-18-fdcc: NOAA's Level 2 Fire/Hot Spot Characterization
product (FDC) for the GOES-18 CONUS sector.
The FDC algorithm uses the ABI 3.89 µm and 11.19 µm bands of each scan, with
other bands for its cloud tests. For each pixel it assigns a fire mask code, and for some fire pixels it estimates the fire's radiative power,
temperature and area. NOAA writes one netCDF file per scan. The cube stacks
those files along time and reads them in place.
The gsd of 2000 m in the collection is the pixel size at nadir. Pixels are
larger toward the edges of the sector.
The GOES-18 CONUS sector is sometimes called PACUS. The extent above is NOAA's
geospatial_lat_lon_extent for the sector.
Measured from the file headers. Each variable is a time × y × x array.
Temp and Area are stored as scaled integers. Most readers apply the scaling
and the fill value on read. The collection agent guide says how to get
the raw integers.
Each scan also has NOAA's own summary values, stored as variables along
time. They include the number of fire pixels and the outlier counts. They
also include the minimum, maximum, mean and standard deviation of fire
temperature, area and radiative power. The
collection has no statistics of its own, because they would change with every
scan the cube gains.
Mask assigns each pixel one code. The codes and names come from the
flag_values and flag_meanings attributes in the file.
The file lists one name for each of the 45 codes. A fire pixel is a code from 10 to 15 or from 30 to 35.
The time coordinate is the t value in each file. It falls in the middle of
the scan, between the start and end stamps in the file name. When a file's t
is missing or not usable, time is the midpoint of the file-name stamps.
NOAA's bucket can have gaps where no file exists for a scan. The cube has no
time step for a missing scan, so the spacing along time is not always 5
minutes.
CC0-1.0. NOAA releases the data that its Open Data Dissemination (NODD)
program distributes, including the noaa-goes18 bucket, under the
Creative Commons CC0 1.0 Universal Public Domain Dedication.
NODD states that this license applies to each NOAA dataset it makes available
(NODD license text). The GOES
registry page says the data "can be used as desired".
NOAA also makes these requests:
Every scan comes from the ABI-L2-FDCC prefix of the noaa-goes18 bucket,
listed in the
AWS Registry of Open Data. Nothing
is resampled, reprojected, filtered or reclassified. The cube keeps NOAA's grid,
chunks, compression, codes, scaling and fill values. The cube includes the pixel
variables and the per-scan summary values in the files.
The methods are in the repository design document. The update workflow has not run yet.
Open the Icechunk repository with icechunk, zarr and xarray, and authorize
NOAA's bucket as a virtual chunk container. The tested recipe is in the
collection README. For a worked example that
starts from this catalog, see examples/palisades-frp.ipynb in the
source repository.
The Zarr asset is outside the Portolan conformance surface. The Portolan specification defers Zarr support until real Zarr datasets have been tested in catalogs (portolan-spec#132). This catalog is one of those test cases.
Assets and structural links resolve relative to the object that carries them.
Catalogs here have no self link, so a client tracks its own location. The
data assets use absolute https hrefs built from the public base URL.