Conversation
…ent version to 0.8.0
…Array definitions and removing Zarr V2 references.
emmanuelmathot
changed the title
| "storage_transformers": [], | ||
| "storage_transformers": [] | ||
| } | ||
| } |
There was a problem hiding this comment.
I'm not sure to understand why we don't have shape in the example
There was a problem hiding this comment.
good catch, either this should be clearly indicated as a partial array metadata document, with some fields omitted, or the full array metadata should be there
|
|
||
| There are no required attributes for Datasets but to qualify as a GeoZarr Dataset, the group must contain at least one DataArray with spatial reference information. | ||
| This DataArray is referenced in the `grid_mapping` attribute of the dataset and is usually named `spatial_ref`. | ||
| There are no required attributes for Datasets. To qualify as a GeoZarr Dataset, the group must carry geospatial metadata via the `proj:` and `spatial:` conventions declared in its `zarr_conventions` attribute. |
There was a problem hiding this comment.
| There are no required attributes for Datasets. To qualify as a GeoZarr Dataset, the group must carry geospatial metadata via the `proj:` and `spatial:` conventions declared in its `zarr_conventions` attribute. | |
| There are no required attributes for Datasets. To qualify as a GeoZarr Dataset, the group must carry geospatial metadata via the `proj:` and `spatial:` conventions declared in its `zarr_conventions` key. |
It feels weird to say no attribute but then say that we need to declare things in zarr_convention attribute
| > The `spatial:transform` uses **Rasterio/Affine coefficient ordering** `[a, b, c, d, e, f]`, which differs from GDAL's `GetGeoTransform` ordering `[c, a, b, f, d, e]`. Converting from GDAL: `spatial_transform = [GT(1), GT(2), GT(0), GT(4), GT(5), GT(3)]`. | ||
|
|
||
| > [!Note] | ||
| > CF metadata (`standard_name`, `grid_mapping` variables, coordinate variable attributes) is no longer required by this specification but remains compatible and may be included alongside the Zarr conventions. See [CF conventions](https://cfconventions.org) for reference. |
There was a problem hiding this comment.
CF metadata is no longer required by this specification but remains compatible
remain compatible with what? if not in the spec, we shouldn't imply compatibility with tools that will read/write GeoZarr
| of `D` along the axis named by `N`. In this case, `D` is called a "data variable", and the each | ||
| DataArrays matching a dimension names of `D` is called a "coordinate variable". | ||
| of `D` along the axis named by `N`. In this case, `D` is called a "data variable", and each | ||
| DataArray matching a dimension names of `D` is called a "coordinate variable". |
There was a problem hiding this comment.
This should be a schema. I got lost at the end of the first sentence!
There was a problem hiding this comment.
totally agree but I'm not sure how we could put it in a schema. I wrote this for myself to make sense of how xarray distinguishes coordinate variables from data variables (and geozarr inherits this)
|
follow-up in #133 |
3 participants
Revise the GeoZarr mini-spec to align with Zarr V1 conventions and exclusively target Zarr V3, removing references to Zarr V2.