Since the frontend was a fork of WHIS there is already a defined structure for the API responses.
The app relies on a standard STAC api with the following details:
One collection with the geometries of the AOIs, where each item is an AOI and has a name and an id. For WHIS we have the volume of each lake, but here we can replace with something else, or remove it.
A second collection with all the data for the AOIs, where each item corresponds to an AOI and a date. (item named <AOI ID>_<DATE>). Each item has one asset for each indicator we want to show, where for each asset we have (cog, mean, min, max).
We also need a way to get information about the exiting indicators:
- id
- name
- values extent
- dates extent
In the case of WHIS this is somewhat hardcoded.
This is the structure that the app uses at the moment. There can be changes to better suit a more abstracted use case, but shouldn't be drastically different.
@emmanuelmathot @ciaransweet @pantierra Maybe let's discuss whether this is workable.
Since the frontend was a fork of WHIS there is already a defined structure for the API responses.
The app relies on a standard STAC api with the following details:
One collection with the geometries of the AOIs, where each item is an AOI and has a
nameand anid. For WHIS we have the volume of each lake, but here we can replace with something else, or remove it.A second collection with all the data for the AOIs, where each item corresponds to an AOI and a date. (item named
<AOI ID>_<DATE>). Each item has one asset for each indicator we want to show, where for each asset we have (cog,mean,min,max).We also need a way to get information about the exiting indicators:
In the case of WHIS this is somewhat hardcoded.
This is the structure that the app uses at the moment. There can be changes to better suit a more abstracted use case, but shouldn't be drastically different.
@emmanuelmathot @ciaransweet @pantierra Maybe let's discuss whether this is workable.