[saket0187]

Fixes #7525

[ninsbl]

Nice. Thanks! The same applies also to t.rast3d.univar:
https://github.com/OSGeo/grass/actions/runs/27260952617/job/80506261338?pr=7529#step:17:101

I guess it is sufficient to update the tests there according to your changes...

[ninsbl]

This looks good to me. @petrasovaa , what do you think about column names changing. Would that be considered part of the API? On the other hand, reason for the PR is a bug, so the change may be acceptable anyway?

[petrasovaa]

This looks good to me. @petrasovaa , what do you think about column names changing. Would that be considered part of the API? On the other hand, reason for the PR is a bug, so the change may be acceptable anyway?

I am for changing. I looked at r.univar again and here is r.univar with csv output:

GRASS nc_spm_08_grass7/user1:t.rast3d.list > r.univar inundation_113.0@user1 format=csv
non_null_cells,null_cells,min,max,range,mean,mean_of_abs,stddev,variance,coeff_var,sum,sum_abs
10,2024990,0.0344314575195312,0.356651306152344,0.322219848632812,0.161949157714844,0.161949157714844,0.0899406513064383,0.00808932075742632,55.5363501579944,1.61949157714844,1.61949157714844

Notably, the order is different and there is actually not the total number of cells. So since we are changing this anyway, perhaps we should make it match completely (with the exception of the temporal-specific columns)?

[saket0187]

This looks good to me. @petrasovaa , what do you think about column names changing. Would that be considered part of the API? On the other hand, reason for the PR is a bug, so the change may be acceptable anyway?

I am for changing. I looked at r.univar again and here is r.univar with csv output:

GRASS nc_spm_08_grass7/user1:t.rast3d.list > r.univar inundation_113.0@user1 format=csv
non_null_cells,null_cells,min,max,range,mean,mean_of_abs,stddev,variance,coeff_var,sum,sum_abs
10,2024990,0.0344314575195312,0.356651306152344,0.322219848632812,0.161949157714844,0.161949157714844,0.0899406513064383,0.00808932075742632,55.5363501579944,1.61949157714844,1.61949157714844

Notably, the order is different and there is actually not the total number of cells. So since we are changing this anyway, perhaps we should make it match completely (with the exception of the temporal-specific columns)?

I think there are actually some inconsistencies in r.univar as well. For example, there is an n key in the shell, JSON, and plain formats, but it's called non_null_cells in CSV. Also, the total cells count is present for shell and JSON, but it is missing entirely for CSV.

[petrasovaa]

I think there are actually some inconsistencies in r.univar as well. For example, there is an n key in the shell, JSON, and plain formats, but it's called non_null_cells in CSV. Also, the total cells count is present for shell and JSON, but it is missing entirely for CSV.

That's true, but I don't want to change r.univar, one of the most widely used tools. I would just match the t.rast.univar with r.univar, matching the format outputs.