<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Patton, Eric wrote:
<blockquote
cite="mid:CA803441152AAE40935609509953BAD201075F20@s0-ott-x4.nrn.nrcan.gc.ca"
type="cite">
<pre wrap="">Hi Patrick,
I haven't been following the thread very closely, but if you think you have discovered some undocumented features or oddities through your trials with r.le*, could you give me some suggestions on how to improve the docs if you have a chance?
Thanks,
~ Eric.
</pre>
</blockquote>
Dear Eric,<br>
<br>
To sum up:<br>
<br>
1/ There was a bug about defining circle sampling units > 100 pixels
in r.le.setup. Looks like Hamish has solved it just before leaving but
he asked me to take a trial (see copy below). However, I don't know how
to insert the C code in a GRASS working version (I can manage with a
patch and a cvs version since recent only... Actually I am a landscape
ecologist and R programmer. From Hamish's well readable and commented
code it is tempting to go a step forward to C... but time is lacking
!!!).<br>
<br>
2/ Regarding r.le*, it would be nice to get simple and quick reports on
sampling unit composition (e.g. number of pixels of each attribute
category, mean, min, max, etc. e.g. the same as for r.neighbors)
without going straight to time-consuming shape analysis. Indeed,
classical neighborhood analysis is limited to 25 pixels in GRASS and
there are many cases where statistics on larger sampling units are
needed. It may be that such simple statistics on sampling units can be
obtained with other GRASS functions, but I cannot find one throughout
books and threads on the web... and no feed back yet on this on the
GRASS list.<br>
<br>
3/ Regarding pixel counts, I have found a work around when attribute
categories are not many (here to take each category as a group and use
att=a5). It would not be possible (or at least it would be extremely
combersome) to do the same when it is real numbers (eg. altitudes in a
dem).<br>
<br>
So, no real trouble with the doc, which looks fair enough.<br>
<br>
Cheers,<br>
<br>
Patrick<br>
<br>
<br>
<br>
<br>
<br>
<br>
<blockquote
cite="mid:CA803441152AAE40935609509953BAD201075F20@s0-ott-x4.nrn.nrcan.gc.ca"
type="cite">
<pre wrap="">
-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:grass-user-bounces@lists.osgeo.org">grass-user-bounces@lists.osgeo.org</a> on behalf of Patrick Giraudoux
Sent: Thu 12/27/2007 4:17 AM
To: Hamish
Cc: <a class="moz-txt-link-abbreviated" href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a>; Clémentine Fritsch
Subject: Re: [GRASS-user] Re: count pixels by attribute in sampling units
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
bug found and fixed in 6.3 svn. The logic around the >100 check was to
blame. Thanks for pin-pointing it.
<a class="moz-txt-link-freetext" href="http://trac.osgeo.org/grass/log/grass/trunk/raster/r.le/r.le.setup/sample.c">http://trac.osgeo.org/grass/log/grass/trunk/raster/r.le/r.le.setup/sample.c</a>
I haven't tested the fix, but it should work. If it works for you can
you post to this list with the result? It should then be safe to
backport to the release branches. I am traveling right now so would ask
someone else to commit that- I left my knoppix/ubuntu CDs at home and
after a spyware infection scare yesterday (apparently stopped by the
outgoing firewall) on a very well maintained WinXP PC, I am a rather
concerned about ssh'ing into our server (& then to osgeo SVN) from any
MS Windows machine ever ever ever again.
Hamish
</pre>
</blockquote>
<pre wrap=""><!---->OK I will do it asap. However I don't know how to insert the new code
practically from the script given (I am using R and grass but I am not a
C developper)... Has it been inserted in the last cvs version (guess not
from your mail) at <a class="moz-txt-link-freetext" href="http://grass.itc.it/grass63/source/snapshot/">http://grass.itc.it/grass63/source/snapshot/</a>, or any
other way ?
Sorry for your virus mishappenings... I had one in August 2006, and I
could not get rid of it, even with the local computer ingineer... Ended
up erasing the hard disk and reformating. Fortunately I had a safe copy
but took 15 days to solve the trouble.
Cheers,
Patrick
</pre>
</blockquote>
<br>
+++++++++++++++<br>
<pre wrap="">Patrick Giraudoux wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""><span class="moz-txt-citetags">> > </span>Doubts confirmed... Circles in r.le.setup may not reach the
<span class="moz-txt-citetags">> > </span>expected size.
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->...
</pre>
<blockquote type="cite">
<pre wrap=""><span class="moz-txt-citetags">> </span>Complement: any radius > 100 gives inconsistent results in the
<span class="moz-txt-citetags">> </span>'units' file of r.le.par:
<span class="moz-txt-citetags">> </span>
<span class="moz-txt-citetags">> </span>/Thèse Fritsch/PrépaFragStat/grass$ cat r.le.para/units
<span class="moz-txt-citetags">> </span> 1 # of scales
<span class="moz-txt-citetags">> </span> 5 # of units of scale 1.
<span class="moz-txt-citetags">> </span>-1078225628-1217465035 u_w, u_l of units in scale 1
<span class="moz-txt-citetags">> </span> 100.5 radius of circles in scale 1
<span class="moz-txt-citetags">> </span> 539113457 608735128 left, top of unit[1]
<span class="moz-txt-citetags">> </span> 539113466 608734109 left, top of unit[2]
<span class="moz-txt-citetags">> </span> 539114864 608734976 left, top of unit[3]
<span class="moz-txt-citetags">> </span> 539115149 608733823 left, top of unit[4]
<span class="moz-txt-citetags">> </span> 539113914 608733783 left, top of unit[5]
<span class="moz-txt-citetags">> </span>
<span class="moz-txt-citetags">> </span>When I use a shorter radius, I get:
<span class="moz-txt-citetags">> </span>
<span class="moz-txt-citetags">> </span>grass > cat r.le.para/units
<span class="moz-txt-citetags">> </span> 1 # of scales
<span class="moz-txt-citetags">> </span> 5 # of units of scale 1.
<span class="moz-txt-citetags">> </span> 51 51 u_w, u_l of units in scale 1
<span class="moz-txt-citetags">> </span> 25.5 radius of circles in scale 1
<span class="moz-txt-citetags">> </span> 618 2586 left, top of unit[1]
<span class="moz-txt-citetags">> </span> 627 1567 left, top of unit[2]
<span class="moz-txt-citetags">> </span> 2025 2434 left, top of unit[3]
<span class="moz-txt-citetags">> </span> 2310 1281 left, top of unit[4]
<span class="moz-txt-citetags">> </span> 1075 1241 left, top of unit[5]
</pre>
</blockquote>
<pre wrap=""><!---->
Hi,
bug found and fixed in 6.3 svn. The logic around the >100 check was to
blame. Thanks for pin-pointing it.
<a class="moz-txt-link-freetext"
href="http://trac.osgeo.org/grass/log/grass/trunk/raster/r.le/r.le.setup/sample.c">http://trac.osgeo.org/grass/log/grass/trunk/raster/r.le/r.le.setup/sample.c</a>
I haven't tested the fix, but it should work. If it works for you can
you post to this list with the result? It should then be safe to
backport to the release branches. I am traveling right now so would ask
someone else to commit that- I left my knoppix/ubuntu CDs at home and
after a spyware infection scare yesterday (apparently stopped by the
outgoing firewall) on a very well maintained WinXP PC, I am a rather
concerned about ssh'ing into our server (& then to osgeo SVN) from any
MS Windows machine ever ever ever again.
Hamish
</pre>
<br>
</body>
</html>