No 'count' method for r.statistics

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

No 'count' method for r.statistics

NikosAlexandris
`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

_______________________________________________
grass-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: No 'count' method for r.statistics

Markus Metz-3


On Wed, Aug 1, 2018 at 11:59 AM, Nikos Alexandris <[hidden email]> 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
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/grass-dev


_______________________________________________
grass-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: No 'count' method for r.statistics

NikosAlexandris
* Markus Metz <[hidden email]> [2018-08-01 20:33:33 +0200]:

>On Wed, Aug 1, 2018 at 11:59 AM, Nikos Alexandris <[hidden email]>
>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!

_______________________________________________
grass-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: No 'count' method for r.statistics

Markus Neteler
Hi,

On Fri, Aug 3, 2018 at 10:13 AM Nikos Alexandris
<[hidden email]> wrote:

> * Markus Metz <[hidden email]> [2018-08-01 20:33:33 +0200]:
> >On Wed, Aug 1, 2018 at 11:59 AM, Nikos Alexandris <[hidden email]>
> >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 :-)

> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev
SBL
Reply | Threaded
Open this post in threaded view
|

Re: No 'count' method for r.statistics

SBL
Hi Markus,


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

r.stats -c input=A_map,B_map
(for overall counts)

or
(for counts/diversity within each pixel).

Cheers
Stefan

Fra: grass-dev <[hidden email]> på vegne av Markus Neteler <[hidden email]>
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
<[hidden email]> wrote:
> * Markus Metz <[hidden email]> [2018-08-01 20:33:33 +0200]:
> >On Wed, Aug 1, 2018 at 11:59 AM, Nikos Alexandris <[hidden email]>
> >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 :-)

> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev

_______________________________________________
grass-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: No 'count' method for r.statistics

Markus Metz-3


On Mon, Feb 11, 2019 at 9:17 PM Stefan Blumentrath <[hidden email]> 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 <[hidden email]> på vegne av Markus Neteler <[hidden email]>
> 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
> <[hidden email]> wrote:
> > * Markus Metz <[hidden email]> [2018-08-01 20:33:33 +0200]:
> > >On Wed, Aug 1, 2018 at 11:59 AM, Nikos Alexandris <[hidden email]>
> > >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 :-)
>
> > 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
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/grass-dev
> _______________________________________________
> grass-dev mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/grass-dev
_______________________________________________
grass-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev
SBL
Reply | Threaded
Open this post in threaded view
|

Re: No 'count' method for r.statistics

SBL
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 <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> på vegne av Markus Neteler <[hidden email]>
> 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
> <[hidden email]> wrote:
> > * Markus Metz <[hidden email]> [2018-08-01 20:33:33 +0200]:
> > >On Wed, Aug 1, 2018 at 11:59 AM, Nikos Alexandris <[hidden email]>
> > >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 :-)
>
> > 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
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/grass-dev
> _______________________________________________
> grass-dev mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/grass-dev

_______________________________________________
grass-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: No 'count' method for r.statistics

Markus Neteler
In reply to this post by Markus Metz-3
On Mon, Feb 11, 2019 at 9:19 PM Markus Metz
<[hidden email]> wrote:
> On Mon, Feb 11, 2019 at 9:17 PM Stefan Blumentrath <[hidden email]> 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
_______________________________________________
grass-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev