[Feature Request]: Provide inputs for a replacement of WMS getCapabilities requests to WFP's HDC

[wadhwamatic]

Provide a clear and concise description of what you want to happen.

As mentioned in #1091, WFP's HDC will phase out WMS services. Tiles will be covered in #1091. In addition, we need to propose to @valpesendorfer what we would need to replace the WMS getCapabilities requests used to fetch available dates per layer.

There's an opportunity here to revisit date logic for layers served via HDC, but keeping in mind we still need to maintain the previous approach for other WMS servers providing data to PRISM.

The main thing to improve is that HDC / STAC support start and end dates per data product. For example, within the rfh_dekad product, each data point (STAC item) specifies start and end date as seen in the example below for rfh_dekad-202401d2:

Ideally this will help us address issue #1025 and help to simplify solutions in #1040

Is there anything else you can add about the proposal? You might want to link to related issues here, if you haven't already.

No response

[Kirill888]

@wadhwamatic we do not expect you to extract the same information you are currently getting out of WMS getCapabilities directly from STAC endpoint. Most likely we will have a single json file that describes all the available collections and their colorizations, it will also provide info needed to construct endpoint urls from a selected temporal bin.

I was looking at TileJSON as a possible candidate, but I don't think that works well enough for our needs, we have too many "tilesets". I was thinking something along these lines:

[
  {
    "id": "rfq_dekad",
    "title": "CHIRPS dekadal rainfall anomaly",
    "abstract": "Anomaly of dekadal CHIRPS data compared to long term average (LTA). The anomaly is specified on percent relatvive to the LTA (i.e. > 100 indicating above LTA and < 100 below)",
    "attribution": "Climate Hazards Group, Department of Geography, University of California at Santa Barbara",
    "keywords": [
      "chirp",
      "chirps",
      "rainfall",
      "spi",
      "un",
      "humanitarian",
      "anomaly",
      "precipitation",
      "remote-sensing",
      "time-series",
      "earth-observation",
      "satellite",
      "standardized precipitation index"
    ],
    "bbox": [-180,-50,180,50],
    "styles": [
      "rfq_14_20_400",
      "ryq_14_50_200"
    ],
    "time": [
      "1981-01-01",
      "1981-01-11",
      "1981-01-21",
      "1981-02-01",
      "1981-02-11",
      "...",
      "2024-01-21",
      "2024-02-01",
      "2024-02-11"
    ],
    "duration": "dekad",
    "period": "dekad",
    "href": "https://tiles.earthobservation.vam.wfp.org/rfq_dekad/{s}/{t}/{z}/{x}/{y}.png"
  },
  {
    "id": "r3q_dekad",
    "title": "CHIRPS Dekad: 3 months aggregated rainfall anomaly",
    "abstract": "Anomaly of dekadal CHIRPS data over 3 months aggregation, compared to long term average (LTA). The anomaly is specified on percent relatvive to the LTA (i.e. > 100 indicating above LTA and < 100 below)",
    "attribution": "Climate Hazards Group, Department of Geography, University of California at Santa Barbara",
    "keywords": [
      "chirp",
      "chirps",
      "rainfall",
      "spi",
      "un",
      "humanitarian",
      "anomaly",
      "precipitation",
      "remote-sensing",
      "time-series",
      "earth-observation",
      "satellite",
      "standardized precipitation index"
    ],
    "bbox": [-180,-50,180,50],
    "styles": [
      "rfq_14_20_400",
      "ryq_14_50_200"
    ],
    "time": [
      "1981-01-01",
      "1981-01-11",
      "1981-01-21",
      "1981-02-01",
      "1981-02-11",
      "...",
      "2024-01-21",
      "2024-02-01",
      "2024-02-11"
    ],
    "duration": "3m",
    "period": "dekad",
    "href": "https://tiles.earthobservation.vam.wfp.org/r3q_dekad/{s}/{t}/{z}/{x}/{y}.png"
  }
]

In the above you replace {s} with a chosen style and {t} with the selected time label to get a url template for the mapping libs.

From time, and duration one can reconstruct period covered, time being start date and duration is an aggregation window size. period is how often we expect to see new set of values (some might be missing for whatever reasons), maybe a better name would be frequency, or repeats.

Also dekad is different from just 10d, hence special value. Dekad is a way to partition calendar month into three somewhat equal parts: [1, 10], [11, 20] and [21, 28|29|30|31].

[ericboucher]

Linked to #1138
We can now define layers validity periods like this:

type Validity = {
  mode: DatesPropagation; // Propagation mode for dates - currently day || dekad.
  backward: number; // Number of days/dekades backward.
  forward: number; // Number of days/dekades forward.
};