Feature request: phenology-adaptive STMs

[olegzhelezn]

It is currently possible to make phenology-adaptive BAPs. However, a similar possibility (setting up custom start and end of period of interest based on LSP data) is not implemented in the TSA module. I think it would be a reasonable and helpful addition.

[davidfrantz]

This is an interesting idea. Do you mean like a pixel-specific filtering for dates? Or rather a close integration, e.g. for weighting STMs or similar?

[olegzhelezn]

What I thought of is more like the former: e.g. calculating metrics (median, percentiles) between the start and the end of the season, variable for each pixel.

[davidfrantz]

OK I see. This is reasonable. I will look into this.

[kelewinska]

sounds cool!
but how a double-season will be handed though?

[davidfrantz]

I think it won't. Otherwise, things will get complicated very quickly.

I envsion it as an additional filter, where you can input two images, one for the start, one for the end.

Supporting edge cases would be quite difficult...

One question that I have:
Should the images be static? This would be similar to the DOY_RANGE parameter - but on the pixel level.
Or do you require dynamic layers for each year, e.g. based on phenometrics? (like in phenology-adaptive comositing).

While this would be possible, please note that using some of the available functions could result in unexpected and maybe even unwanted effects.

I am thinking about phenometrics or fold-by-year products.

[olegzhelezn]

In my case, static images would be sufficient - but with a possibility of having an interval of several years (like in BAPs, so including specified (same) intervals from neighboring or preceding years into the data pool for metric calculation).

What would be nice is some flexibility to potentially have a combination of fixed start of season (as a single number) and variable (pixelwise) EOS (or vice versa). But this is rather easily bypassed by creating images with uniform dates for one of the endpoints, so not so important.

[kelewinska]

If the function is going to accept one image for SOS and one for EOS, then double seasons could be dealt with too.
i think a static approach i.e. - one set of SOS and EOS is enough, but as @olegzhelezn suggests a year range would be a great addition.

[davidfrantz]

with image, I mean a one-band image.

However, it may be possible to allow for two multiband images, which contain dates (not just DOY). This way, multiple windows could be defined variably. This would allow for multiple windows per year, as well as windows that extend across years.

However, to clarify: this would only represent a more adaptive filtering in the same way as the combination of DOY_RANGE and YEAR_RANGE. In fact, it will also be possible to use all these options simultaneously. You wouldn't get STMs for each window, for example. And fold-by-year would split windows if they extend across the year.