[GRASS-user] New AddOns for Analyzing landscape connectivity based on graph-theory - the r.connectivity.*-toolchain

[Helmut Kudrnovsky]

hi Stefan,

>Many thanks for testing!

de nada

>Regarding A: Did I get you right that you had problems with the ' \ ' and '
" '?

r.mapcalc "patches=if(\
landuse96_28m[0,1]==11&&\
[...]

this isn't possible in the wxgui-commandline (not tried in the
wingrass-windows-commandline; most users on windows probably are using only
the GUI)

>Removing the backslash won`t be a problem, but I think the quotation-marks
are required on >Linux...

unfortunately there seams to be inconsistency between
unix/windows/GUI/commandline

>For the latter it is probably best to put a note in the example... 

sure, but better feel free to open a ticket for this in
http://trac.osgeo.org/grass/, because otherwise it's getting lost in
manual/ML and other modules/scripts etc. are able to benefit

>C)
>C occurs because v.extract (at line 377 of the script) fails.
>I assume you used the command-line in the wxPython-GUI?

yes

>Could you be so kind and try to use the command in the text version of
wingrass?

sure, but unfortunately the same message:

[...]
Calculating connectivity-distances for patch number 279
C:/OSGeo4W/apps/grass/grass-6.4.3svn/scripts/r.connectivity.distance: line
379:
[: -gt: unary operator expected
C:/OSGeo4W/apps/grass/grass-6.4.3svn/scripts/r.connectivity.distance: line
386:
[: -eq: unary operator expected
 100%
 100%
Calculating connectivity-distances for patch number 294
C:/OSGeo4W/apps/grass/grass-6.4.3svn/scripts/r.connectivity.distance: line
379:
[: -gt: unary operator expected
C:/OSGeo4W/apps/grass/grass-6.4.3svn/scripts/r.connectivity.distance: line
386:
[: -eq: unary operator expected
 100%
 100%
Calculating connectivity-distances for patch number 298
C:/OSGeo4W/apps/grass/grass-6.4.3svn/scripts/r.connectivity.distance: line
379:
[: -gt: unary operator expected
C:/OSGeo4W/apps/grass/grass-6.4.3svn/scripts/r.connectivity.distance: line
386:
[: -eq: unary operator expected
 100%
 100%
GRASS 6.4.3svn (nc_spm_08)>

>It is a mystery to me why some wingrass commands behave differently when
invoked from the >command-line in the GUI and from the command-line
(text-GUI). 

...windows itself is a mystery...not only the differences between XP, Vista,
7 and soon 8

>I think it would be a pitty if the GUI was not usable for these addons, but
I feel that it is beyond my >power to make it work... Are there any
solutions I could use from other shell-scripts (calling >v.extract)?

feel free to post this issue separately on the dev-ML or open a ticket in
http://trac.osgeo.org/grass/ 

>The %PATH% settings are also a problem for ghostscript which is required
for eps-output (the >plots).

adding the ghostscript-%PATH%-issue to the manual?

> Because this is neither added to the %PATH%-variable by default, I simply 
>skipped/deactivated checking for ghostscript in windows (here also the
commands / executables >can be different... :-( ), 

the windows mystery...

>so checking for ghostscript on Windows is challenging in itself.
>The problem with R is, that R is called by the script (while ghostscript is
not). In other words: the >script  requires that the path to R is defined in
the %PATH% settings and that R can be called >directly...
>Maybe the best way to solve this is to add this information to the
error-message (and a link to the >GRASS-R-Wiki...). 

in the standalone winGRASS6.5svn/winGRASS7-installer there is the new
approach of R-winGRASS-coupling by the "Windows batchfiles for use with R"
mentioned in the wiki
(http://grass.osgeo.org/wiki/R_statistics#GRASS_7_Usage), in the upcoming
standalone winGRASS6.4.3(svn) there is the old statically approach
(http://grass.osgeo.org/wiki/R_statistics#GRASS_6_Usage_III_.28taken_from_the_grass-stats-ML.29)
because of "nearly" feature freeze.

in short, in the standalone-winGRASSX.x.x, R should in the %PATH%

in the osgeo4w-winGRASSX.x.x R isn't yet in the %PATH%. 

please feel free to open a ticket in http://trac.osgeo.org/grass/ to change
this.

>Strange that r_connectivity.log seams not to be readable. Because from your
output you posted I >can see, that the file was written at the correct
place. 

yes

>So the path must have been interpreted 
>correctly for writing. I have no idea why it is obviously 
>not interpreted correctly for reading... I will 
>check that... 

no idea at the moment for this.













-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.n6.nabble.com/New-AddOns-for-Analyzing-landscape-connectivity-based-on-graph-theory-the-r-connectivity-toolchain-tp5000351p5003035.html
Sent from the Grass - Users mailing list archive at Nabble.com.