[GRASS-user] LSMetrics - addon development

Moritz Lennert mlennert at club.worldonline.be
Wed Feb 7 07:14:52 PST 2018


Dear Bernardo,

On 07/02/18 14:55, Bernardo Santos wrote:
> Dear list,
> 
> We have been developing a python application called LSMetrics to 
> calculate landscape metrics for environmental management and ecological 
> research. All functions/metrics use GRASS modules in the process of 
> calculation. More information here:
> https://github.com/LEEClab/LS_METRICS/wiki

Great, thanks !

Out of curiosity: could you maybe explain how this application compares 
to the existing r.li suite of modules in GRASS core 
(https://grass.osgeo.org/grass74/manuals/r.li.html) and the r.pi suite 
of modules in GRASS addons (there seems to be a problem with building 
the manual pages, but you can get an idea by looking at the 
description.html file here: 
https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.pi) ? 
I am no expert in the field of landscape metrics and am just wondering 
how this all fits into the picture.

> 
> Basically we have several python functions, each of which calculates a 
> different metric. All of them are then called by a single function that 
> can coordinate the calculation of several metrics for several maps in a row.
> Currently the metrics can be calculated for input maps using a grafical 
> interface (we call it from the GRASS shell using "python 
> LS_metrics_v1_0_0.py") or by calling python shell from the GRASS shell 
> and then using python scripting to call the functions (importing 
> functions and then calling them directly). We wish to transform these 
> function into one (or more than one) grass addon.
> 
> Then I have two questions:
> - Do you think it would be better to build a single addon (e.g. called 
> r.ls.metrics) so that each metrics is defined by a parameter (e.g. 
> method = "patch_size", "fragment_size", "structural connectivity" ...), 
> or rather a set of addons, each one corresponding to a single landscape 
> metrics (e.g. r.ls.patch_size, r.ls.fragment_size, ...)?

The other two suites have gone for separate modules for each metric. I'm 
not sure what the rationale was behind that choice, but I guess we 
should try to be consistent across similar module suites.

> 
> - Also, I have looked on how to build the addon in GRASS help pages but 
> I am not sure about some details. Can you send me some references to 
> ease that process?

The basic idea for a module for addons is to create a directory with the 
source file(s), the html file for the manual page and a Makefile.

Please follow the general submitting rules as explained at 
https://trac.osgeo.org/grass/wiki/Submitting.

To get an idea of the structure of a suite of modules in Addons, you 
could look at the recently added r.sentinel tools: 
https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.sentinel

Moritz


More information about the grass-user mailing list