You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Should we allow the daops interface to include the selection of variables?
Philosophically, we created daops and rook to deal with dataset identifiers, which tend to include only a single data variable (along with its metadata and coordinate variables). As we consider the wider use of roocs we find, as with the ESA CCI datasets at CEDA, that some datasets have many variables. For example, this kerchunk file links to NetCDF files that contain 204 variables!
Should we allow the daops interface to include the selection of variables?
Philosophically, we created
daops
androok
to deal with dataset identifiers, which tend to include only a single data variable (along with its metadata and coordinate variables). As we consider the wider use ofroocs
we find, as with the ESA CCI datasets at CEDA, that some datasets have many variables. For example, thiskerchunk
file links toNetCDF
files that contain 204 variables!https://data.ceda.ac.uk/neodc/esacci/cloud/metadata/kerchunk/version3/L3C/ATSR2-AATSR/v3.0/ESACCI-L3C_CLOUD-CLD_PRODUCTS-ATSR2_AATSR-199506-201204-fv3.0-kr1.1.json
Here is an example request to remind us of the existing interface (using the command-line
daops subset
approach):So, should we extend the daops interface to allow specific selection of variables?
If yes, what are the options?
If we decide to support this extension, then maybe we have two options:
So a full command might be:
variables
:variables
: list of strings (or variable IDs) - DEFAULT =None
(i.e. include all variables)time
area
level
collection
@cehbrecht: what are your thoughts on this proposal?
The text was updated successfully, but these errors were encountered: