4.1.  Terms and definitions

A multidimensional, regularly spaced collection of values (e.g., raster data or gridded measurements), typically indexed by dimensions such as time, latitude, longitude, or spectral band.

A sub-array representing a partition of a larger array, used to optimise data access and storage. In Zarr, data is stored and accessed as a collection of independently compressed chunks.

A one-dimensional array whose values define the coordinate system for a dimension of one or more data variables. Typical examples include latitude, longitude, time, or vertical levels.

An array containing the primary geospatial or scientific measurements of interest (e.g., temperature, reflectance). Data variables are defined over one or more dimensions and associated with metadata.

An index axis along which arrays are organised. Dimensions provide a naming and ordering scheme for accessing data in multidimensional arrays (e.g., time, x, y, band).

A container for datasets, variables, dimensions, and metadata in Zarr. Groups may be nested to represent a logical hierarchy (e.g., for resolutions or collections).

Structured information describing the content, context, and semantics of datasets, variables, and attributes. GeoZarr metadata includes CF attributes, geotransform definitions, and links to STAC metadata where applicable.

A dataset that includes multiple representations of the same data variable at varying spatial resolutions. Each resolution level is associated with a tile matrix from an OGC Tile Matrix Set.

A spatial tiling scheme defined by a hierarchy of zoom levels and consistent grid parameters (e.g., scale, CRS). Tile Matrix Sets enable spatial indexing and tiling of gridded data.

An affine transformation used to convert between grid coordinates and geospatial coordinates, typically defined using the GDAL GeoTransform convention.

A conceptual model that defines how to structure geospatial data in Zarr using CDM-based constructs, including support for coordinate referencing, metadata integration, and multiscale representations.

4.2.  Abbreviated terms

5.1.  Identifiers

The normative provisions in this Standard are denoted by the base URI:

http://www.opengis.net/spec/geozarr/1.0

All requirements, recommendations, permissions, and conformance tests that appear in this document are assigned relative URIs anchored to this base.

For example:

http://www.opengis.net/spec/geozarr/1.0/conf/core — refers to the Core Requirements Class of the GeoZarr Unified Data Model.

5.2.  Data Encoding

This Standard specifies the encoding of geospatial data in the Zarr format. Zarr is a chunked, compressed, binary format for n-dimensional arrays, with support for both Version 2 and Version 3 encodings.

The specification makes extensive use of:

5.3.  Schemas

Metadata schemas referenced in this Standard are represented using JSON-compatible objects and may be defined formally using JSON Schema. Metadata structures for tile matrix sets, STAC properties, or CF metadata may be embedded inline or referenced externally via URI.

5.4.  URI Usage

URIs used in this Standard must comply with [RFC3986] (URI Syntax). When including reserved characters in a URI, they must be percent-encoded. Dataset identifiers, metadata links, and STAC references should use persistent and canonical forms to support reproducibility and catalogue integration.

6.1.  Encodings

GeoZarr supports encoding in both Zarr Version 2 and Zarr Version 3. Each version defines how arrays, groups, and metadata are stored within a directory-based structure. All metadata is encoded in JSON-compatible formats, ensuring both human readability and machine interoperability.

Encoding guidelines include:

JSON is the primary format for metadata, attributes, and structural declarations. Implementations are encouraged to support standardised naming conventions, EPSG code references, and structured metadata to facilitate search, validation, and transformation across platforms.

GeoZarr does not prescribe a single interface for data access. Instead, it enables serverless and cloud-native data access strategies by aligning its model with chunked, parallelisable storage patterns that are optimised for use in object stores and analytical environments.

7.1.  Scope and Purpose

This Standard defines a unified data model (UDM) that provides a conceptual framework for representing geospatial and scientific data in Zarr. The purpose of this model is to support standards-based interoperability across Earth observation systems and analytical environments, while preserving compatibility with existing data models and software ecosystems..

The unified data model incorporates and extends the following established specifications and community standards:

The unified model is format-agnostic and describes the abstract structure of resources independently of the physical encoding. It does not redefine the semantics of the CDM or CF conventions, but introduces integration and extension points required to support tiled multiscale data, geospatial referencing, and metadata for discovery.

This clause specifies the logical composition of the unified model, the external standards it leverages, and the conformance points that facilitate harmonised implementation within the GeoZarr framework.

7.2.  Foundational Model and Standards Reuse

The unified data model described in this Standard is derived from established community specifications to maximise interoperability and to enable the reuse of mature tools and practices. The model is grounded in the Unidata Common Data Model (CDM) and the Climate and Forecast (CF) Conventions, which together provide a robust framework for representing scientific and geospatial datasets.

7.3.  Model Extension Points

The unified data model specifies a series of optional, standards-aligned extension points to support functionality beyond the base CDM and CF constructs. These extensions enhance applicability to Earth observation and spatial analysis use cases without imposing additional mandatory requirements.

Each extension is defined as an independent module. Implementation of any given extension does not necessitate support for others.

7.4.  Unified Model Structure

This clause defines the structural organisation of datasets conforming to the unified data model (UDM). It consolidates the foundational elements and optional extensions into a coherent architecture suitable for Zarr encoding, while remaining format-agnostic. The model establishes a modular and extensible framework that supports structured representation of multidimensional, geospatially-referenced resources.

The model represents datasets as abstract compositions of dimensions, coordinate variables, data variables, and associated metadata. This abstraction ensures that applications and services can reason about the content and semantics of a dataset without reliance on storage layout or specific serialisation.

7.4.1.  Dataset Structure

A dataset conforming to the Unified Data Model (UDM) is structured as a hierarchy rooted at a top-level dataset entity. This design enables modularity and facilitates the representation of complex, multi-resolution, or thematically partitioned data collections.

Each dataset node comprises the following core components, aligned with the Unidata Common Data Model (CDM) and Climate and Forecast (CF) Conventions:

• Dimensions – Named, integer-valued axes defining the extent of data variables. Examples include time, x, y, and band.

• Coordinate Variables – Arrays that supply coordinate values along dimensions, providing spatial, temporal, or contextual referencing. These may be scalar or higher-dimensional, depending on the referencing scheme.

• Data Variables – Multidimensional arrays representing physical measurements or derived products. Defined over one or more dimensions, these variables are associated with coordinate variables and annotated with metadata.

• Attributes – Key-value pairs attached to variables or dataset components. Attributes convey semantic information such as units, standard names, and geospatial metadata.

The hierarchy is implemented through groups, which function as containers for variables, dimensions, and metadata. Groups may define local context while inheriting attributes from parent nodes. This supports the logical subdivision of datasets by theme, resolution, or processing stage, and enhances the clarity and reusability of complex geospatial structures.

The diagram below represents the structural layer of the unified data model, derived from the Unidata Common Data Model, which serves as the foundational framework for supporting all overlaying model layer.

 

Figure 1 — Conformance-class model

Note that, conceptually, node within this hierarchy might be treated as a self-contained dataset.

7.5.  Conformance and Extensibility

The GeoZarr data model is designed with an open conformance approach to support a wide range of use cases and implementation contexts. Its core model is permissive, allowing partial implementations, while optional extensions and compliance profiles can define stricter requirements for interoperability.

7.6.  Interoperability Considerations

Interoperability is a core objective of the GeoZarr unified data model. The model is designed to bridge diverse Earth observation and scientific data ecosystems by enabling structural and semantic compatibility with established formats and standards, while providing a forward-looking foundation for scalable, cloud-native workflows.

This section outlines the principles and mechanisms supporting interoperability across formats, tools, and communities.

9.1.  Hierarchical Structure

A dataset conforming to the unified data model is represented as a hierarchical structure of groups, variables (arrays), dimensions, and metadata. The dataset is rooted in a top-level group, which may contain:

Each group adheres to a consistent structure, allowing recursive composition. This reflects the CDM’s use of groups and is supported by both Zarr v2 and v3 with differing implementations.

Table 3

Zarr v3 requires zarr_format: 3 and stores all metadata (including user-defined attributes) in the zarr.json document. Each node includes a node_type field: either "group" or "array".

9.2.  Dimensions

Dimensions define the axes along which variables are indexed.

Example for a 2D array with dimension names ["lat", "lon"]:

{
  "zarr_format": 3,
  "node_type": "array",
  "shape": [180, 360],
  "dimension_names": ["lat", "lon"],
  ...
}

Listing 1

9.3.  Coordinate Variables

Coordinate variables (excluding GeoTransform Coordinates) define the geospatial or temporal context of data. They are represented as named arrays with metadata attributes.

Coordinate variables are represented as named 1D arrays aligned with corresponding dimensions.

Table 4

Example zarr.json for a coordinate array:

{
  "zarr_format": 3,
  "node_type": "array",
  "shape": [180],
  "dimension_names": ["lat"],
  "data_type": "float32",
  "chunk_grid": {
    "name": "regular",
    "configuration": {
      "chunk_shape": [180]
    }
  },
  "attributes": {
    "standard_name": "latitude",
    "units": "degrees_north",
    "axis": "Y"
  }
}

Listing 2

9.4.  Data Variables

Data variables represent measured or derived quantities. They are stored as multidimensional arrays with metadata attributes.

Table 5

Example:

{
  "_ARRAY_DIMENSIONS": ["time", "lat", "lon"],
  "standard_name": "air_temperature",
  "units": "K",
  "long_name": "Surface air temperature",
  "_FillValue": -9999.0
}

Listing 3

9.5.  Global Metadata

Metadata associated with the dataset as a whole is stored at the root group level.

Table 6

Example Zarr v3 root zarr.json:

{
  "zarr_format": 3,
  "node_type": "group",
  "attributes": {
    "title": "Example Dataset",
    "summary": "Multidimensional Earth Observation data",
    "institution": "Example Space Agency",
    "Conventions": "CF-1.10"
  }
}

Listing 4

9.6.  Variables Metadata

All metadata attributes (for groups, coordinates variables and data variables) are recommended to conform to CF naming and typing conventions. Supported attributes include:

In all cases:

9.7.  Encoding of Multiscale Overviews in Zarr

This clause specifies how multiscale tiling (also known as overviews or pyramids) is encoded in Zarr-based datasets conforming to the unified data model. The encoding supports both Zarr Version 2 and Version 3 and is aligned with the OGC Two Dimensional Tile Matrix Set Standard.

Multiscale datasets are composed of a set of Zarr groups representing multiple zoom levels. Each level stores coarser-resolution resampled versions of the original data variables.

{
  "multiscales": {
    "tile_matrix_set": "WebMercatorQuad",
    "resampling_method": "nearest"
  }
}

{
  "zarr_format": 3,
  "node_type": "group",
  "attributes": {
    "multiscales": {
      "tile_matrix_set": "WebMercatorQuad",
      "resampling_method": "nearest"
    }
  }
}

"tile_matrix_set_limits": {
  "1": {
    "min_tile_col": 0,
    "max_tile_col": 1,
    "min_tile_row": 0,
    "max_tile_row": 1
  }
}