Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for internal tiles #43

Open
thomas-maschler opened this issue Dec 8, 2023 · 1 comment
Open

Add support for internal tiles #43

thomas-maschler opened this issue Dec 8, 2023 · 1 comment

Comments

@thomas-maschler
Copy link

thomas-maschler commented Dec 8, 2023

We are working on an update of the GDAL STACTA (tiled-assets) driver. Currently, the driver has to fetch metadata of at least one tiled asset to construct full metadata for the gridded dataset. This becomes an issue when working with sparse grids and the 0/0 tile is not present. The driver wouldn't know which other file to choose. The PR addresses this and makes use of raster:band and eo:band metadata to avoid this call in first place. However, there is some information needed that is currently not covered by any of the extensions. In particular information on the internal tile size (or block size in GDAL slang) is missing.

I'd like to propose a new field in the raster band object to support this use case.

There are various possible flavors and would like to seek some feedback prior to submitting a PR.

I could imagine the following:

A tuple describing the shape of the internal tiles

{
    ...,
    "internal_tile": {
        "type": "array",
        "title": "Internal tile shape",
        "description": "A tuple (width/height), specifying the internal block/ strip/ chunk shape of the raster band.",
        "prefixItems": [
            {
                "type": "integer"
            },
            {
                "type": "integer"
            }
        ]
    }
}

Or, to be more explicit, an object. This option would allow to add additional properties, suchs as whether or not the blocks are stored sparse.

{
   ...,
   "internal_tile": {
        "type": "object",
        "description": "This object allows to specify the internal tiling of a raster band, describing the block/ strip/ chunk shape and other storage information.",
        "required": [
            "width",
            "height"
        ],
        "properties": {
            "width": {
                "type": "integer",
                "description": "The width in pixels of the internal block/ strip/ chunk."
            },
            "height": {
                "type": "integer",
                "description": "The height in pixels of the internal block/ strip/ chunk."
            },
            "sparse": {
                "type": "boolean",
                "description": "Indicate whether or not bands are stored as sparse files. Sparse files are only compatible with GDAL driver."
            }
        }
    }
}
@thomas-maschler
Copy link
Author

thomas-maschler commented Jul 1, 2024

Discussed during STAC community meeting on Jul 1st 2024:

The preferred option is option 1, which describes everything at the extension's top level. ie two separate attributes one for block size, and the other for sparse.
Instead of the name internal_tiles, using block_size is better to align with GDAL jargon.

block_size should only describe 2D chunk. The raster extension is meant for Rasters only. If there is a need to describe multi-dimensional arrays with nd-chunks the nd-array extension will be better suited.

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

No branches or pull requests

1 participant