r3.univar gives bad results for cell counts

[hamish]

Hi,

r3.univar gives wrong results for cell counts. tested in 6.5svn on debian oldstable&stable ia32&amd64.

2x2 test

cat << EOF > test_rast3d_2x2.asc
north: 2.0
south: 0.0
east: 2.0
west: 0.0
top: 2.0
bottom: 0.0
rows: 2
cols: 2
levels: 2
0 1
1 0
1 0
0 1
EOF

r3.in.ascii in=test_rast3d_2x2.asc out=test3d.2x2
g.region rast3d=test3d.2x2

r3.univar test3d.2x2
==> total null and non-null cells: 0
==> total null cells: -8

Of the non-null cells:
----------------------
n: 8
minimum: 0
maximum: 0
range: 0
mean: 0.5
mean of absolute values: 0.5
standard deviation: 0.5
variance: 0.25
variation coefficient: 100 %
sum: 4

stats seem ok, cell counts at top of 0,-8 should be 8,0.

3x3 test

cat << EOF > test_rast3d_3x3.asc
north: 3.0
south: 0.0
east: 3.0
west: 0.0
top: 3.0
bottom: 0.0
rows: 3
cols: 3
levels: 3
0 0 1
0 1 0
1 0 0
1 0 0
0 1 0
0 0 1
0 1 0
0 1 0
0 1 0
EOF

r3.in.ascii in=test_rast3d_3x3.asc out=test3d.3x3
g.region rast3d=test3d.3x3
r3.univar test3d.3x3

==> total null and non-null cells: 0
==> total null cells: -27

Of the non-null cells:
----------------------
n: 27
minimum: 0
maximum: 0
range: 0
mean: 0.333333
mean of absolute values: 0.333333
standard deviation: 0.471405
variance: 0.222222
variation coefficient: 141.421 %
sum: 9

same header text is wrong, but the rest of the stats (including n) are ok.

The r3.info values look ok.

?, Hamish

[huhabla]

These issues should be fixed in r46670 grass7. After testing we can backport these changes to 6.4.

Soeren

[hamish]

I'll have to refamiliarize myself with the r3/zonal bits of the module before being auditing it properly, please wait on any backport. I suspect that val_f and val_d want to remain as float and double, even if in a practical sense they are the same as FCELL and DCELL types.

thanks, Hamish

[mmetz]

Replying to hamish:

I'll have to refamiliarize myself with the r3/zonal bits of the module before being auditing it properly, please wait on any backport. I suspect that val_f and val_d want to remain as float and double, even if in a practical sense they are the same as FCELL and DCELL types.

I have submitted some more (tested) fixes, particularly for zonal stats.

IMHO, it may be safer to have val_f and val_d as FCELL and DCELL because they are used in G3d_getValue().

Markus M

[hamish]

Replying to mmetz:

I have submitted some more (tested) fixes, particularly for zonal stats.

thanks, I'll give it a better look after I get back from sea.

IMHO, it may be safer to have val_f and val_d as FCELL and DCELL because they are used in G3d_getValue().

my main concern is that I apparently went to the trouble of adding a comment that they should be available for general use, so I'd like to audit that we aren't breaking any assumptions based on that comment, and no new casts are needed.

---

also I notice that r3.to.rast is giving me just min=max=0 2D maps from seemingly good 3D floating point temperature data? (gr6.5; r3.null was run to remove value=99.999 null cells, maybe that had something to do with it?)

thanks, Hamish

[hamish]

Replying to hamish:

also I notice that r3.to.rast is giving me just min=max=0 2D maps from seemingly good 3D floating point temperature data? (gr6.5; r3.null was run to remove value=99.999 null cells, maybe that had something to do with it?)

isolated it: nothing to do with r3.null, it was because I did type=float with r3.in.ascii. If I leave it as the default type (DCELL) then r3.to.rast works ok.

Hamish

[mmetz]

This bug has been fixed in June 2011 (5 months ago) with r46705. Please test and confirm.

Markus M

[hamish]

r3.univar tested using the example above & confirmed ok in all branches; closing ticket.

I am not sure if the r3.in.ascii type=float + r3.to.rast error mentioned in comment:5 is now fixed or not, I suspect it isn't.

thanks, Hamish