[GRASS-user] Re: count pixels by attribute in sampling units

[Patrick Giraudoux]

Patton, Eric wrote:
> 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.
>   
Dear Eric,

To sum up:

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 !!!).

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.

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).

So, no real trouble with the doc, which looks fair enough.

Cheers,

Patrick






>
> -----Original Message-----
> From: grass-user-bounces at lists.osgeo.org on behalf of Patrick Giraudoux
> Sent: Thu 12/27/2007 4:17 AM
> To: Hamish
> Cc: grass-user at lists.osgeo.org; Clémentine Fritsch
> Subject: Re: [GRASS-user] Re: count pixels by attribute in sampling units
>  
>
>   
>> Hi,
>>
>> bug found and fixed in 6.3 svn. The logic around the >100 check was to
>> blame. Thanks for pin-pointing it.
>>
>> http://trac.osgeo.org/grass/log/grass/trunk/raster/r.le/r.le.setup/sample.c
>>
>> 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
>>
>>   
>>     
> 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 http://grass.itc.it/grass63/source/snapshot/, 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
>
>   

+++++++++++++++

Patrick Giraudoux wrote:

>> > > Doubts confirmed... Circles in r.le.setup may not reach the
>> > > expected size.
>>     
...

> > Complement: any radius > 100 gives inconsistent results in the
> > 'units' file of r.le.par:
> > 
> > /Thèse Fritsch/PrépaFragStat/grass$ cat r.le.para/units
> >          1    # of scales
> >          5    # of units of scale 1.
> > -1078225628-1217465035   u_w, u_l of units in scale 1
> >      100.5             radius of circles in scale 1
> >  539113457 608735128   left, top of unit[1]
> >  539113466 608734109   left, top of unit[2]
> >  539114864 608734976   left, top of unit[3]
> >  539115149 608733823   left, top of unit[4]
> >  539113914 608733783   left, top of unit[5]
> > 
> > When I use a shorter radius, I get:
> > 
> > grass > cat r.le.para/units
> >          1    # of scales
> >          5    # of units of scale 1.
> >         51        51   u_w, u_l of units in scale 1
> >       25.5             radius of circles in scale 1
> >        618      2586   left, top of unit[1]
> >        627      1567   left, top of unit[2]
> >       2025      2434   left, top of unit[3]
> >       2310      1281   left, top of unit[4]
> >       1075      1241   left, top of unit[5]
>   


Hi,

bug found and fixed in 6.3 svn. The logic around the >100 check was to
blame. Thanks for pin-pointing it.

http://trac.osgeo.org/grass/log/grass/trunk/raster/r.le/r.le.setup/sample.c

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-user/attachments/20071227/8668faa1/attachment.html