Added API endpoints for listing download links and downloading coverage data #247
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR implements API endpoints for listing and downloading forecast-related coverages.
Implementation is based on the strategy discussed in
#150 (comment)
There are two endpoints:
/api/v2/coverages/forecast-data
- lists download linksThis allows filtering by means of the following query parameters, which all accept multiple values:
climatological_variable
(tas, tasmin, pr, fd, etc.)aggregation_period
(30yr, annual)climatological_model
(model_ensemble, etc.)scenario
(rcp26, rcp45 etc.)/api/v2/coverages/forecast-data/{coverage_identifier}
- allows download of a coverage as a NetCDF fileThis endpoint accepts spatial and temporal subsetting parameters:
datetime
accepts a string of the formstart/end
where start and end are either a date like2024-01-01
or..
to indicate an open intervalcoords
accepts a polygon specified in WKTExample usage:
Get all download links for the
tas
indicator, with an aggregation period ofannual
, a climatological model ofmodel_ensemble
and scenario ofrcp45
:The result is like this:
The resulting links list can be used by the frontend to show a list of possible downloads to the user.
When the user chooses a link, it can perform a request like this:
As shown above, the user can include the
coords
anddatetime
query parameters in order to request a spatial and temporal subset of the coverage.The result of this request is a netcdf file with the coverage data, which can then be loaded in e.g. QGIS, as shown below:
Details
In order to allow caching, the spatial subsetting is done by adjusting the input to a well-known grid - this means that the result is always a spatial area that is slightly larger than what the client requested. This well-known grid is configurable in the settings and can even be set via env variables:
Data download requests are proxied to the THREDDS server and use its NCSS service, which allows the temporal and spatial subsetting.
This PR does not include the caching functionality yet, but the plan is to introduce it later and leverage the fact that it will be possible to save the prepared netcdf files in a local cache and reuse them when a similar request arrives, thus avoiding hitting the THREDDS server again to prepare the same data. Using this static grid will hopefully help in reducing the number of individual processing steps. The image below shows the grid (blue) and how a client-requested bbox (green) is fitted to the grid and used as the actual NCSS spatial extent (red):