[GRASS-dev] [GRASS GIS] #1388: r3.univar gives bad results for cell counts

GRASS GIS GRASS GIS developer
1

#1388: r3.univar gives bad results for cell counts
-----------------------+----------------------------------------------------
Reporter: hamish | Owner: grass-dev@…
     Type: defect | Status: new
Priority: critical | Milestone: 6.4.2
Component: Raster | Version: svn-develbranch6
Keywords: r3.univar | Platform: Linux
      Cpu: x86-32 |
-----------------------+----------------------------------------------------
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

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1388&gt;
GRASS GIS <http://grass.osgeo.org>

2

#1388: r3.univar gives bad results for cell counts
-----------------------+----------------------------------------------------
Reporter: hamish | Owner: grass-dev@…
     Type: defect | Status: new
Priority: critical | Milestone: 6.4.2
Component: Raster | Version: svn-develbranch6
Keywords: r3.univar | Platform: Linux
      Cpu: x86-32 |
-----------------------+----------------------------------------------------

Comment(by huhabla):

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

Soeren

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1388#comment:1&gt;
GRASS GIS <http://grass.osgeo.org>

3

#1388: r3.univar gives bad results for cell counts
-----------------------+----------------------------------------------------
Reporter: hamish | Owner: grass-dev@…
     Type: defect | Status: new
Priority: critical | Milestone: 6.4.2
Component: Raster | Version: svn-develbranch6
Keywords: r3.univar | Platform: Linux
      Cpu: x86-32 |
-----------------------+----------------------------------------------------

Comment(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

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1388#comment:2&gt;
GRASS GIS <http://grass.osgeo.org>

4

#1388: r3.univar gives bad results for cell counts
-----------------------+----------------------------------------------------
Reporter: hamish | Owner: grass-dev@…
     Type: defect | Status: new
Priority: critical | Milestone: 6.4.2
Component: Raster | Version: svn-develbranch6
Keywords: r3.univar | Platform: Linux
      Cpu: x86-32 |
-----------------------+----------------------------------------------------

Comment(by mmetz):

Replying to [comment:2 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

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1388#comment:3&gt;
GRASS GIS <http://grass.osgeo.org>

5

#1388: r3.univar gives bad results for cell counts
-----------------------+----------------------------------------------------
Reporter: hamish | Owner: grass-dev@…
     Type: defect | Status: new
Priority: critical | Milestone: 6.4.2
Component: Raster | Version: svn-develbranch6
Keywords: r3.univar | Platform: Linux
      Cpu: x86-32 |
-----------------------+----------------------------------------------------

Comment(by hamish):

Replying to [comment:3 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

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1388#comment:4&gt;
GRASS GIS <http://grass.osgeo.org>

6

#1388: r3.univar gives bad results for cell counts
-----------------------+----------------------------------------------------
Reporter: hamish | Owner: grass-dev@…
     Type: defect | Status: new
Priority: critical | Milestone: 6.4.2
Component: Raster | Version: svn-develbranch6
Keywords: r3.univar | Platform: Linux
      Cpu: x86-32 |
-----------------------+----------------------------------------------------

Comment(by hamish):

Replying to [comment:4 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

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1388#comment:5&gt;
GRASS GIS <http://grass.osgeo.org>

7

#1388: r3.univar gives bad results for cell counts
-----------------------+----------------------------------------------------
Reporter: hamish | Owner: grass-dev@…
     Type: defect | Status: new
Priority: critical | Milestone: 6.4.2
Component: Raster | Version: svn-develbranch6
Keywords: r3.univar | Platform: Linux
      Cpu: x86-32 |
-----------------------+----------------------------------------------------

Comment(by mmetz):

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

Markus M

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1388#comment:6&gt;
GRASS GIS <http://grass.osgeo.org>

8

#1388: r3.univar gives bad results for cell counts
-----------------------+----------------------------------------------------
  Reporter: hamish | Owner: grass-dev@…
      Type: defect | Status: closed
  Priority: critical | Milestone: 6.4.2
Component: Raster | Version: svn-develbranch6
Resolution: fixed | Keywords: r3.univar
  Platform: Linux | Cpu: x86-32
-----------------------+----------------------------------------------------
Changes (by hamish):

  * status: new => closed
  * resolution: => fixed

Comment:

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

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1388#comment:7&gt;
GRASS GIS <http://grass.osgeo.org>