<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=iso-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hamish wrote:
<blockquote cite="mid:428866.56650.qm@web45815.mail.sp1.yahoo.com"
type="cite">
<pre wrap="">[r.le.setup]
Hamish wrote:
</pre>
<blockquote type="cite">
<pre wrap="">bug found and fixed in 6.3 svn. The logic around the >100 check was
to blame. Thanks for pin-pointing it.
</pre>
</blockquote>
<pre wrap=""><!----><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>
Patrick:
</pre>
<blockquote type="cite">
<pre wrap="">OK I will do it asap. However I don't know how to insert the new code
practically from the script given
</pre>
</blockquote>
<pre wrap=""><!---->....
</pre>
<blockquote type="cite">
<pre wrap="">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...
</pre>
</blockquote>
<pre wrap=""><!---->
You can get a patch from the above link. Click on the 'View Changes'
button, then the 'Unified diff' link. Or from the changes page just see
how to edit sample.c by hand.
</pre>
<blockquote type="cite">
<pre wrap="">(I am using R and grass but I am not a C developper)...
</pre>
</blockquote>
<pre wrap=""><!---->
You don't have to know any C to apply the patch, nor much C to
understand the change. Simply knowing if{;} else{;} syntax and how to
/* comment out lines */ is enough to start tinkering with the code.
In this case the "else" part was only run if the radius was under 100,
instead of being run after radius of any size was accepted.
</pre>
<blockquote type="cite">
<pre wrap="">Actually I am a landscape ecologist and R programmer.
</pre>
</blockquote>
<pre wrap=""><!---->
Well FWIW, I'm actually an engineer and oceanographer in a place
dominated by smart marine biologists and ecologists. I think only a
couple of grass developers are real programmers, and their ongoing
patience with the rest continues to amaze me.
</pre>
<blockquote type="cite">
<pre wrap="">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 ?
</pre>
</blockquote>
<pre wrap=""><!---->
The fix has been applied in 6.3-svn, not CVS. In the last weeks GRASS
has migrated from CVS to a new SVN source code repository at OSgeo.
Sorry the source code snapshot links on the website are currently out
of date, check a recent post by Markus on the grass-dev mailing list
for a SVN-snapshot link. I am done trying to do source code commits
from the road, so someone else will have to update that or wait for me
to get back to the office.
Here is a link to the unidiff if you don't mind patches:
<a class="moz-txt-link-freetext" href="http://trac.osgeo.org/grass/changeset?format=diff&new=29503&old=29458&new_path=grass%2Ftrunk%2Fraster%2Fr.le%2Fr.le.setup%2Fsample.c&old_path=grass%2Ftrunk%2Fraster%2Fr.le%2Fr.le.setup%2Fsample.c">http://trac.osgeo.org/grass/changeset?format=diff&new=29503&old=29458&new_path=grass%2Ftrunk%2Fraster%2Fr.le%2Fr.le.setup%2Fsample.c&old_path=grass%2Ftrunk%2Fraster%2Fr.le%2Fr.le.setup%2Fsample.c</a>
Patrick:
</pre>
<blockquote type="cite">
<pre wrap="">Sorry for your virus mishappenings...
</pre>
</blockquote>
<pre wrap=""><!---->....
</pre>
<blockquote type="cite">
<pre wrap="">but took 15 days to solve the trouble.
</pre>
</blockquote>
<pre wrap=""><!---->
I guess my lesson is that there is no such thing as a "safe" MS Windows
machine, at least with any confidence. It wasn't a major infection or
anything, just some internet-explorer auto-installed spyware. It was
easily found and removed, but enough to spook me.
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
it is an easy edit of the r.neighbors source code if you want to make
that number more than 25.
but yes, there are modules to do this.
r.buffer + r.univar,
v.buffer + v.rast.stats
v.what.rast
.... more?
It might be nice for that to be built into r.le.* automatically, and
probably not that hard to do, but generally I would prefer if new
development went into r.li, and r.le only got bug fixes. I don't mind
simple niceties being added but it seems like wasted effort when r.li
is supposed to replace r.le. Of course it is open source so if someone
prefers to keep adding to r.le I'm not going to stop them or refuse
patches.
</pre>
<blockquote type="cite">
<pre wrap="">So, no real trouble with the doc, which looks fair enough.
</pre>
</blockquote>
<pre wrap=""><!---->
In general for bugs I would rather fix them than document them.
(but document the "it's a feature not bug" design choices)
regards,
Hamish
</pre>
</blockquote>
Dear Hamish,<br>
<br>
I have modified the code by hand (no patch used, indeed this was quite
easy...) and recompiled a cvs version. Everything works fine now in
r.le.setup with sample unit radius > 100. This gave me the
opportunity to see how the file system is organised in GRASS and may
encourage me to go further... Thanks for the incent !<br>
<br>
One question remains pending about r.li. It does not accept any circle
radius at the moment for some reasons (see the threat 'r.li.setup
trouble with circle').<br>
<br>
Regarding crude totals in sampling unit circles, I have written a
UNIX/GRASS 'pilot' programme which does what I need. I though it may
help other listers and thus you'll find the script below.<br>
<br>
Cheers,<br>
<br>
Patrick<br>
<br>
#!/bin/sh<br>
<br>
##########################################################################<br>
# Program to run within GRASS (this file must be copied into a
folder #<br>
# of the PATH). A circular buffer is created from each point
location #<br>
# of a vector file and it creates a text file of two
columns: #<br>
# col 1 = pixel value, col 2 = pixel count corresponding to this
value. #<br>
# Buffer results are separated by '$ $'. This file can be read
from #<br>
# e.g. R and formatted for user
purposes. #<br>
#
#<br>
# The programme shall be used on isometric projected
coordinates #<br>
# (UTM, Lambert, etc...) - the size of the buffer does not adapt
to #<br>
# geographical coordinates in
degrees. #<br>
#
#<br>
# Before running the programme, do not
forget: #<br>
# - to name the vector file (variable fichier=filename1, see
below) #<br>
# - to name the raster file (variable rast=filename2, see
below) #<br>
# - to give the buffer radius (in kilometres) (variable
radius=) #<br>
# #<br>
# By defaut results are found in a file whose name is the
name #<br>
# of the point file + the suffix
.txt #<br>
#
#<br>
# This program is just a prototype and few controls are really done.
For #<br>
# instance, users must make sure that point vector file and raster
file #<br>
# do overlap; null values are however
counted. #<br>
#
#<br>
# P. Giraudoux - version 28.12.2007
21:11:40 #<br>
##########################################################################<br>
<br>
if test "$GISBASE" = ""; then<br>
echo "You must be in GRASS to run this programme."<br>
exit<br>
fi<br>
<br>
fichier=chinaSP4 # name of the point file (vect)<br>
rast=dem3 # name of the raster file (rast)<br>
radius=100 # buffer radius (kilometers)<br>
<br>
resultat=$fichier.txt # name of the result file<br>
cote=`expr $radius \* 1000` # half of the length of the square edge of
the GRASS <br>
# region (in meters) where the buffers will
take place<br>
<br>
rm $resultat # remove an older file of the same name if any<br>
<br>
points=`v.info -t $fichier | grep 'points=' | cut -d= -f2` # number of
point locations<br>
<br>
count=0<br>
while [ $count -lt $points ]<br>
<br>
do<br>
count=`expr $count + 1`<br>
echo;echo<br>
echo $count/$points<br>
echo;echo<br>
g.remove MASK --q # remove mask if any (some troubles happened with
the new mask when not done)<br>
v.extract -t in=$fichier out=essais list=$count type=point --o --q
# point extraction<br>
<br>
# get point coordinates and setup the GRASS region at buffer size<br>
lat=`v.info -g essais | grep 'north=' | cut -d= -f2`<br>
long=`v.info -g essais | grep 'east=' | cut -d= -f2`<br>
<br>
nn=`echo "scale=2; $lat + $cote" | bc` # use bc for floating point
computing<br>
ns=`echo "scale=2; $lat - $cote" | bc`<br>
ne=`echo "scale=2; $long + $cote" | bc`<br>
nw=`echo "scale=2; $long - $cote" | bc`<br>
<br>
g.region n=$nn s=$ns e=$ne w=$nw # setup GRASS region<br>
#-----------------------------------------<br>
<br>
<br>
v.to.rast in=essais out=essais use=val type=point layer=1 value=1
--overwrite --q # convert the single point file into a raster<br>
r.buffer in=essais out=essais.buf distances=$radius
units=kilometers --overwrite --q # computes the buffer<br>
r.mask -o in=essais.buf maskcats=* --q # mask excluding the area
not in the buffer<br>
#d.erase<br>
#d.rast dem3<br>
r.stats -c $rast >> $resultat # adds the result at the end of
the result file<br>
echo "$ $" >> $resultat # buffer separator<br>
<br>
done<br>
<br>
g.remove MASK --q<br>
g.remove rast=essais --q<br>
g.remove rast=essais.buf --q<br>
g.remove vect=essais --q<br>
g.region rast=$rast<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>