Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ENH: Add a user_index operator to aggregate values between spatially varying dates (1 date per pixel) #170

Open
bzah opened this issue May 5, 2022 · 1 comment

Comments

@bzah
Copy link
Member

bzah commented May 5, 2022

  • icclim version: 5.2.1

Description

Originally posted by @tlogan2000 and @pagecp in #162 (comment)

xclim provides a generic function to aggregate data between two ndarray of dates on simple reducers {‘min’, ‘max’, ‘sum’, ‘mean’, ‘std’}.

aggregate_between_dates allows for an array of start, end dates (i.e. that vary spatially over a large territory) to be used as inputs. A specific example would be something like calculating accumulated precipitation within a growing season.

Scientifically it would be quite useful to have this feature of having different start and end date possible depending on the gridpoint, and also the same for thresholds on field values (not percentiles).

In this ENH request we will focus on "different dates depending on the gridpoint".
For this we we should implement a new calc_operator to be used with user_index. To ease user experience I propose to stick with xclim's name "aggregate_between_dates".

Ideally, I would also like to come up with proper metadata generation for this calc_operator. Until now, metadata were quite poor when using user_index operators and it would be nice to come up with a generalist solution here to improve this situation.

@bzah bzah changed the title ENH: Add a user_index operator to aggregate between spatially varying dates (1 date per pixel) ENH: Add a user_index operator to aggregate values between spatially varying dates (1 date per pixel) May 5, 2022
@bzah
Copy link
Member Author

bzah commented Aug 5, 2022

Another option could be to enable a tuple[DataArray, DataArray] + a freq as a valid input for slice_mode (or add parameter for the tuple).

In that case it would enable this feature for all indices at once.
We could then compute, say su, on varying summer at the same time.

This could really go hand in hand with the generification done in #189.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant