[GRASS-dev] r.pi installation fails

Hi Devs

I am trying to install r.pi addon, but I am getting the following error message:

Fetching <r.pi> from GRASS GIS Addons repository (be patient)...
Compiling...
/usr/bin/ld: cannot open output file
/usr/local/grass7/grass-7.3.svn/lib/libgrass_rpi.7.3.svn.so:
Permission denied
collect2: error: ld returned 1 exit status
make[1]: *** [/usr/local/grass7/grass-7.3.svn/lib/libgrass_r
pi.7.3.svn.so] Error 1
/bin/sh: 1: cannot create
/usr/local/grass7/grass-7.3.svn/error.log: Permission denied
make: *** [r.pi.library] Error 2
ERROR: Compilation failed, sorry. Please check above error messages.

It seems it is not installing the plugin in the plugin folder but in the grass7 system folder?

On Fri, Apr 7, 2017 at 9:09 AM, Paulo van Breugel <p.vanbreugel@gmail.com> wrote:

Hi Devs

I am trying to install r.pi addon, but I am getting the following error message:

Fetching <r.pi> from GRASS GIS Addons repository (be patient)…
Compiling…
/usr/bin/ld: cannot open output file
/usr/local/grass7/grass-7.3.svn/lib/libgrass_rpi.7.3.svn.so:
Permission denied
collect2: error: ld returned 1 exit status
make[1]: *** [/usr/local/grass7/grass-7.3.svn/lib/libgrass_r
pi.7.3.svn.so] Error 1
/bin/sh: 1: cannot create
/usr/local/grass7/grass-7.3.svn/error.log: Permission denied
make: *** [r.pi.library] Error 2
ERROR: Compilation failed, sorry. Please check above error messages.

It seems it is not installing the plugin in the plugin folder but in the grass7 system folder?

At least it tries to install the r.pi library in the system folder and not in the local addons folder. Even if the r.pi library would be installed to the local addons folder, the library path would need to be modified accordingly, not sure if g.extension handles that.

If you compile GRASS from source, you can svn checkout the r.pi folder, manually run make and (as root) make install.

Also note that porting the r.pi modules to GRASS7 is work in progress, there are still known bugs and they are not yet well tested.

Markus M

OK, thanks for the information. This is a disadvantages of having all addons automatically listed in the g.extension installer, even if it is known to not install. The same is true for shell scripts, which can also not be installed automatically using g.extension a.f.a.i.k. Would it be an idea, and possible, to exclude them from the list shows in the g.extension GUI, but maintaining them e.g., on the list on )?

···

On 07-04-17 14:05, Markus Metz wrote:

On Fri, Apr 7, 2017 at 9:09 AM, Paulo van Breugel <p.vanbreugel@gmail.com> wrote:

Hi Devs

I am trying to install r.pi addon, but I am getting the following error message:

Fetching <r.pi> from GRASS GIS Addons repository (be patient)…
Compiling…
/usr/bin/ld: cannot open output file
/usr/local/grass7/grass-7.3.svn/lib/libgrass_rpi.7.3.svn.so:
Permission denied
collect2: error: ld returned 1 exit status
make[1]: *** [/usr/local/grass7/grass-7.3.svn/lib/libgrass_r
pi.7.3.svn.so] Error 1
/bin/sh: 1: cannot create
/usr/local/grass7/grass-7.3.svn/error.log: Permission denied
make: *** [r.pi.library] Error 2
ERROR: Compilation failed, sorry. Please check above error messages.

It seems it is not installing the plugin in the plugin folder but in the grass7 system folder?

At least it tries to install the r.pi library in the system folder and not in the local addons folder. Even if the r.pi library would be installed to the local addons folder, the library path would need to be modified accordingly, not sure if g.extension handles that.

If you compile GRASS from source, you can svn checkout the r.pi folder, manually run make and (as root) make install.

https://grass.osgeo.org/grass72/manuals/addons/

Also note that porting the r.pi modules to GRASS7 is work in progress, there are still known bugs and they are not yet well tested.

Markus M

On 07/04/17 14:05, Markus Metz wrote:

On Fri, Apr 7, 2017 at 9:09 AM, Paulo van Breugel
<p.vanbreugel@gmail.com <mailto:p.vanbreugel@gmail.com>> wrote:

Hi Devs

I am trying to install r.pi addon, but I am getting the following

error message:

Fetching <r.pi> from GRASS GIS Addons repository (be patient)...
Compiling...
/usr/bin/ld: cannot open output file
/usr/local/grass7/grass-7.3.svn/lib/libgrass_rpi.7.3.svn.so

<http://libgrass_rpi.7.3.svn.so>:

Permission denied
collect2: error: ld returned 1 exit status
make[1]: *** [/usr/local/grass7/grass-7.3.svn/lib/libgrass_r
pi.7.3.svn.so <http://pi.7.3.svn.so>] Error 1
/bin/sh: 1: cannot create
/usr/local/grass7/grass-7.3.svn/error.log: Permission denied
make: *** [r.pi.library] Error 2
ERROR: Compilation failed, sorry. Please check above error messages.

It seems it is not installing the plugin in the plugin folder but in

the grass7 system folder?

At least it tries to install the r.pi library in the system folder and
not in the local addons folder. Even if the r.pi library would be
installed to the local addons folder, the library path would need to be
modified accordingly, not sure if g.extension handles that.

If you compile GRASS from source, you can svn checkout the r.pi folder,
manually run make and (as root) make install.

Trying this, I get two errors while compiling:

make[1] : on entre dans le répertoire « /data/home/mlennert/SRC/GRASS/grass-addons/grass7/raster/r.pi/r.pi.grow »
test -d OBJ.x86_64-pc-linux-gnu || mkdir -p OBJ.x86_64-pc-linux-gnu
gcc -g -O2 -I/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-pc-linux-gnu/include -I/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-pc-linux-gnu/include -DPACKAGE=\""grassmods"\" -I/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-pc-linux-gnu/include -I/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"/data/home/mlennert/SRC/GRASS/grass-addons/grass7/raster/r.pi/r.pi.grow\" -o OBJ.x86_64-pc-linux-gnu/func.o -c func.c
In file included from func.c:1:0:
local_proto.h:23:3: error: conflicting types for ‘Position’
  } Position;
    ^~~~~~~~
In file included from local_proto.h:12:0,
                  from func.c:1:
../r.pi.library/r_pi.h:25:3: note: previous declaration of ‘Position’ was here
  } Position;
    ^~~~~~~~
/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-pc-linux-gnu//include/Make/Compile.make:32 : la recette pour la cible « OBJ.x86_64-pc-linux-gnu/func.o » a échouée
make[1]: *** [OBJ.x86_64-pc-linux-gnu/func.o] Erreur 1
make[1] : on quitte le répertoire « /data/home/mlennert/SRC/GRASS/grass-addons/grass7/raster/r.pi/r.pi.grow »

and

make[1] : on entre dans le répertoire « /data/home/mlennert/SRC/GRASS/grass-addons/grass7/raster/r.pi/r.pi.lm »
test -d OBJ.x86_64-pc-linux-gnu || mkdir -p OBJ.x86_64-pc-linux-gnu
gcc -g -O2 -I/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-pc-linux-gnu/include -I/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-pc-linux-gnu/include -DPACKAGE=\""grassmods"\" -I/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-pc-linux-gnu/include -I/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"/data/home/mlennert/SRC/GRASS/grass-addons/grass7/raster/r.pi/r.pi.lm\" -o OBJ.x86_64-pc-linux-gnu/frag.o -c frag.c
frag.c:6:3: error: conflicting types for ‘Position’
  } Position;
    ^~~~~~~~
In file included from local_proto.h:10:0,
                  from frag.c:1:
../r.pi.library/r_pi.h:25:3: note: previous declaration of ‘Position’ was here
  } Position;
    ^~~~~~~~
/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-pc-linux-gnu//include/Make/Compile.make:32 : la recette pour la cible « OBJ.x86_64-pc-linux-gnu/frag.o » a échouée
make[1]: *** [OBJ.x86_64-pc-linux-gnu/frag.o] Erreur 1
make[1] : on quitte le répertoire « /data/home/mlennert/SRC/GRASS/grass-addons/grass7/raster/r.pi/r.pi.lm »

Moritz

On Tue, Apr 25, 2017 at 3:31 PM, Moritz Lennert <mlennert@club.worldonline.be> wrote:

On 07/04/17 14:05, Markus Metz wrote:
[…]

If you compile GRASS from source, you can svn checkout the r.pi folder,
manually run make and (as root) make install.

Trying this, I get two errors while compiling:

make[1] : on entre dans le répertoire « /data/home/mlennert/SRC/GRASS/grass-addons/grass7/raster/r.pi/r.pi.grow »

and

make[1] : on entre dans le répertoire « /data/home/mlennert/SRC/GRASS/grass-addons/grass7/raster/r.pi/r.pi.lm »

Fixed in r70952. Please test (not only compilation, but also actual results).

Markus M

On 25/04/17 22:14, Markus Metz wrote:

On Tue, Apr 25, 2017 at 3:31 PM, Moritz Lennert
<mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be>> wrote:

On 07/04/17 14:05, Markus Metz wrote:

[...]

If you compile GRASS from source, you can svn checkout the r.pi folder,
manually run make and (as root) make install.

Trying this, I get two errors while compiling:

make[1] : on entre dans le répertoire «

/data/home/mlennert/SRC/GRASS/grass-addons/grass7/raster/r.pi/r.pi.grow »

and

make[1] : on entre dans le répertoire «

/data/home/mlennert/SRC/GRASS/grass-addons/grass7/raster/r.pi/r.pi.lm »

Fixed in r70952. Please test (not only compilation, but also actual
results).

Here are some rapid tests based on the man pages examples (with me not understanding most of the metrics, yet):

*********************************************
r.pi.index

I get identical area and perimeter values as from r.object.geometry.

Compactness and fractal dimension are not identical to the respective either measures of r.object.geometry (for compactness for neither of the two in r.object.geometry), but I haven't read through the Fragstat manual nor though the code to see how they are calculated here.

If r.pi.index allowed an output of all indicators directly to text file this could possibly supersede r.object.geometry. No need to maintain two similar modules, or ?

*********************************************
r.pi.enn:

r.pi.enn input=landclass96 output=dist1.c5 keyval=5 method=distance number=1 statmethod=average --o

Loading patches...
  100%
Performing operation distance ...
  100%
Writing output...
  100%
ERROR: Raster map <dist1.c5@user1> not found

Probably because of lines 392ff in main.c:

     Rast_write_cats(newname, &cats);

     if (copycolr)
         Rast_write_colors(newname, G_mapset(), &colr);

which try to write to newnames, but maps are actually named with

sprintf(fullname, "%s.NN%d.%s", newname, parseres[j],
                     menu[methods[m]].name);

and so there is no map newname. The resulting map does not seem correct, either:

r.info -r dist1.c5.NN1.distance
min=-nan
max=-nan

Same issue with all other examples on that man page. And there is an error in the output name of the third example: output=dist1.5.10,c5 should probably be output=dist1.5.10.c5 (period instead of comma).
*********************************************

********************************************
r.pi.energy

r.pi.energy input=landclass96 output=energy1 keyval=5 n=1000 step_length=5 energy=10 percent=80

It runs and there are results. At this stage I don't understand the module enough to judge the quality of the results, but:

1) output=name [required]
     Name for output raster map

This should be described as "Prefix of output raster map names" (or similar). In addition, it would be nice to be able to choose which maps are created.

2) The module silently overwrites existing maps which is not a good idea IMHO.
**********************************************

**********************************************
r.pi.nlm

r.pi.nlm output=nlm.1 landcover=5 --o
r.stats -p nlm.1 --q
1 0.28%
* 99.72%

r.pi.nlm output=nlm.1 landcover=10 --o
r.stats -p nlm.1 --q
1 3.22%
* 96.78%

r.pi.nlm output=nlm.1 landcover=25 --o
r.stats -p nlm.1 --q
1 49.25%
* 50.75%

r.pi.nlm output=nlm.1 landcover=50 --o
r.stats -p nlm.1 --q
1 50.77%
* 49.23%

r.pi.nlm output=nlm.1 landcover=75 --o
r.stats -p nlm.1 --q
1 51.97%
* 48.03%

So, I don't really understand the landcover parameter which is indicated as meaning "Landcover in percent".
***********************************************

**********************************************
r.pi.searchtime

r.pi.searchtime input=landclass96 output=searchtime1 keyval=5 step_length=5 stats=average,variance percent=80 n=1000

There is this output in stdout, which looks like debug info:

average:
frag0: 4.35 frag1: 20.37 frag2: 16.56 frag3: 1.61 frag4: 4.90 frag5: 2.45 frag6: 10.70 frag7: 2.01 frag8: 2.88 frag9: 1.32 frag10: 1.39 frag11: 8.68 frag12: 1.72 frag13: 1.56 frag14: 1.71 frag15: 8.87 frag16: 10.01 frag17: 10.86 frag18: 7.54 frag19: 7.82 frag20: 12.36 frag21: 10.35 frag22: 8.88 frag23: 5.30 frag24: 4.54 frag25: 3.22 frag26: 9.74 frag27: 2.80 frag28: 8.76 frag29: 1.70 frag30: 11.07 frag31: 8.89 frag32: 7.59 frag33: 1.87 frag34: 4.70 frag35: 8.68 frag36: 1.65 frag37: 1.96 frag38: 1.29[...

Again, output=name [required] should be described as "Prefix of output map names" and output overwrites an existing map.

I can't judge the quality of the results.
******************************************************

That's all I have time for right now. Probably at one point this should all go through the bug tracker ?

Moritz

On Wed, Apr 26, 2017 at 12:03 PM, Moritz Lennert <mlennert@club.worldonline.be> wrote:

On 25/04/17 22:14, Markus Metz wrote:

On Tue, Apr 25, 2017 at 3:31 PM, Moritz Lennert
<mlennert@club.worldonline.be mailto:[mlennert@club.worldonline.be](mailto:mlennert@club.worldonline.be)> wrote:

On 07/04/17 14:05, Markus Metz wrote:

[…]

If you compile GRASS from source, you can svn checkout the r.pi folder,
manually run make and (as root) make install.

Trying this, I get two errors while compiling:

make[1] : on entre dans le répertoire «

/data/home/mlennert/SRC/GRASS/grass-addons/grass7/raster/r.pi/r.pi.grow »

and

make[1] : on entre dans le répertoire «

/data/home/mlennert/SRC/GRASS/grass-addons/grass7/raster/r.pi/r.pi.lm »

Fixed in r70952. Please test (not only compilation, but also actual
results).

Here are some rapid tests based on the man pages examples (with me not understanding most of the metrics, yet):


r.pi.index

I get identical area and perimeter values as from r.object.geometry.

Compactness and fractal dimension are not identical to the respective either measures of r.object.geometry (for compactness for neither of the two in r.object.geometry), but I haven’t read through the Fragstat manual nor though the code to see how they are calculated here.

In r.pi.index, compactness is apparently calculated as the area of the bounding box divided by the actual area of a patch, and fractal dimension of a patch is calculated as 2 * log(0.25 * perimeter) / log(area). These formulas are different from r.object.geometry. Also, r.pi.index uses cells as unit, not map units or meters.

If r.pi.index allowed an output of all indicators directly to text file this could possibly supersede r.object.geometry. No need to maintain two similar modules, or ?

Be aware that the r.pi modules are not maintained, while r.object.geometry is being maintained. I would rather remove r.pi modules if their functionality is also covered by other modules.


r.pi.enn:

r.pi.enn input=landclass96 output=dist1.c5 keyval=5 method=distance number=1 statmethod=average --o

Loading patches…
100%
Performing operation distance …
100%
Writing output…
100%
ERROR: Raster map dist1.c5@user1 not found

Probably because of lines 392ff in main.c:

Rast_write_cats(newname, &cats);

if (copycolr)
Rast_write_colors(newname, G_mapset(), &colr);

which try to write to newnames, but maps are actually named with

sprintf(fullname, “%s.NN%d.%s”, newname, parseres[j],
menu[methods[m]].name);

and so there is no map newname.

Copying the colors does not make sense here (coming from the GRASS6 version).

The resulting map does not seem correct, either:

r.info -r dist1.c5.NN1.distance
min=-nan
max=-nan

No idea yet why the results is NULL (-nan is equal to NULL for fp maps).

Same issue with all other examples on that man page. And there is an error in the output name of the third example: output=dist1.5.10,c5 should probably be output=dist1.5.10.c5 (period instead of comma).



r.pi.energy

  1. output=name [required]
    Name for output raster map

This should be described as “Prefix of output raster map names” (or similar). In addition, it would be nice to be able to choose which maps are created.

same for e.g. r.pi.enn

  1. The module silently overwrites existing maps which is not a good idea IMHO.

Should be fixed, also in other r.pi modules that internally create output raster names from a given prefix.


r.pi.nlm

r.pi.nlm output=nlm.1 landcover=5 --o
r.stats -p nlm.1 --q
1 0.28%

  • 99.72%

r.pi.nlm output=nlm.1 landcover=10 --o
r.stats -p nlm.1 --q
1 3.22%

  • 96.78%

r.pi.nlm output=nlm.1 landcover=25 --o
r.stats -p nlm.1 --q
1 49.25%

  • 50.75%

r.pi.nlm output=nlm.1 landcover=50 --o
r.stats -p nlm.1 --q
1 50.77%

  • 49.23%

r.pi.nlm output=nlm.1 landcover=75 --o
r.stats -p nlm.1 --q
1 51.97%

  • 48.03%

So, I don’t really understand the landcover parameter which is indicated as meaning “Landcover in percent”.

use r.random instead.


r.pi.searchtime

r.pi.searchtime input=landclass96 output=searchtime1 keyval=5 step_length=5 stats=average,variance percent=80 n=1000

There is this output in stdout, which looks like debug info:

average:
frag0: 4.35 frag1: 20.37 frag2: 16.56 frag3: 1.61 frag4: 4.90 frag5: 2.45 frag6: 10.70 frag7: 2.01 frag8: 2.88 frag9: 1.32 frag10: 1.39 frag11: 8.68 frag12: 1.72 frag13: 1.56 frag14: 1.71 frag15: 8.87 frag16: 10.01 frag17: 10.86 frag18: 7.54 frag19: 7.82 frag20: 12.36 frag21: 10.35 frag22: 8.88 frag23: 5.30 frag24: 4.54 frag25: 3.22 frag26: 9.74 frag27: 2.80 frag28: 8.76 frag29: 1.70 frag30: 11.07 frag31: 8.89 frag32: 7.59 frag33: 1.87 frag34: 4.70 frag35: 8.68 frag36: 1.65 frag37: 1.96 frag38: 1.29[…

Maybe this is intended, maybe not. Also present in the GRASS6 version.

Again, output=name [required] should be described as “Prefix of output map names” and output overwrites an existing map.

As above for other r.pi modules.

That’s all I have time for right now. Probably at one point this should all go through the bug tracker ?

IMHO, the original authors need to test the r.pi modules first and provide feedback including more documentation on the intended behaviour of the r.pi modules.

Markus M

On 26/04/17 23:17, Markus Metz wrote:

On Wed, Apr 26, 2017 at 12:03 PM, Moritz Lennert
<mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be>> wrote:

If r.pi.index allowed an output of all indicators directly to text

file this could possibly supersede r.object.geometry. No need to
maintain two similar modules, or ?

Be aware that the r.pi modules are *not* maintained, while
r.object.geometry is being maintained. I would rather remove r.pi
modules if their functionality is also covered by other modules.

[...]

IMHO, the original authors need to test the r.pi modules first and
provide feedback including more documentation on the intended behaviour
of the r.pi modules.

Ok, I misunderstood. I thought your effort of porting to grass7 was a sign that they were maintained.

If that's not the case, let's wait for the authors to react (Martin, are you still listening to this list ?). Potentially these are nice metrics to have, both for landscape analysis, but also for OBIA, so it would be great to have someone who maintains them.

Moritz