t.rast.univar: allow r-flag combined with zones option

[ninsbl]

Fix #4576

The library function actually used already a region environment. So it did not have to be added. But the region env was actualy applied redundant to the r-flag for STRDS...
So, now, the region env is only used if r-flag and zones are combined or for STR3DS. If only the r-flag is used, it is propagated to r.univar (for STRDS).

[echoix]

I don't see a problem with the code changed, but I don't think I understand well the issue. What was the exclusivity between the options protecting before?

I think it boils down to the fact that I don't know yet the details of the implementation of an STR3DS vs just a temporal raster STRDS.

[ninsbl]

r.univar does not allow to use the r-flag and the zones option, because the region would change while the zones map is open. That limitation was handed down to the temporal application of the module. However, the region can be changed to the input map(s) using a region env for the call to r.univar. That would have the same effect and circumvent the problem in r.univar.

r3.univar does not have an r-flag (see: https://grass.osgeo.org/grass-stable/manuals/r3.univar.html), so space time 3D raster datasets need to use the region env to that effect anyway...

[ninsbl]

@neteler or @veroandreo do you have any thoughts on this maybe?

[echoix]

r.univar does not allow to use the r-flag and the zones option, because the region would change while the zones map is open. That limitation was handed down to the temporal application of the module. However, the region can be changed to the input map(s) using a region env for the call to r.univar. That would have the same effect and circumvent the problem in r.univar.

r3.univar does not have an r-flag (see: https://grass.osgeo.org/grass-stable/manuals/r3.univar.html), so space time 3D raster datasets need to use the region env to that effect anyway...

Thanks, I better understand why the change works now. The biggest missing piece for me was that zones is like map (that is to be opened), and they can have different regions

[echoix]

I've attentively reviewed (in an IDE this time) in regard to this comment: #4577 (comment).
So if that comment makes sense, then after addressing the docstring review comment, this PR would be good to go.

Sorry for the delay, I didn't touch a computer for the whole week

[echoix]

This is coherent with your explanations in #4577 (comment)

But now, the docstring of the rast_region parameter of this function (compute_univar_stats()) should be adjusted to reflect the change.

Currently, it reads:

    :param rast_region: If set True ignore the current region settings
           and use the raster map regions for univar statistical calculation.
           Only available for strds.