[GRASS-dev] Re: [GRASS5] r.li (landscape indices)

[Helena Mitasova]

Just a quick question:

is there any reason why there are some r.li modules named
like this (these would be the first module names that introduce  
capital letters):

r.li.patchAreaDistributionCV
r.li.patchAreaDistributionRANGE
r.li.contrastWeightedEdgeDensity

compared to this:

r.li.edgedensity (why not r.li.edgeDensity?)
r.li.patchnumber (r.li.patchNUMBER?)



Thanks,

Helena

P.S. Note, that if you use CLI and take advantage of name completion
you would still have to type entire r.li.patchAreaDistribution


Helena Mitasova
Dept. of Marine, Earth and Atm. Sciences
1125 Jordan Hall, NCSU Box 8208,
Raleigh NC 27695
http://skagit.meas.ncsu.edu/~helena/



On Jan 19, 2006, at 10:13 AM, Paolo Cavallini wrote:

> Hi all.
> We used r.le a lot, but we're not satisfied by its performances,  
> ease of use,
> and maintainability. A previous attempt at incorporating Fragstats  
> as a grass
> module (thanks Jachym!) revealed theat the code is not maintained very
> actively, and probably not worth the effort. Therefore, a couple of  
> students
> have produced an interesting new C module for grass, with a rather  
> different
> approach to the problem. It is not functional yet, but it has been  
> built with
> expandability in mind, so it should be straightforward to include new
> indices. I include here their note. It would be good if people  
> could see if
> the general structure and idea is ok, and help us completing it.
> You can download it from:
> http://www.faunalia.it/download/r.li.tar.gz
> Looking forward to hear from you.
> pc
> ===
> Hi again, we post a development version of our work about r.li module.
> The pourpose of this project is the parallel computing of focals index
> on raster maps or areas.
> It is based on sampling area definition of r.le but we tried to made a
> more upgradable module to make definition of index indipendent from
> areas definition management.
>
> We wrote two programs:
> 1 - r.li.setup: this program defines the sample areas for the analysis
> with a gui interface. It is based on sampling frame-  and sampling  
> area
> definition of r.le.setup, but it have two novelties: the first one  
> is the
> gui, and the second one the format of configuration file that is
> raster-indipendent. It means that you can define an area configuration
> file on a raster map and use the same file on another map (the
> dimension are saved in relative coordinates).
> See the description file for more explanations.
>
> 2 - r.li.daemon is a client-server architecture that manage the
> parallel computing of index on the areas defined by the configuration
> file. It is a little long to explain but we'll try with few words.
> The server reads the configuration file and build a list of areas,  
> then
> create a group of clients and send an area to everyone of this. The
> clients calculates the index (it is passed with a function pointer)  
> and
> then returns the result to the server. Then the server stores the
> result in a file (or on a raster in moving window mode that is under
> development).
> In this way a new index have only to take care of an area (defined  
> with
> a rectangle and a mask) and can be written only defining the C
> function. To create a new index then you have only to copy the main
> program and change the simple index with your index and pass your
> function calling the calculateIndex function... We hope it will be
> useful.
> Please send comments or suggestions...
>
> Davide Spano, Claudio Porta University of Pisa
> -- 
> Paolo Cavallini
> email+jabber: cavallini at faunalia.it
> www.faunalia.it
> Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy   Tel: (+39) 
> 348-3801953
>
> _______________________________________________
> grass5 mailing list
> grass5 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
>