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

[Stefan Blumentrath]

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 at 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 at nina.no<mailto:Stefan.Blumentrath at 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 at lists.osgeo.org<mailto:grass-dev-bounces at lists.osgeo.org>> på vegne av Markus Neteler <neteler at osgeo.org<mailto:neteler at 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 at nikosalexandris.net<mailto:nik at nikosalexandris.net>> wrote:
> > * Markus Metz <markus.metz.giswork at gmail.com<mailto:markus.metz.giswork at gmail.com>> [2018-08-01 20:33:33 +0200]:
> > >On Wed, Aug 1, 2018 at 11:59 AM, Nikos Alexandris <nik at nikosalexandris.net<mailto:nik at 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 :-)
>
> > 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 at lists.osgeo.org<mailto:grass-dev at lists.osgeo.org>
> https://lists.osgeo.org/mailman/listinfo/grass-dev
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org<mailto:grass-dev at lists.osgeo.org>
> https://lists.osgeo.org/mailman/listinfo/grass-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20190211/1e9903ee/attachment-0001.html>