Re: LSMetrics - addon development

Moritz Lennert <[email protected]>
Newsgroups gmane.comp.gis.grass.user
Message-ID <[email protected]>
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
_______________________________________________
grass-user mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/grass-user
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.