Datasetpublic

asterisk-labs/taco-api-fixtures

TACO API Fixtures 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. Matrix The repository combines ten… See the full description on the dataset page: https://huggingface.co/datasets/asterisk-labs/taco-api-fixtures.

sourceHugging Faceotherupdated 14d agoView on Hugging Face

1likes512downloads

Dataset Card

TACO API Fixtures

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.

Matrix

The repository combines ten logical contracts with five physical topologies:

Topology	Purpose
`folder`	One mutable-directory representation
`single-zip`	One immutable cloud-optimized ZIP
`by-size`	Six one-sample ZIP partitions plus TACOCAT
`by-split`	Train, validation, and test ZIP partitions plus TACOCAT
`manual-catalog`	Three independently written ZIP partitions consolidated into TACOCAT

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.

Repository structure

text

data/<case>/<topology>/     generated TACO datasets
generate/generate.py        deterministic matrix generator
verify/verify_local.py      structural and Rumi decode checks
verify/verify_http.py       loopback HTTP Range checks
verify/verify_huggingface.py remote HTTP Range checks
manifest.json               expected cases, entrypoints, assets, and metadata
checksums.sha256            generated-file checksums
source-lock.json            pinned Rumi fixture source
SOURCE_DATA.md              provenance and synthetic-metadata notice

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.

Reproduce and verify

From a checkout next to rumi-api-fixtures:

bash

uv sync
uv run python generate/generate.py --clean
uv run python verify/verify_local.py
uv run python verify/verify_http.py

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:

bash

python generate/generate.py --clean
python verify/verify_local.py
python verify/verify_http.py

After publication:

bash

python verify/verify_huggingface.py --revision main

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.