t.rast.univar: allow r-flag combined with zones option #4577
Conversation
ninsbl
added
enhancement
|
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. |
|
|
|
@neteler or @veroandreo do you have any thoughts on this maybe? |
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 |
There was a problem hiding this comment.
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
| @@ -57,7 +57,7 @@ def compute_univar_stats(registered_map_info, stats_module, fs, rast_region=Fals | |||
| ) | |||
|
|
|||
| stats_module.inputs.map = id | |||
| if rast_region: | |||
| if rast_region and (stats_module.inputs.zones or stats_module.name == "r3.univar"): | |||
There was a problem hiding this comment.
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.
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).