pretty_name: TACO API Fixtures license: other tags:
A deterministic collection of 50 small TACO datasets whose payloads are all Rumi files. The fixtures exercise TACO contracts, metadata hierarchies, FOLDER and ZIP containers, ZIP partitioning, TACOCAT consolidation, generated locations, and local or remote range reads.
They are API fixtures, not training data or a scientific benchmark. Spatial and temporal metadata generated here is intentionally synthetic.
The repository combines ten logical contracts with five physical topologies:
The ten contracts cover single and paired assets, fixed and variable
sequences, nested folders, point metadata, STAC grids, STAC footprints without
a grid, nullable coordinates, folder-level STAC, temporal-only metadata,
high-dimensional Rumi arrays, and equivalent Rumi frame layouts. A STAC grid is
stored as a grid: its geometry and bbox stay null and the writer derives
only the float32 {lon, lat} centroid.
Every topology is an independently openable dataset entrypoint. ZIP files referenced by a TACOCAT are partitions of that dataset and are not counted as additional matrix entries.
Every object below a dataset's DATA/ tree is a Rumi container with a
.rumi name. External Rumi headers are stored in Parquet as rumi:header, and
a wide read returns each one as {file}::header beside {file}::location. TACO's own COLLECTION.json and
METADATA/*.parquet control files are present as required by the format.
Neither taco:location nor cozip:location is stored in Parquet. Readers
construct locations from the physical payload and its container.
From a checkout next to rumi-api-fixtures:
The workspace development configuration also expects the current TACO and
Rumi checkouts at ../taco/python and ../rumi/bindings/python. Those local
sources let the fixtures exercise unreleased writer and reader changes. Once
matching releases are available, consumers can resolve the declared package
ranges without the workspace source overrides.
The same commands without uv work in an already configured development
environment:
After publication:
The default remote verifier opens all 40 ZIP-backed entrypoints and decodes
every Rumi through an HTTP subfile location. Pass --full-api to additionally
repeat the raw-level and coordinate-profile checks that the local verifier
already performs.
The generator seed, source revision, and source manifest checksum are pinned. Regeneration preserves the logical datasets and synthetic metadata. ZIP byte checksums may change when ZIP timestamps change, so published revisions should be treated as immutable fixture targets.