On Wed, Apr 26, 2017 at 12:03 PM, Moritz Lennert < mlenn...@club.worldonline.be> wrote: > > On 25/04/17 22:14, Markus Metz wrote: >> >> >> On Tue, Apr 25, 2017 at 3:31 PM, Moritz Lennert >> <mlenn...@club.worldonline.be <mailto:mlenn...@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 > > 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
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev