zarr-cm
Python types and utilities for Zarr Conventions Metadata.
Overview
zarr-cm provides typed Python support for the published Zarr conventions:
| Convention | Module | Description |
|---|---|---|
| proj | zarr_cm.proj (also zarr_cm.geo_proj) |
Coordinate reference system information |
| spatial | zarr_cm.spatial |
Spatial coordinate metadata |
| multiscales | zarr_cm.multiscales |
Multiscale pyramid layout |
| license | zarr_cm.license |
License specifiers |
| uom | zarr_cm.uom |
Units of measurement |
| stac | zarr_cm.stac |
STAC metadata for a Zarr group |
Each module provides:
- TypedDict types for convention-specific metadata
create— create convention metadata: the convention's own keys, nothing elsecreate_convention_attrs— create a complete stand-alone attributes dict: that data plus thezarr_conventionsentry declaring itinsert— compose: add convention metadata to attributes that already existextract— remove and return convention metadata from an attributes dictvalidate— check runtime invariants the type system cannot expressvalidate_group_metadata/validate_array_metadata/validate_node_metadata— validate a wholezarr.jsondocument, including the rules that depend on itsnode_type
See the docs for more information.
Installation
pip install zarr-cm
Usage
from zarr_cm import proj
# Create convention metadata
data = proj.create(code="EPSG:4326")
print(data)
#> {'proj:code': 'EPSG:4326'}
# Validate
print(proj.validate({"proj:code": "EPSG:4326"}))
#> {'proj:code': 'EPSG:4326'}
# Insert into an attributes dict
attrs = {"foo": "bar"}
result = proj.insert(attrs, data)
print(result)
"""
{
'foo': 'bar',
'proj:code': 'EPSG:4326',
'zarr_conventions': [
{
'uuid': 'f17cb550-5864-4468-aeb7-f3180cfb622f',
'schema_url': 'https://raw.githubusercontent.com/zarr-conventions/proj/refs/tags/v0.1/schema.json',
'spec_url': 'https://github.com/zarr-conventions/proj/blob/v0.1/README.md',
'name': 'proj',
'description': 'Coordinate reference system information for geospatial data',
}
],
}
"""
# Extract it back out
remaining, extracted = proj.extract(result)
print(remaining)
#> {'foo': 'bar'}
print(extracted)
#> {'proj:code': 'EPSG:4326'}
Convention revisions
Upstream Zarr conventions sometimes change their field shapes in place —
keeping the same uuid but altering required keys and cardinalities. To let you
both author data at the current spec and still read data written against an
earlier draft, the revisioned conventions (spatial, proj, multiscales)
expose package-local revision labels ordered oldest → newest. Today spatial
and proj ship r2 and r3, while multiscales ships only r2; more are
added as upstream conventions evolve.
Each revision pins its emitted schema_url/spec_url to an immutable upstream
reference — the release tag where one exists (v0.1 for the latest revisions),
otherwise the commit SHA it was snapshotted from — so a written document is
self-describing: the uuid says which convention, and the pinned schema_url
says which revision. Writes default to the latest revision; reads auto-detect
the revision from the document's schema_url (overridable with a revision=
argument).
Why there is no r1
The revision labels start at r2, not r1. Earlier drafts of spatial,
proj, and multiscales did exist, but the only schema_url they could carry
was upstream's refs/tags/v1/schema.json — and that tag was never published
on any of these repositories (their first and only release tag is v0.1). That
URL has therefore always returned 404, which is non-conformant with the Zarr
Conventions spec's requirement that schema_url resolve to the convention's
schema. For multiscales the draft was worse than dangling: its schema
const-requires the refs/tags/v1 URL, so no schema_url value could both
resolve and validate.
Rather than ship a revision whose self-describing URL is permanently broken,
r1 was dropped from all three conventions. The surviving revisions keep their
r2/r3 labels (labels are package-local and never appear in emitted
documents, so renumbering would only churn the public type names without
changing behavior).
Development
Common development tasks are defined in the justfile and run with
just (they only need
uv on top of that):
just # list all the available recipes
just test # run the test suite
just lint # run the pre-commit hooks over all files
just typecheck # run mypy
just docs # serve the docs locally with live reload
just check # everything CI runs: lint, pylint, typecheck, tests
Release files for zarr-cm 0.5.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| zarr_cm-0.5.0.tar.gz | 202.2 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| zarr_cm-0.5.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 257.7 kB
Release files / zarr_cm-0.5.0.tar.gz
| Download URL | zarr_cm-0.5.0.tar.gz |
|---|---|
| Size | 202.2 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
f39234ef5abc9acab2a4fadcde9132f8695fa47692a1f4e000d2d7b6fac039bd
|
|
BLAKE2b-256 checksum How to use checksums |
458129d60d04fad69ae1d7ee2675990a4c7421ded4d9a15280ead2d4c5f470c6
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 26, 2026.
Transparency logRelease files / zarr_cm-0.5.0-py3-none-any.whl
| Download URL | zarr_cm-0.5.0-py3-none-any.whl |
|---|---|
| Size | 55.6 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
99fef56dae5eb5ee2a7126d8a18e669944494e0778832577ae8ae922b0207b12
|
|
BLAKE2b-256 checksum How to use checksums |
85fb8c17b2956a248be9398f6727490976ab3e69cd419af9d983164a46d830da
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 26, 2026.
Transparency log