Opened 9 years ago

Closed 9 years ago

#1388 closed defect (fixed)

r3.univar gives bad results for cell counts

Reported by: hamish Owned by: grass-dev@…
Priority: critical Milestone: 6.4.2
Component: Raster Version: svn-develbranch6
Keywords: r3.univar Cc:
CPU: x86-32 Platform: Linux

Description

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

Change History (7)

comment:1 Changed 9 years ago by huhabla

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

Soeren

comment:2 Changed 9 years ago by 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

comment:3 in reply to:  2 ; Changed 9 years ago by 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

comment:4 in reply to:  3 ; Changed 9 years ago by 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

comment:5 in reply to:  4 Changed 9 years ago by 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

comment:6 Changed 9 years ago by mmetz

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

Markus M

comment:7 Changed 9 years ago by hamish

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.