thanks for the answer and the examples. I'll try to put the functions and files
in this format and test them like that.I am not sure how to build these
makefile files but I'll try to follow the patterns I find in the other examples
of modules.Once this is done, I'll post it here.
Which GRASS version I should use to do that?
Regarding the comparison with the other GRASS tools, LSMetrics is complementary
to many of the functions the r.li suite offers. I still could not test r.pi
since I had some trouble installing it, but I'll try it again so that I can
compare both packages. I believe they are also somehow complementary in many of
Em quarta-feira, 7 de fevereiro de 2018 13:15:03 BRST, Moritz Lennert
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:
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:
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
To get an idea of the structure of a suite of modules in Addons, you
could look at the recently added r.sentinel tools:
grass-user mailing list