[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