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.
There would be a need for a "bootstrap" file config passed to the webapp.
Please describe the runtime parameters the webapp needs to connect with the rest of the software components (e.g. STAC collections API)
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 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.