mvmaltitz
commented
1 month ago Acceptance Criteria for GAP:
Non Functional Requirements
- [ ] Response times must be fast
- [ ] API must be well documented
- [ ] API must be easy to understand and use
- [ ] Micro-services architecture
- [ ] Use cloud native technologies and design patterns as far as possible
- [ ] The design and any code and documentation pertaining to it must be open source and open access
- [ ] Be able to scale over time
- [ ] Support extension and customisation to provide visualisations and analytics in addition to vector and gridded data
Functional Requirements
- [ ] Host and serve the CBAM reanalysis data set
- [ ] Host and serve additional data sets such as laser distrometer point data
- [ ] Host and serve georeferenced images
- [ ] In future provide access to hosted and third party ARD through one interface
- [ ] Handle the following request types: (a) Provide a bounding box or polygon and a date range and return records from all grid points and time steps that meet those spatial and temporal criteria (i.e. no spatial aggregation) i. If redundant spatial criteria are provided, for example multiple farm polygons falling within one CBAM grid cell, return only one set of matching results (i.e. no duplicates) ii. Aggregate variables into the requested time resolution if anything but raw temporal resolution is requested. Default aggregate statistics are mean, max and min. A. Hourly B. Three-hourly C. Daily (e.g. APSIM7 needs daily data) D. Monthly E. Annual F. Climatology – define a period and provide monthly aggregate statistics for each requested variable (b) Provide a bounding box or polygon and return a weighted spatial aggregate, e.g. for Regrow scenario analysis, such as for a trial area in Rwanda. Specifications of the aggregation algorithms remain to be defined. The system should support any aggregation method or provide options for multiple methods. Jonathan Ojeda (Regrow) noted that he can provide some algorithms. (c) Provide a point or a list / array of points and return the closest grid cell values for those points. e.g. for specific trial locations
- [ ] Bestiapop (11.4) developers must be able to configure this service as one of its data providers (as NASA Power10 is), to facilitate use by the APSIM6 or DSSAT8 models. The system should not duplicate functionality that Bestiapop already provides.
- [ ] Prioritise the return of raw meteorological data as opposed to post-processed or derived outputs like ‘growing degree days’. This is because the R package, climatrends (11.1), calculates many of the crop-specific agro-climatic indices needed for tricot predictive models. Furthermore, further development of climatrends will be done by 1000FARMS to add new indicators [TN001].
- [ ] REST request formats (a) GET requests to be structured into the url path as far as possible, minimising the use of key-value pairs (b) POST requests to contain JSON payload, with spatial elements as GeoJSON
- [ ] REST response formats. Returned data must be ‘Analysis Ready’, able to be ingested into operational tools ((a) JSON/GeoJSON, (b) csv, (c) XML, (d) Gridded (GeoTIFF, GeoJSON), (e) netCDF, (f) Zarr, (g) other OGC or model-specific formats as requested)
- [ ] Return rendered views of the data on request, e.g. as OGC WMS, KML/Z. This is to support visualisation of the data as opposed to analysis.
- [ ] Return comprehensive metadata: source, units, etc.
- [ ] Data should be browsable and directly downloadable as well
- [ ] Manage system use – register users and track who uses the platform and why
- [ ] Return these variables: See Table (page 6) in _Report - OSIRIS Data Access Framework for Next-Gen Weather technologies final version
This is the creation of the analysis ready data API and all the dependencies therefore.