Fw: [GRASS-user] r.le.patch moving window output and other moving window commands

[Koen Hufkens]

I checked the values with d.what (.rast) and it seems that they are real
values and using a uneven window size didn't alter the results either.

So now I have to figure out why the output has such a limited range.

What strikes me is the lack of a fuzzy border around the obvious windows
(see results picture in my previous post). When the sliding window
enters an isolated patch it seems that this patch isn't accounted for
until it doesn't touch any border, probably to correct for edge effects.
This could explain the abrupt edges on the moving window results and the
limited range of data.

Koen


On Thu, 2006-12-14 at 10:13 -0700, William L. Baker wrote:
> Hello Koen, Hamish,
> 
> I wonder if you could check the output map with d.what.rast (not sure 
> that's still a program?) to see if the output map shows integer values 
> or if there is a decimal point shown?
> 
> I wonder what the window size is that you used? It is possible to get 
> integer result when the window is an even number of pixels and the map 
> is binary (e.g., a window with 10 pixels taking only two values will 
> always have an integer mean).
> 
> Bill Baker, Univ. of Wyoming
> 
> Hamish wrote:
> > any ideas? is it showing delta-value instead of value?   cheers, Hamish
> >
> >
> > Begin forwarded message:
> >
> > Date: Wed, 13 Dec 2006 13:02:00 +0100
> > From: Koen Hufkens <koen.hufkens at ua.ac.be>
> > To: GRASS mailinglist <grassuser at grass.itc.it>
> > Subject: [GRASS-user] r.le.patch moving window output and other moving	window commands
> >
> >
> > Okay,
> >
> > I got Grass 6.2 running and r.le.setup works fine (my data didn't work
> > well at first with r.le.setup it seems). But I ran a windowed r.le.patch
> > analysis (this is why I needed the r.le.setup to work in the first
> > place) and it didn't produce the expected results.
> >
> >
> > I have a gradual transition of one type to another but not in values but
> > rather in patch size and density (classified as 1 and 2 - binary so to
> > speak). the line below illustrates it more or less.
> >
> > type 1 --- patchy type 1 and type 2 -- type 2
> >
> > and an image:
> >
> > http://users.pandora.be/requested/images/input.jpg
> >
> > So I was thinking of running a moving window analysis across this image
> > returning in the first place a mean patch size for every moving window,
> > you can think of this more or less like a weighted average according to
> > patch size. I expected a continuous output but this was not the case.
> >
> > This is the output I get on the input image above:
> >
> > http://users.pandora.be/requested/images/mean-patch-size.jpg
> >
> > (in this case I used round windows, if I use square windows I get the
> > same result with square yellow and green patches)
> >
> > I noticed that in r.neighbors and r.mfilter results are rounded to the
> > nearest integer (resulting in non continuous results). Is this also the
> > case in the results of r.le.patch using the moving window approach (sam
> > = m). In addition to my r.le.patch problem, is there a way to get real
> > values out of r.mfilter or r.neighbors or an alternative function? It
> > seems a little strange to force a rounded output onto people while this
> > rounding would just be a reclass of a real valued output.
> >
> > Kind regards,
> > Koen
> >
> > _______________________________________________
> > grassuser mailing list
> > grassuser at grass.itc.it
> > http://grass.itc.it/mailman/listinfo/grassuser
> >
> >