[GRASS-dev] No 'count' method for r.statistics

GRASS GRASS developer
1

`r.statistics` which was/is meant for categorical raster maps, does not
provide for a 'count' method.

`r.stats.zonal`, on the other hand, which is meant for floating point
raster maps, does so.

This is rather unexpected. 'Count'ing pixels should rather derive 'CELL'
maps and not 'FCELL'.

At the moment, I require an extra mapcalc using the int() function.

Any comments?

Nikos

2

On Wed, Aug 1, 2018 at 11:59 AM, Nikos Alexandris <nik@nikosalexandris.net> wrote:

r.statistics which was/is meant for categorical raster maps, does not
provide for a ‘count’ method.

r.stats.zonal, on the other hand, which is meant for floating point
raster maps, does so.

This is rather unexpected. 'Count’ing pixels should rather derive ‘CELL’
maps and not ‘FCELL’.

At the moment, I require an extra mapcalc using the int() function.

Any comments?

Counting pixels can produce a result that is too large for CELL (32 bit integer), therefore storing the count as DCELL is a bit safer because it can exactly store integers larger than the 32 bit maximum.

In short, use r.stats.zonal rather than r.statistics.

Markus M

Nikos

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

3

* Markus Metz <markus.metz.giswork@gmail.com> [2018-08-01 20:33:33 +0200]:

On Wed, Aug 1, 2018 at 11:59 AM, Nikos Alexandris <nik@nikosalexandris.net>
wrote:

`r.statistics` which was/is meant for categorical raster maps, does not
provide for a 'count' method.

`r.stats.zonal`, on the other hand, which is meant for floating point
raster maps, does so.

This is rather unexpected. 'Count'ing pixels should rather derive 'CELL'
maps and not 'FCELL'.

At the moment, I require an extra mapcalc using the int() function.

Any comments?

Counting pixels can produce a result that is too large for CELL (32 bit
integer), therefore storing the count as DCELL is a bit safer because it
can exactly store integers larger than the 32 bit maximum.

In short, use r.stats.zonal rather than r.statistics.

Markus M

I understand it now.

If integrating this extra "int()" conversion, in `r.stats.zonal`, is not
a smart/wanted thing to do, maybe we should add an explanation in the
`r.statistics` manual. Why 'count' is missing and why `r.stats.zonal` should
be used.

I can offer a patch for the manual if you agree.

My guess is that the development team has future plans regarding all r.stat*
modules, to merge and simplify as much as possible.

Thank you Markus!

4

Hi,

On Fri, Aug 3, 2018 at 10:13 AM Nikos Alexandris
<nik@nikosalexandris.net> wrote:

* Markus Metz <markus.metz.giswork@gmail.com> [2018-08-01 20:33:33 +0200]:
>On Wed, Aug 1, 2018 at 11:59 AM, Nikos Alexandris <nik@nikosalexandris.net>
>wrote:
>>
>> `r.statistics` which was/is meant for categorical raster maps, does not
>> provide for a 'count' method.
>>
>> `r.stats.zonal`, on the other hand, which is meant for floating point
>> raster maps, does so.
>>
>> This is rather unexpected. 'Count'ing pixels should rather derive 'CELL'
>> maps and not 'FCELL'.
>>
>> At the moment, I require an extra mapcalc using the int() function.
>>
>> Any comments?
>
>Counting pixels can produce a result that is too large for CELL (32 bit
>integer), therefore storing the count as DCELL is a bit safer because it
>can exactly store integers larger than the 32 bit maximum.
>
>In short, use r.stats.zonal rather than r.statistics.
>
>Markus M

I understand it now.

If integrating this extra "int()" conversion, in `r.stats.zonal`, is not
a smart/wanted thing to do, maybe we should add an explanation in the
`r.statistics` manual. Why 'count' is missing and why `r.stats.zonal` should
be used.

I can offer a patch for the manual if you agree.

No need to ask, it would be great :slight_smile:

My guess is that the development team has future plans regarding all r.stat*
modules, to merge and simplify as much as possible.

Suggestions may be discussed here.

A related question from a (remote) colleague:

They have two Land Cover raster files at different resolutions, one at
5 m x 5 m and the other at 30m x 30 m with both 9 identical
categories.
They want to count the number of pixels of a category of the first map
that fall within each pixel of the second.
How to do that in an elegant way?

thanks
Markus

5

Hi Markus,

Not sure I fully understand the objective, but did you consider:

r.stats -c input=A_map,B_map
https://grass.osgeo.org/grass76/manuals/r.stats.html
(for overall counts)

or

https://grass.osgeo.org/grass76/manuals/r.resamp.stats.html
(for counts/diversity within each pixel).

Cheers
Stefan

···

Fra: grass-dev grass-dev-bounces@lists.osgeo.org på vegne av Markus Neteler neteler@osgeo.org
Sendt: mandag 11. februar 2019 20.54
Til: Nikos Alexandris
Kopi: GRASS-GIS development mailing list
Emne: Re: [GRASS-dev] No ‘count’ method for r.statistics

Hi,

On Fri, Aug 3, 2018 at 10:13 AM Nikos Alexandris
nik@nikosalexandris.net wrote:

On Wed, Aug 1, 2018 at 11:59 AM, Nikos Alexandris nik@nikosalexandris.net
wrote:

r.statistics which was/is meant for categorical raster maps, does not
provide for a ‘count’ method.

r.stats.zonal, on the other hand, which is meant for floating point
raster maps, does so.

This is rather unexpected. 'Count’ing pixels should rather derive ‘CELL’
maps and not ‘FCELL’.

At the moment, I require an extra mapcalc using the int() function.

Any comments?

Counting pixels can produce a result that is too large for CELL (32 bit
integer), therefore storing the count as DCELL is a bit safer because it
can exactly store integers larger than the 32 bit maximum.

In short, use r.stats.zonal rather than r.statistics.

Markus M

I understand it now.

If integrating this extra “int()” conversion, in r.stats.zonal, is not
a smart/wanted thing to do, maybe we should add an explanation in the
r.statistics manual. Why ‘count’ is missing and why r.stats.zonal should
be used.

I can offer a patch for the manual if you agree.

No need to ask, it would be great :slight_smile:

My guess is that the development team has future plans regarding all r.stat*
modules, to merge and simplify as much as possible.

Suggestions may be discussed here.

A related question from a (remote) colleague:

They have two Land Cover raster files at different resolutions, one at
5 m x 5 m and the other at 30m x 30 m with both 9 identical
categories.
They want to count the number of pixels of a category of the first map
that fall within each pixel of the second.
How to do that in an elegant way?

thanks
Markus

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

6

On Mon, Feb 11, 2019 at 9:17 PM Stefan Blumentrath <Stefan.Blumentrath@nina.no> wrote:

Hi Markus,

Not sure I fully understand the objective, but did you consider:

r.stats -c input=A_map,B_map
https://grass.osgeo.org/grass76/manuals/r.stats.html
(for overall counts)

I agree, this seems to be the easiest way. The region and resolution should first be set to match the high-res raster.

Markus M

or
https://grass.osgeo.org/grass76/manuals/r.resamp.stats.html
(for counts/diversity within each pixel).

Cheers
Stefan

Fra: grass-dev <grass-dev-bounces@lists.osgeo.org> på vegne av Markus Neteler <neteler@osgeo.org>
Sendt: mandag 11. februar 2019 20.54
Til: Nikos Alexandris
Kopi: GRASS-GIS development mailing list
Emne: Re: [GRASS-dev] No ‘count’ method for r.statistics

Hi,

On Fri, Aug 3, 2018 at 10:13 AM Nikos Alexandris
<nik@nikosalexandris.net> wrote:

On Wed, Aug 1, 2018 at 11:59 AM, Nikos Alexandris <nik@nikosalexandris.net>
wrote:

r.statistics which was/is meant for categorical raster maps, does not
provide for a ‘count’ method.

r.stats.zonal, on the other hand, which is meant for floating point
raster maps, does so.

This is rather unexpected. 'Count’ing pixels should rather derive ‘CELL’
maps and not ‘FCELL’.

At the moment, I require an extra mapcalc using the int() function.

Any comments?

Counting pixels can produce a result that is too large for CELL (32 bit
integer), therefore storing the count as DCELL is a bit safer because it
can exactly store integers larger than the 32 bit maximum.

In short, use r.stats.zonal rather than r.statistics.

Markus M

I understand it now.

If integrating this extra “int()” conversion, in r.stats.zonal, is not
a smart/wanted thing to do, maybe we should add an explanation in the
r.statistics manual. Why ‘count’ is missing and why r.stats.zonal should
be used.

I can offer a patch for the manual if you agree.

No need to ask, it would be great :slight_smile:

My guess is that the development team has future plans regarding all r.stat*
modules, to merge and simplify as much as possible.

Suggestions may be discussed here.

A related question from a (remote) colleague:

They have two Land Cover raster files at different resolutions, one at
5 m x 5 m and the other at 30m x 30 m with both 9 identical
categories.
They want to count the number of pixels of a category of the first map
that fall within each pixel of the second.
How to do that in an elegant way?

thanks
Markus

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

7

Hi again,

Vero had a feature request in a similar direction for v.rast.stats (count / mode statistics) for categorical raster maps (e.g. land cover).

Should such a feature be added to v.rast.stats or would it make more sense to create a new module for that for not overloading v.rast stats.
I would have some code snippet in v.rast.bufferstats (https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.rast.bufferstats/v.rast.bufferstats.py#L506) that I could re-purpose…

What do you think?

Cheers
Stefan

···

Fra: Markus Metz markus.metz.giswork@gmail.com
Sendt: mandag 11. februar 2019 21.19
Til: Stefan Blumentrath
Kopi: Markus Neteler; Nikos Alexandris; GRASS-GIS development mailing list
Emne: Re: [GRASS-dev] No ‘count’ method for r.statistics

On Mon, Feb 11, 2019 at 9:17 PM Stefan Blumentrath <Stefan.Blumentrath@nina.no> wrote:

Hi Markus,

Not sure I fully understand the objective, but did you consider:

r.stats -c input=A_map,B_map
https://grass.osgeo.org/grass76/manuals/r.stats.html
(for overall counts)

I agree, this seems to be the easiest way. The region and resolution should first be set to match the high-res raster.

Markus M

or
https://grass.osgeo.org/grass76/manuals/r.resamp.stats.html
(for counts/diversity within each pixel).

Cheers
Stefan

Fra: grass-dev <grass-dev-bounces@lists.osgeo.org> på vegne av Markus Neteler <neteler@osgeo.org>
Sendt: mandag 11. februar 2019 20.54
Til: Nikos Alexandris
Kopi: GRASS-GIS development mailing list
Emne: Re: [GRASS-dev] No ‘count’ method for r.statistics

Hi,

On Fri, Aug 3, 2018 at 10:13 AM Nikos Alexandris
<nik@nikosalexandris.net> wrote:

On Wed, Aug 1, 2018 at 11:59 AM, Nikos Alexandris <nik@nikosalexandris.net>
wrote:

r.statistics which was/is meant for categorical raster maps, does not
provide for a ‘count’ method.

r.stats.zonal, on the other hand, which is meant for floating point
raster maps, does so.

This is rather unexpected. 'Count’ing pixels should rather derive ‘CELL’
maps and not ‘FCELL’.

At the moment, I require an extra mapcalc using the int() function.

Any comments?

Counting pixels can produce a result that is too large for CELL (32 bit
integer), therefore storing the count as DCELL is a bit safer because it
can exactly store integers larger than the 32 bit maximum.

In short, use r.stats.zonal rather than r.statistics.

Markus M

I understand it now.

If integrating this extra “int()” conversion, in r.stats.zonal, is not
a smart/wanted thing to do, maybe we should add an explanation in the
r.statistics manual. Why ‘count’ is missing and why r.stats.zonal should
be used.

I can offer a patch for the manual if you agree.

No need to ask, it would be great :slight_smile:

My guess is that the development team has future plans regarding all r.stat*
modules, to merge and simplify as much as possible.

Suggestions may be discussed here.

A related question from a (remote) colleague:

They have two Land Cover raster files at different resolutions, one at
5 m x 5 m and the other at 30m x 30 m with both 9 identical
categories.
They want to count the number of pixels of a category of the first map
that fall within each pixel of the second.
How to do that in an elegant way?

thanks
Markus

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

8

On Mon, Feb 11, 2019 at 9:19 PM Markus Metz
<markus.metz.giswork@gmail.com> wrote:

On Mon, Feb 11, 2019 at 9:17 PM Stefan Blumentrath <Stefan.Blumentrath@nina.no> wrote:

...

>
> r.stats -c input=A_map,B_map
> https://grass.osgeo.org/grass76/manuals/r.stats.html
> (for overall counts)

Right, I didn't remember "-c" of r.stats.

I agree, this seems to be the easiest way. The region and resolution should first be set to match the high-res raster.

Thanks Stefan and Markus, I have fwd'ed your suggestions.

(if something extra makes sense I cannot judge but I'll let you know
if the proposed way worked for them)

Best
markusN