[GRASS-dev] r.pi installation fails

Wed Apr 26 14:17:47 PDT 2017

On Wed, Apr 26, 2017 at 12:03 PM, Moritz Lennert <
mlennert at 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 at club.worldonline.be <mailto:mlennert at 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 at 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

>
> 2) 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20170426/d298c5cc/attachment.html>