Re: [GRASS-user] LSMetrics - addon development

2018-02-16 Thread Markus Metz 
On Fri, Feb 16, 2018 at 10:05 AM, Markus Neteler  wrote:
>
> On Fri, Feb 16, 2018 at 9:42 AM, Markus Metz
>  wrote:
> ...
> > I can't reproduce with your compiler flags. A wild guess: in draw.c:L3
try
> > to replace inline with static
>
> Yes, this helps. I didn't submit the change, will you do that?

done in r72247

Markus M
>
> markusN
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] LSMetrics - addon development

2018-02-16 Thread Markus Neteler 
On Fri, Feb 16, 2018 at 9:42 AM, Markus Metz
 wrote:
...
> I can't reproduce with your compiler flags. A wild guess: in draw.c:L3 try
> to replace inline with static

Yes, this helps. I didn't submit the change, will you do that?

markusN
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] LSMetrics - addon development

2018-02-16 Thread Markus Metz 
On Thu, Feb 15, 2018 at 10:38 PM, Markus Neteler  wrote:
>
> On Thu, Feb 15, 2018 at 7:49 PM, Markus Metz
>  wrote:
> >
> >
> > On Thu, Feb 15, 2018 at 5:57 PM, Markus Neteler 
wrote:
> >>
> >> On Thu, Feb 15, 2018 at 5:43 PM, Moritz Lennert
> >>  wrote:
> >> > On 12/02/18 18:01, Bernardo Santos wrote:
> >> ...
> >> >> 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 the functions.
> >> >
> >> >
> >> > Yes, r.pi installation is still an issue.
> >>
> >> I have probably fixed it in r72243. Please try.
> >>
> >> But: I get this compilation error (probably easy to fix but I have no
> >> time right now):
> >>
> >> [mneteler@oboe r.pi.library ]$ make MODULE_TOPDIR=~/software/grass74
> >> gcc -shared -o
> >> /home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib/
libgrass_rpi.7.4.1svn.so
> >> -L/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib
> >> -L/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib
> >> -Wl,--no-undefined -Wl,-z,now -Wl,--export-dynamic
> >>
> >>
-Wl,-rpath-link,/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib
> >> -Wl,-soname,libgrass_rpi.7.4.1svn.so OBJ.x86_64-pc-linux-gnu/draw.o
> >> OBJ.x86_64-pc-linux-gnu/frag.o OBJ.x86_64-pc-linux-gnu/helpers.o
> >> OBJ.x86_64-pc-linux-gnu/stat_method.o  -lgrass_gis.7.4.1svn -lm  -lm
> >> OBJ.x86_64-pc-linux-gnu/draw.o: In function `draw_line':
> >>
> >>
/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:38:
> >> undefined reference to `swap'
> >>
> >>
/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:39:
> >> undefined reference to `swap'
> >>
> >>
/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:43:
> >> undefined reference to `swap'
> >>
> >>
/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:44:
> >> undefined reference to `swap'
> >> collect2: error: ld returned 1 exit status
> >> make: *** [/home/mneteler/software/grass74/include/Make/Shlib.make:10:
> >>
> >> /home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib/
libgrass_rpi.7.4.1svn.so]
> >> Error 1
> >
> > swap is in draw.c L3-9
>
>
> Yes, I saw that - quite confusing that it does not compile (Fedora 27):
>
> > I can not reproduce this error. Do you have any changes in your local
copy?
>
> all clean and shiny
>
> > Maybe also try make clean, then make again, because
>
> yes done. So I get:
>
> [mneteler@oboe r.pi ]$ make MODULE_TOPDIR=~/software/grass74
> make -C r.pi.library || echo
> /home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library
> >> /home/mneteler/software/grass74/error.log
> make[1]: Entering directory
> '/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library'
> test -d OBJ.x86_64-pc-linux-gnu || mkdir -p OBJ.x86_64-pc-linux-gnu
> gcc  -g -Wall -Wshadow -Wlogical-op
> -Werror-implicit-function-declaration -fPIC -fno-common -fexceptions
> -Wextra -Wunused -Waggressive-loop-optimizations -Wreturn-type
> -Wfatal-errors -march=native -std=gnu99 -fexceptions -fstack-protector
> -m64   -fPIC
 -I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
> -I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
> -DPACKAGE=\""grasslibs"\"
> -I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
> -I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
>
-DRELDIR=\"/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library\"
> -o OBJ.x86_64-pc-linux-gnu/draw.o -c draw.c
> draw.c: In function ‘draw_point’:
> draw.c:11:62: warning: unused parameter ‘sy’ [-Wunused-parameter]
>  void draw_point(int *map, int val, int x, int y, int sx, int sy, int
width)
>   ^~
> gcc  -g -Wall -Wshadow -Wlogical-op
> -Werror-implicit-function-declaration -fPIC -fno-common -fexceptions
> -Wextra -Wunused -Waggressive-loop-optimizations -Wreturn-type
> -Wfatal-errors -march=native -std=gnu99 -fexceptions -fstack-protector
> -m64   -fPIC
 -I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
> -I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
> -DPACKAGE=\""grasslibs"\"
> -I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
> -I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
>
-DRELDIR=\"/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library\"
> -o OBJ.x86_64-pc-linux-gnu/frag.o -c frag.c
> gcc  -g -Wall -Wshadow -Wlogical-op
> -Werror-implicit-function-declaration -fPIC -fno-common -fexceptions
> -Wextra -Wunused -Waggressive-loop-optimizations

Re: [GRASS-user] LSMetrics - addon development

2018-02-15 Thread Markus Neteler 
On Thu, Feb 15, 2018 at 7:49 PM, Markus Metz
 wrote:
>
>
> On Thu, Feb 15, 2018 at 5:57 PM, Markus Neteler  wrote:
>>
>> On Thu, Feb 15, 2018 at 5:43 PM, Moritz Lennert
>>  wrote:
>> > On 12/02/18 18:01, Bernardo Santos wrote:
>> ...
>> >> 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 the functions.
>> >
>> >
>> > Yes, r.pi installation is still an issue.
>>
>> I have probably fixed it in r72243. Please try.
>>
>> But: I get this compilation error (probably easy to fix but I have no
>> time right now):
>>
>> [mneteler@oboe r.pi.library ]$ make MODULE_TOPDIR=~/software/grass74
>> gcc -shared -o
>> /home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib/libgrass_rpi.7.4.1svn.so
>> -L/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib
>> -L/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib
>> -Wl,--no-undefined -Wl,-z,now -Wl,--export-dynamic
>>
>> -Wl,-rpath-link,/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib
>> -Wl,-soname,libgrass_rpi.7.4.1svn.so OBJ.x86_64-pc-linux-gnu/draw.o
>> OBJ.x86_64-pc-linux-gnu/frag.o OBJ.x86_64-pc-linux-gnu/helpers.o
>> OBJ.x86_64-pc-linux-gnu/stat_method.o  -lgrass_gis.7.4.1svn -lm  -lm
>> OBJ.x86_64-pc-linux-gnu/draw.o: In function `draw_line':
>>
>> /home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:38:
>> undefined reference to `swap'
>>
>> /home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:39:
>> undefined reference to `swap'
>>
>> /home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:43:
>> undefined reference to `swap'
>>
>> /home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:44:
>> undefined reference to `swap'
>> collect2: error: ld returned 1 exit status
>> make: *** [/home/mneteler/software/grass74/include/Make/Shlib.make:10:
>>
>> /home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib/libgrass_rpi.7.4.1svn.so]
>> Error 1
>
> swap is in draw.c L3-9


Yes, I saw that - quite confusing that it does not compile (Fedora 27):

> I can not reproduce this error. Do you have any changes in your local copy?

all clean and shiny

> Maybe also try make clean, then make again, because

yes done. So I get:

[mneteler@oboe r.pi ]$ make MODULE_TOPDIR=~/software/grass74
make -C r.pi.library || echo
/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library
>> /home/mneteler/software/grass74/error.log
make[1]: Entering directory
'/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library'
test -d OBJ.x86_64-pc-linux-gnu || mkdir -p OBJ.x86_64-pc-linux-gnu
gcc  -g -Wall -Wshadow -Wlogical-op
-Werror-implicit-function-declaration -fPIC -fno-common -fexceptions
-Wextra -Wunused -Waggressive-loop-optimizations -Wreturn-type
-Wfatal-errors -march=native -std=gnu99 -fexceptions -fstack-protector
-m64   -fPIC  -I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-DPACKAGE=\""grasslibs"\"
-I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-DRELDIR=\"/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library\"
-o OBJ.x86_64-pc-linux-gnu/draw.o -c draw.c
draw.c: In function ‘draw_point’:
draw.c:11:62: warning: unused parameter ‘sy’ [-Wunused-parameter]
 void draw_point(int *map, int val, int x, int y, int sx, int sy, int width)
  ^~
gcc  -g -Wall -Wshadow -Wlogical-op
-Werror-implicit-function-declaration -fPIC -fno-common -fexceptions
-Wextra -Wunused -Waggressive-loop-optimizations -Wreturn-type
-Wfatal-errors -march=native -std=gnu99 -fexceptions -fstack-protector
-m64   -fPIC  -I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-DPACKAGE=\""grasslibs"\"
-I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-DRELDIR=\"/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library\"
-o OBJ.x86_64-pc-linux-gnu/frag.o -c frag.c
gcc  -g -Wall -Wshadow -Wlogical-op
-Werror-implicit-function-declaration -fPIC -fno-common -fexceptions
-Wextra -Wunused -Waggressive-loop-optimizations -Wreturn-type
-Wfatal-errors -march=native -std=gnu99 -fexceptions -fstack-protector
-m64   -fPIC  -I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-DPACKAGE=\""grasslibs"\"

Re: [GRASS-user] LSMetrics - addon development

2018-02-15 Thread Markus Metz 
On Thu, Feb 15, 2018 at 5:57 PM, Markus Neteler  wrote:
>
> On Thu, Feb 15, 2018 at 5:43 PM, Moritz Lennert
>  wrote:
> > On 12/02/18 18:01, Bernardo Santos wrote:
> ...
> >> 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 the functions.
> >
> >
> > Yes, r.pi installation is still an issue.
>
> I have probably fixed it in r72243. Please try.
>
> But: I get this compilation error (probably easy to fix but I have no
> time right now):
>
> [mneteler@oboe r.pi.library ]$ make MODULE_TOPDIR=~/software/grass74
> gcc -shared -o
/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib/
libgrass_rpi.7.4.1svn.so
> -L/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib
> -L/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib
> -Wl,--no-undefined -Wl,-z,now -Wl,--export-dynamic
>
-Wl,-rpath-link,/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib
> -Wl,-soname,libgrass_rpi.7.4.1svn.so OBJ.x86_64-pc-linux-gnu/draw.o
> OBJ.x86_64-pc-linux-gnu/frag.o OBJ.x86_64-pc-linux-gnu/helpers.o
> OBJ.x86_64-pc-linux-gnu/stat_method.o  -lgrass_gis.7.4.1svn -lm  -lm
> OBJ.x86_64-pc-linux-gnu/draw.o: In function `draw_line':
>
/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:38:
> undefined reference to `swap'
>
/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:39:
> undefined reference to `swap'
>
/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:43:
> undefined reference to `swap'
>
/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:44:
> undefined reference to `swap'
> collect2: error: ld returned 1 exit status
> make: *** [/home/mneteler/software/grass74/include/Make/Shlib.make:10:
> /home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib/
libgrass_rpi.7.4.1svn.so]
> Error 1

swap is in draw.c L3-9

I can not reproduce this error. Do you have any changes in your local copy?
Maybe also try make clean, then make again, because

[mneteler@oboe r.pi.library ]$ make MODULE_TOPDIR=~/software/grass74

should produce a lot more output.

Markus M

>
> Then g.extension will probably work with r.pi.
>
> Markus
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] LSMetrics - addon development

2018-02-15 Thread Markus Neteler 
On Thu, Feb 15, 2018 at 5:43 PM, Moritz Lennert
 wrote:
> On 12/02/18 18:01, Bernardo Santos wrote:
...
>> 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 the functions.
>
>
> Yes, r.pi installation is still an issue.

I have probably fixed it in r72243. Please try.

But: I get this compilation error (probably easy to fix but I have no
time right now):

[mneteler@oboe r.pi.library ]$ make MODULE_TOPDIR=~/software/grass74
gcc -shared -o 
/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib/libgrass_rpi.7.4.1svn.so
-L/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib
-L/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib
-Wl,--no-undefined -Wl,-z,now -Wl,--export-dynamic
-Wl,-rpath-link,/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib
-Wl,-soname,libgrass_rpi.7.4.1svn.so OBJ.x86_64-pc-linux-gnu/draw.o
OBJ.x86_64-pc-linux-gnu/frag.o OBJ.x86_64-pc-linux-gnu/helpers.o
OBJ.x86_64-pc-linux-gnu/stat_method.o  -lgrass_gis.7.4.1svn -lm  -lm
OBJ.x86_64-pc-linux-gnu/draw.o: In function `draw_line':
/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:38:
undefined reference to `swap'
/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:39:
undefined reference to `swap'
/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:43:
undefined reference to `swap'
/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:44:
undefined reference to `swap'
collect2: error: ld returned 1 exit status
make: *** [/home/mneteler/software/grass74/include/Make/Shlib.make:10:
/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib/libgrass_rpi.7.4.1svn.so]
Error 1

Then g.extension will probably work with r.pi.

Markus
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] LSMetrics - addon development

2018-02-15 Thread Moritz Lennert 

On 12/02/18 18:01, Bernardo Santos wrote:

Dear Moritz,

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?


You should probably do it with trunk, but 7.4 is also ok as the two are 
not far from each other.




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 the functions.


Yes, r.pi installation is still an issue. Currently it does not seem 
configured in a way to be usable by g.extension.


Assuming you are on a *nix like system, the easiest is to download the 
entire r.pi directory from SVN 
(https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.pi?rev=72241=zip), 
unzip it somewhere on your system, cd to the r.pi directory and then 
compile it with


make MODULE_TOPDIR=~/SRC/GRASS/grass_trunk/

where you replace ~/SRC/GRASS/grass_trunk

with the path to your GRASS source code (again 7.4 is ok, and 7.2 
probably also).


Moritz

___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] LSMetrics - addon development

2018-02-12 Thread Bernardo Santos 
 Dear Moritz, 
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 
the functions.
Best,Bernardo


Em quarta-feira, 7 de fevereiro de 2018 13:15:03 BRST, Moritz Lennert 
 escreveu:  
 
 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
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] LSMetrics - addon development

2018-02-07 Thread Moritz Lennert 

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
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] LSMetrics - addon development

2018-02-07 Thread Bernardo Santos 
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

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, ...)?
- 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?
Thanks a lot. Below you can find more information regarding the 
metrics.BestBernardo Niebuhr
_
Metrics calculated:Metrics related to structural connectivity:- patch size- 
fragment size (excludes corridors with a given edge depth)- structural 
connectivity- proportion of habitat (within a window around each pixel)Metrics 
related to functional connectivity- functionally connected area (considering 
the capacity of organisms to cross gaps between habitat patches)- functional 
connectivityMetrics related to habitat edges- distance from edges- 
clasisfication edge/core/matrix (considering a given edge depth)- proportion of 
edge and core (within a window around each pixel)Metrics of landscape 
diversity(we are currently using the r.diversity add on to calculate that)

___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user