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

xcube server STAC implementation, further information needed to access data #1020

Closed
konstntokas opened this issue Jun 20, 2024 · 4 comments · Fixed by #1029
Closed

xcube server STAC implementation, further information needed to access data #1020

konstntokas opened this issue Jun 20, 2024 · 4 comments · Fixed by #1029
Assignees

Comments

@konstntokas
Copy link
Contributor

Is your feature request related to a problem? Please describe.
So far, the xcube server STAC implementation does not give further information regarding the store parameters to access the data. This will be needed if a client wants to access the data linked by an item's asset in the STAC catalog. See xcube viewer's data access snippet below:

from xcube.core.store import new_data_store

store = new_data_store(
    "s3",
    root="datasets",  # can also use "pyramids" here
    storage_options={
        "anon": True,
        "client_kwargs": {
            "endpoint_url": "http://localhost:8080/s3"
        }
    }
)
# store.list_data_ids()
dataset = store.open_data(data_id="zarr_file.zarr")

Describe the solution you'd like
Add a new field to the asset called something like "xcube:open_kwargs". We can get inspiration from the item https://planetarycomputer.microsoft.com/api/stac/v1/collections/era5-pds/items/era5-pds-1980-01-fc, which stores extra information in "xarray:open_kwargs" for opening the data. Similarly, we could add

xcube:open_kwargs =  dict(
    root="datasets",
    endpoint_url="http://localhost:8080/s3"
)
@forman
Copy link
Member

forman commented Jun 25, 2024

Similarly, we could add

We should provide the parameters that would allow users using the xcube data store framework. Therefore we need the following information:

  • data_store_id
  • data_store_params
  • data_id
  • open_data_params

If we stick to the datasets published by the same xcube Server instance that also provides the STAC API we may boil it down to just the S3 API parameters.

@konstntokas
Copy link
Contributor Author

konstntokas commented Jun 28, 2024

With the PR #1029 I can now read zarr, levels, geotiffs and cog-geotiffs from the STAC published by xcube server. Two questions remain:

  1. When starting the server, all files are published as zarrs. See xcube/webapi/ows/stac/controllers.py#L800 Why is that? This also means that the levels file is presented as a dataset instead of a mldataset.
  2. When adding a netcdf file to the server configuration, something goes wrong. Also the viewer does not show the datasets. I see in the examples/serve/demo/config.yml that the cube.nc is not assigned. Does this mean that the server cannot publish netcdf files?

@konstntokas
Copy link
Contributor Author

The PR #1029 is converted to a draft. First the MIME-type and format extension of the dataset will be added to the asset. So far all files will be published as zarrs.

@konstntokas
Copy link
Contributor Author

The xcube server publishes each dataset as .zarr and .levels on the s3/datasets and s3/pyramidsendpoint, respectively. Two assets will be published, namely analytic (asset as before) and analytic_multires, linking to the dataset and the multi-level dataset, respectively.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants