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