[Feat] t.rast.mapcalc: add a temporal where option

[ninsbl]

Is your feature request related to a problem? Please describe.
Many temporal tools have a temporal "where" option to select subsets of the STRDS for processing, but not t.rast.mapcalc. t.rast.mapcalc does have temporal operators as part of the mapcalculator expression, but those do not allow to process only a subset of the data.

Describe the solution you'd like
Add a temporal where option to t.rast.mapcalc to select only a subset for processing...

Describe alternatives you've considered
t.rast.algebra may be able to temorarily subset an STRDS and for some cases t.rast.extract may be sufficient. However, having where as a standard option for temporal modules may simplify usage of temporal tools....

Additional context
t.rast.mapcalc allows to use multiple STRDS as input, so, one has to think a bit about how behavior should be in case of multiple input STRDS that may have different temporal extents and granularities (or should be handled with temporal offsets...

[sakirr05]

hey @ninsbl
Should the where= condition be applied independently to each input STRDS before temporal alignment, similar to other t.* modules?
In case of multiple STRDS, should time steps be skipped when one of the inputs has no maps after filtering?

[ninsbl]

Good questions, @sakirr05

If no sampling is needed (only one input STRDS) the case is quite simple and all that is needed would be to add the "where" parameter here:

grass/python/grass/temporal/mapcalc.py

Line 205 in b166c02

list = dataset.get_registered_maps_as_objects(dbif=dbif)

For the other case (when datasets need to be sampled), the where option would probably have to be added as an optional kwarg to the sample_by_dataset method (

grass/python/grass/temporal/abstract_space_time_dataset.py

Line 627 in b166c02

def sample_by_dataset(self, stds, method=None, spatial: bool = False, dbif=None):

) first, and passed to get_registered_maps_as_objects and / or get_registered_maps_as_objects_with_gaps there.
Here it is a bit less obvious. Users may check if maps are NULL as part of their mapcalculator expressions. Not sure if a missing map / gap in the time series could or should be counted as NULL. However, if the first input would be empty, all sampling results would be empty as well...So, I tend to say temporal filtering should be added to both STDS in case of sampling... But only filtering the first input (get_registered_maps_as_objects_with_gaps) may be OK too. Anyway, if sampling returns an empty list, t.rast.mapcalc will stop due to the lack of input....

Finally, in the module code, the where option should be added with the standard parser option G_OPT_T_WHERE:
https://grass.osgeo.org/grass-devel/manuals/parser_standard_options.html#g_opt_t_where

[sakirr05]

Thanks for the detailed explanation @ninsbl , this helps a lot.

Based on your reply, my understanding is:
If there is only one input STRDS and no sampling is needed, the solution is straightforward: add a where parameter and apply it directly when calling get_registered_maps_as_objects()

In the case where sampling is required (multiple STRDS), the where option should be handled in sample_by_dataset(), likely as an optional keyword argument, and applied consistently to all input STRDS

Temporal filtering should be applied before sampling, but only to the STRDS involved in sampling (and not just the first input)

If filtering results in an empty list, it’s acceptable for r.trast.mapcalc to stop due to lack of input, rather than trying to handle missing gaps

I’ll start by handling the simple case first (single STRDS, no sampling), and then extend it to the sampling case following the same logic. Before opening a PR, I’ll double-check that this aligns with how other temporal modules handle where filtering

Let me know if this interpretation matches your expectations.

[ninsbl]

Thanks for your interest @sakirr05.
From my understanding of t.rast.mapcalc , I would say that all input STRDS should be filtered, if a temporal where option is given.

Just to clarify: it makes sense to start with the simple case as you suggest. That said, both cases need to be addressed and solved before a PR can be merged, IMHO...

[sakirr05]

Thanks for the clarification @ninsbl , that makes sense
I’ll make sure the temporal where filtering is applied to all input STRDS and handle both the simple and sampling cases before opening a PR