[Feature Request]: Allow for both forward and backward validity ranges

[wadhwamatic]

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

Data layers published by WFP's Humanitarian Data Cube (HDC - https://api.earthobservation.vam.wfp.org/ows/) have multiple time aggregations including 10-day, 1-month, 3-month, etc.

The reference period for a data layer is straightforward for 10-day products. The date is the beginning of a 10-day period. So, 1-November would refer to 1-November through 10-November; 11-November would refer to 11-November through 20-November; and 21-November refers to 21-November through 30-November. For these products, I can use a validity of 10-day forward and get the result I need. It seems we're somehow also managing to handle 31-day months with this approach with this configuration:

    "validity": {
      "days": 10,
      "mode": "forward"
    }

However, 1-month aggregations and above are confusing on the HDC side. A 1-month aggregation published on 1-November refers to the beginning of the last dekad in the one month period AND the two dekads prior. So the coverage would be from 11-October through 10-November. As of now, there's no way to create this in the layer configuration.

I need to be able to configure something like:

    "validity_periods": [
      {
        "days": 10,
        "mode": "forward"
      },
      {
        "days": 20,
        "mode": "backward"
      }
    ]

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

[ericboucher]

@wadhwamatic since it looks like #1093 will not provide all the info we need (exact start/end dates), how about changing the validity config a bit to this object:

"validity": { "mode": "dekad", // or days "backward": 2, "forward": 1 }

Having a list as you proposed also makes sense.

Can you also describe a bit more how things work for 2-month and more periods?

[wadhwamatic]

@ericboucher - I like your suggestion:

"validity": { "mode": "dekad", // or days "backward": 2, "forward": 1 }

Let's use that structure rather than what I proposed.

Kirill mentioned the duration concept in https://github.com/WFP-VAM/prism-app/issues/1093 which is helpful, but it doesn't address the position of the period within the duration. So as far as I can tell, we'll still need to use backward and forward.

For 1-month and longer, the way it's been implemented is not intuitive. The date used in HDC refers to the beginning of the last dekad of a product for any product (1-month or longer). We're always working in terms of dekads (unless it's daily).

A 2-month product could therefore be implemented like this:

 "validity": {
 "mode": "dekad"
 "backward": 5,
 "forward": 1
 }

A 1-year product would look like this:

 "validity": {
 "mode": "dekad"
 "backward": 35,
 "forward": 1
 }

cc @valpesendorfer

[ericboucher]

Linked to #1224