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

[Hamish]

[r.le.setup]

Hamish wrote:
> 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

Patrick:
> OK I will do it asap. However I don't know how to insert the new code
> practically from the script given
....
> 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...

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.

> (I am using R and grass but I am not a C developper)...

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.

> Actually I am a landscape ecologist and R programmer.

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.

> 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 ? 

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:
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

Patrick:
> Sorry for your virus mishappenings... 
....
> but took 15 days to solve the trouble.

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.


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

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.

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

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



      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping