|
1 | | -## Changes in 1.0.0.dev3 |
| 1 | +## Changes in 1.0.0 |
2 | 2 |
|
3 | 3 | ### Enhancements |
4 | 4 |
|
| 5 | +* Added a catalog API compliant to [STAC](https://stacspec.org/en/) to |
| 6 | + xcube server. (#455) |
| 7 | + - It serves a single collection named "datacubes" whose items are the |
| 8 | + datasets published by the service. |
| 9 | + - The collection items make use the STAC |
| 10 | + [datacube](https://github.com/stac-extensions/datacube) extension. |
| 11 | + |
| 12 | +* Simplified the cloud deployment of xcube server/viewer applications (#815). |
| 13 | + This has been achieved by the following new xcube server features: |
| 14 | + - Configuration files can now also be URLs which allows |
| 15 | + provisioning from S3-compatible object storage. |
| 16 | + For example, it is now possible to invoke xcube server as follows: |
| 17 | + ```bash |
| 18 | + $ xcube serve --config s3://cyanoalert/xcube/demo.yaml ... |
| 19 | + ``` |
| 20 | + - A new endpoint `/viewer/config/{*path}` allows |
| 21 | + for configuring the viewer accessible via endpoint `/viewer`. |
| 22 | + The actual source for the configuration items is configured by xcube |
| 23 | + server configuration using the new entry `Viewer/Configuration/Path`, |
| 24 | + for example: |
| 25 | + ```yaml |
| 26 | + Viewer: |
| 27 | + Configuration: |
| 28 | + Path: s3://cyanoalert/xcube/viewer-config |
| 29 | + ``` |
| 30 | + - A typical xcube server configuration comprises many paths, and |
| 31 | + relative paths of known configuration parameters are resolved against |
| 32 | + the `base_dir` configuration parameter. However, for values of |
| 33 | + parameters passed to user functions that represent paths in user code, |
| 34 | + this cannot be done automatically. For such situations, expressions |
| 35 | + can be used. An expression is any string between `"${"` and `"}"` in a |
| 36 | + configuration value. An expression can contain the variables |
| 37 | + `base_dir` (a string), `ctx` the current server context |
| 38 | + (type `xcube.webapi.datasets.DatasetsContext`), as well as the function |
| 39 | + `resolve_config_path(path)` that is used to make a path absolut with |
| 40 | + respect to `base_dir` and to normalize it. For example |
| 41 | + ```yaml |
| 42 | + Augmentation: |
| 43 | + Path: augmentation/metadata.py |
| 44 | + Function: metadata:update_metadata |
| 45 | + InputParameters: |
| 46 | + bands_config: ${resolve_config_path("../common/bands.yaml")} |
| 47 | + ``` |
| 48 | + |
5 | 49 | * xcube's spatial resampling functions `resample_in_space()`, |
6 | 50 | `affine_transform_dataset()`, and `rectify_dataset()` exported |
7 | 51 | from module `xcube.core.resampling` now encode the target grid mapping |
|
77 | 121 | This notebook shows how a new data store instance can connect and list |
78 | 122 | Zarr files from Azure bolb storage using the new `abfs` data store. |
79 | 123 |
|
80 | | - |
81 | | -* Added a catalog API compliant to [STAC](https://stacspec.org/en/) to |
82 | | - xcube server. (#455) |
83 | | - - It serves a single collection named "datacubes" whose items are the |
84 | | - datasets published by the service. |
85 | | - - The collection items make use the STAC |
86 | | - [datacube](https://github.com/stac-extensions/datacube) extension. |
87 | | - |
88 | | -* Simplified the cloud deployment of xcube server/viewer applications (#815). |
89 | | - This has been achieved by the following new xcube server features: |
90 | | - - Configuration files can now also be URLs which allows |
91 | | - provisioning from S3-compatible object storage. |
92 | | - For example, it is now possible to invoke xcube server as follows: |
93 | | - ```bash |
94 | | - $ xcube serve --config s3://cyanoalert/xcube/demo.yaml ... |
95 | | - ``` |
96 | | - - A new endpoint `/viewer/config/{*path}` allows |
97 | | - for configuring the viewer accessible via endpoint `/viewer`. |
98 | | - The actual source for the configuration items is configured by xcube |
99 | | - server configuration using the new entry `Viewer/Configuration/Path`, |
100 | | - for example: |
101 | | - ```yaml |
102 | | - Viewer: |
103 | | - Configuration: |
104 | | - Path: s3://cyanoalert/xcube/viewer-config |
105 | | - ``` |
106 | | - - A typical xcube server configuration comprises many paths, and |
107 | | - relative paths of known configuration parameters are resolved against |
108 | | - the `base_dir` configuration parameter. However, for values of |
109 | | - parameters passed to user functions that represent paths in user code, |
110 | | - this cannot be done automatically. For such situations, expressions |
111 | | - can be used. An expression is any string between `"${"` and `"}"` in a |
112 | | - configuration value. An expression can contain the variables |
113 | | - `base_dir` (a string), `ctx` the current server context |
114 | | - (type `xcube.webapi.datasets.DatasetsContext`), as well as the function |
115 | | - `resolve_config_path(path)` that is used to make a path absolut with |
116 | | - respect to `base_dir` and to normalize it. For example |
117 | | - ```yaml |
118 | | - Augmentation: |
119 | | - Path: augmentation/metadata.py |
120 | | - Function: metadata:update_metadata |
121 | | - InputParameters: |
122 | | - bands_config: ${resolve_config_path("../common/bands.yaml")} |
123 | | - ``` |
124 | | - |
125 | 124 | * xcube's `Dockerfile` no longer creates a conda environment `xcube`. |
126 | 125 | All dependencies are now installed into the `base` environment making it |
127 | 126 | easier to use the container as an executable for xcube applications. |
|
0 commit comments