Skip to content

Conversation

rouault
Copy link
Member

@rouault rouault commented Oct 14, 2025

... following directions of a discussion happening at the Zarr Developer Summit 2025.

It transposes https://github.com/EOPF-Explorer/data-model/tree/main/attributes/geo/proj to that attribute framework.

Example:

{
  "attributes":{
    "zarr_conventions_version": "0.1.0",
    "zarr_conventions":
    {
        "f17cb550-5864-4468-aeb7-f3180cfb622f": {
            "version": "0.1",
            "name": "geo/proj",
            "description": "",
            "schema": "http://example.com/geo.proj.schema.json",
            "configuration": {
                "code": "EPSG:26711",
                "spatial_dimensions": ["Y", "X"],
                "transform": [60, 0, 440720, 0, 60, 3750120]
            }
        }
    }
  }
}

…ute conventions... [ci skip]

... following directions of a discussion happening at the Zarr Developer Summit 2025.

It transposes https://github.com/EOPF-Explorer/data-model/tree/main/attributes/geo/proj to
that attribute framework.
}
}
}
},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be at the group level?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

from https://github.com/EOPF-Explorer/data-model/tree/main/attributes/geo/proj#description

Recommended usage: Store the CRS-encoding JSON object defined in this specification under the proj key in the attributes of a group that contains arrays to declare CRS metadata for those arrays. This supports the common geospatial practice of storing multiple arrays with the same coordinates in a single group. Array-level definitions are supported for override cases but are less common.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This supports the common geospatial practice of storing multiple arrays with the same coordinates in a single group

That's something we need to discuss. My initial feeling is that I'm no a huge fan of having stuff defined only at an upper level when potentially users can point GDAL to open a inner group directly or an array. So that means either such use case will be invalid, or GDAL would need to walk up the hieararchy (but where to stop?) which involves extra I/O

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants