[GRASSLIST:6123] Problems with r.le.pixel !?

GRASS GRASS user
1

Dear Grass users,

In a previous message, I mentioned memory allocation problems with the r.le.pixel command. I managed to avoid it using a smaller area.

For testing, I clipped a 2 by 2 degree area from the whole map and run r.le.pixel with the following command:

r.le.pixel map=test sam=m div=d3

and the following move_wind file:

       25 25 u_w u_l: CELL
      0.0 radius of circular moving window
      200 200 w_w w_l
        0 0 x0, y0

The landcover map and the resulting d3 output can be found here:

http://www.oomvanlieshout.net/ftp/d3.png
http://www.oomvanlieshout.net/ftp/landcover.png

The d3 map seems to have three layers, but I can not figure out what they mean. There seems to be some sensible information in the background, but that is over ruled by the square pattern.

Has anybody tried this recently and had similar results?

I am running GRASS 6.0.0beta2 (2005) on SUSE 9.1.

Thanks,

Sander.

PS I am trying to reproduce the memory problem, so I can report this as a bug. It will take some time for the memory usage to build up. Then I will try to run the code in Grass57.

--
--------------------------------------------
Dr. Sander P. Oom
Animal, Plant and Environmental Sciences,
University of the Witwatersrand
Private Bag 3, Wits 2050, South Africa
Tel (work) +27 (0)11 717 64 04
Tel (home) +27 (0)18 297 44 51
Fax +27 (0)18 299 24 64
Email sander@oomvanlieshout.net
Web www.oomvanlieshout.net/sander
---------------------------------------------

2

On Friday 11 March 2005 04:48, Sander Oom wrote:
[...]

http://www.oomvanlieshout.net/ftp/d3.png
http://www.oomvanlieshout.net/ftp/landcover.png

The d3 map seems to have three layers, but I can not figure out what
they mean. There seems to be some sensible information in the
background, but that is over ruled by the square pattern.

why do you think d3 has three layers? To receive information concerning the
colour patterns just use d.legend.
The square pattern is caused by your sampling unit setup in r.le.setup - you
can choose circle or square and their size. If you set the sampling unit to a
smaller size (and to circles) your square pattern might dissappear.

cheers Martin

3

Dear Martin,

I was viewing the raster in QGIS and the viewer offered three bands. However, the raster is indeed only a single band. This is the first time I seriously use Grass and Qgis!

The output map still does not make sense thought, and IMHO it is wrong.

A moving window analysis calculates a statistic for a certain window, puts the value of the statistic in the center cell of the window and then moves on cell up. Then the whole process repeats.

Thus the resulting map should show gradual changes in the statistic, as the moving window moved across the map. As the window moves a cell each time, the statistic is slightly changed by a new row of cells included in the window. This has to go gradually and should not show sharp edge!!

The resulting map should show gradual changes, independent of the shape of the window. The shape and size of the window will determine how gradual the changes are, i.e. autocorrelation will increase with increasing window size.

Running r.le.pixel on a slightly larger map showed dominance values in NODATA areas of the original map. Another tell tale sign something is wrong.

The ultimate aim is to run the moving window and then rescale to a larger cell size. The larger cell size used is the same as the moving window size!

Please correct me if I have completely misunderstood the methodology!?

Cheers,

Sander.

Martin Wegmann wrote:

On Friday 11 March 2005 04:48, Sander Oom wrote:
[...]

http://www.oomvanlieshout.net/ftp/d3.png
http://www.oomvanlieshout.net/ftp/landcover.png

The d3 map seems to have three layers, but I can not figure out what
they mean. There seems to be some sensible information in the
background, but that is over ruled by the square pattern.

why do you think d3 has three layers? To receive information concerning the colour patterns just use d.legend. The square pattern is caused by your sampling unit setup in r.le.setup - you can choose circle or square and their size. If you set the sampling unit to a smaller size (and to circles) your square pattern might dissappear.

cheers Martin

--
--------------------------------------------
Dr. Sander P. Oom
Animal, Plant and Environmental Sciences,
University of the Witwatersrand
Private Bag 3, Wits 2050, South Africa
Tel (work) +27 (0)11 717 64 04
Tel (home) +27 (0)18 297 44 51
Fax +27 (0)18 299 24 64
Email sander@oomvanlieshout.net
Web www.oomvanlieshout.net/sander
---------------------------------------------

4

Hello Sander,

On Friday 11 March 2005 06:32, Sander Oom wrote:

The output map still does not make sense thought, and IMHO it is wrong.

hmm, hard to tell where the problem lies - have you tried to compute b1,d1
etc. as well (as far as I understood r.le.pixel it does not take longer to
compute more indices) -- just to check if the senseless pattern persists.

A moving window analysis calculates a statistic for a certain window,
puts the value of the statistic in the center cell of the window and
then moves on cell up. Then the whole process repeats.

I think you understood it right but just to check, the calculated statistics
for the window is put into the corresponding centre cell of a new (!) raster
images, the values in the base image never change.

Thus the resulting map should show gradual changes in the statistic, as
the moving window moved across the map. As the window moves a cell each
time, the statistic is slightly changed by a new row of cells included
in the window. This has to go gradually and should not show sharp edge!!

yes, but if your base image has sharp edges it will result in sharp dominance
edges as well. As far as I can just your landcover.png it is classified and
hence there might be sharp edges.

Running r.le.pixel on a slightly larger map showed dominance values in
NODATA areas of the original map. Another tell tale sign something is
wrong.

this sounds like a problem which I encountered before, I discussed it with
Baker (the author of r.le) and send him a few error logs/images, but I
haven't traced this problem anymore since then.

The ultimate aim is to run the moving window and then rescale to a
larger cell size. The larger cell size used is the same as the moving
window size!

Why you want to do that? The pixel value holds already the statistics of the
larger cell size. If you rescale the cell size than you include values of a
even larger area due to the moving window size.

hope I understood you right and could help at least a bit, cheers, Martin

Martin Wegmann wrote:
> On Friday 11 March 2005 04:48, Sander Oom wrote:
> [...]
>
>>http://www.oomvanlieshout.net/ftp/d3.png
>>http://www.oomvanlieshout.net/ftp/landcover.png
>>
>>The d3 map seems to have three layers, but I can not figure out what
>>they mean. There seems to be some sensible information in the
>>background, but that is over ruled by the square pattern.
>
> why do you think d3 has three layers? To receive information concerning
> the colour patterns just use d.legend.
> The square pattern is caused by your sampling unit setup in r.le.setup -
> you can choose circle or square and their size. If you set the sampling
> unit to a smaller size (and to circles) your square pattern might
> dissappear.
>
> cheers Martin

--
Martin Wegmann

DLR - German Aerospace Center
German Remote Sensing Data Center
@
Dept.of Geography
Remote Sensing and Biodiversity Unit
University of Wuerzburg
Am Hubland
97074 Würzburg

phone: +49-(0)931 - 888 4797
fax: +49-(0)931 - 888 4961
http://www.biota-africa.org
http://www.biogis.de

5

r.le documentation from GRASS 5.4 has not yet been incorporated into the
6.0 manuals.

Look in the 5.4 help pages for *much* more info on r.le.*:

  http://grass.ibiblio.org/gdp/html_grass5/raster.html

(start with the r.le.setup help page)

Hamish

6

I read the manual files and the pdf
(http://grass.ibiblio.org/gdp/landscape/r_le_manual5.pdf) before and
after running theb , but nowhere is there a mention of erratic values
in NODATA areas. There is no mention of the program exiting with a
memory allocation error and there is no explanation on what the
output for a dominance analysis should look like.

Is there any place in the manual in particular I should look at? I
read it *again*, but still found no answer to my questions.

I know there is much more information in the manual, just not the
information I have been looking for.

Sorry, I don't know much of anything about the module, I just noticed
that most of the documentation had not been merged into the new help
page.

The erratics in NODATA areas, I have no idea. Maybe a bug, maybe input
the program doesn't expect. Never properly updated for null support?

The memory problem could be solved with a debugger (like gdb) &/or a
memory profiler (like electric fence or valgrind). A C programmer or
someone familiar with UNIX might be required. Straight bug I think.

output for dominance analysis if undocumented might be best determined
by looking at the source code.

Hopefully someone out there uses these modules and can help...

Hamish