Re: [GRASS-user] r.neighbour and r.mask

[hamish-2]

Milton Cezar Ribeiro wrote:
> I am running r.neighbors to compute some moving windows
> stats. As my region is irregular, many of central pixels
> will be NULL. If I use r.mask, it means that when I run
> r.neighbours the processing will be faster than when I
> not set r.mask


.... I wonder, if the gather.c loops in r.neighbors come across
a NULL if they should immediately break out of the for loop^2
and just set everything to NULL, as that is what the result
will be if it has any NULLs in it. [or maybe the test on each
cell is more expensive than the gathering process.  ??]

it might make the module a lot faster.


Hamish



     

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

[Glynn Clements]

Hamish wrote:

> > I am running r.neighbors to compute some moving windows
> > stats. As my region is irregular, many of central pixels
> > will be NULL. If I use r.mask, it means that when I run
> > r.neighbours the processing will be faster than when I
> > not set r.mask
>
>
> .... I wonder, if the gather.c loops in r.neighbors come across
> a NULL if they should immediately break out of the for loop^2
> and just set everything to NULL, as that is what the result
> will be if it has any NULLs in it. [or maybe the test on each
> cell is more expensive than the gathering process.  ??]

r.neighbors doesn't propagate nulls, but computes the aggregate over
the non-null cells. It doesn't even have an option to propagate nulls.

Adding such a flag would be reasonable, as would aborting the gather
loop at the first null when the flag is used. But the existing
behaviour certainly shouldn't be changed in 6.x.

--
Glynn Clements <[hidden email]>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[hamish-2]

Glynn wrote:
> r.neighbors doesn't propagate nulls, but computes the aggregate over
> the non-null cells. It doesn't even have an option to propagate nulls.


ah, good to know. thanks for the explanation.

help pages updated in SVN to mention this.


Hamish



     

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

[Glynn Clements]

Milton Cezar Ribeiro wrote:

> My feeling is that, mainly when running moving windows, the time to check if
> a central pixel is NULL, set output as null and skip must be (very?) lower
> than read all pixels inside the windows, compute the desired index, save it,
> clean the memory and go to next pixel. Or not?! It is with the developers
> :-)

r.neighbors won't output a null just because the central pixel is
null, only if the entire neighborhood is null.

--
Glynn Clements <[hidden email]>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Glynn Clements]

Milton Cezar Ribeiro wrote:

> In fact, I think that for many r.*, if a "skip if is null" flag could be
> setted, may be we can save a lot of time, mainly when running repetitive
> steps on large (60,000x48,000 pixels) maps are ran. And, on my case,
> addictionally the large size of the maps, as I work with multi-scale
> landscape index computing (percentage of cover, density of edge with
> different width, connectivity, number of patches), I need to run moving
> windows with large sizes (like 101x101 pixels). So, if when I set a
> skip_null=T (on my own risk!), I can save not only hours, but weeks of work.

This could be implemented by giving r.neighbors a mask= parameter, or
maybe we need an OUTMASK for output maps. This could be applied
automatically by the raster library to ensure consistency, but
potentially-slow modules could perform the check explicitly as an
optimisation.

--
Glynn Clements <[hidden email]>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev