On Thu, 28 Feb 2008, Rainer M Krug wrote:
On 28/02/2008, Roger Bivand <[EMAIL PROTECTED]> wrote:
Glynn Clements wrote:
Rainer M Krug wrote:
Sorry for crossposting, but I think this can be of interest for GRASS
and
R
users.
I am planning to write a package to make the use of GRASS from R
easier.
The
idea is to wrap the system call to execute the GRASS command into an R
command of the same name.
e.g:
r.to.vect <- function(..., intern=TRUE, ignore.stderr=FALSE)
{
comm <- paste( "r.to.vect ", ..., sep="" )
print(comm)
system( comm, intern=intern, ignore.stderr=ignore.stderr )
}
My questions are:
1) Is this a good way of doing it, or is giving a named list to the
function
more usefull?
If R provides a way to pass individual arguments (argc/argv), use that
instead of contructing a shell command as a string. Otherwise, you are
likely to run into problems with shell metacharacters in argument
values.
(Replying in Nabble because Rainer's posting has been swallowed by
threading everywhere else)
This is the key sympton, seen recently in a similar interface to SAGA,
where the package author carelessly converted all "/" to "\" (it is only
on Windows), thus destroying a valid r.mapcalc-like operation.
It is made worse by differences between Unixen and Windows in handling
stdout and stderr, and by differences between CygWin and MSYS in what
the
GRASS commands are called in system() - MSYS wants an *.exe.
R has a mechanism to detect the OS and, and that could be used to deal with
"/" or "\" issues as well as other differences (one thing I haven't
considered yet as) .
One way of dealing with the different OS concerning stderr and stdout would
be using the command system() in R as it already adresses these issues (as
far as I know) and I managed to write usable wrappers around a few of the
grass commands, including r.mapcalc. But especially r.mapcalc required
manual tweaking...
It is precisely manual tweaking that gets broken ...
2) Is there a way to obtain easily all commands from GRASS and the
parameters possible and required?
You can obtain a list of commands by enumerating the $GISBASE/bin and
$GISBASE/scripts directories. Nearly all commands support the
--interface-description switch, which outputs details of all of the
options in XML. There are several other switches which output the same
information in different formats; see the g.parser manpage for
details.
---
Actually, the interface problem for R is almost exactly the same as for
all the other front ends - think of R as a CLI-UI. Using XML in R to set
up commands going from R to GRASS might not be impossible, where there
would be only one command - do_GRASS(), taking the GRASS command as its
required argument, and relying on the GRASS GUI to put up a dialogue. If
there were further arguments, then they would be used in the context of
the requested command.
That sounds like a good approach and as a starting point - as ultimately I
would like to be able to call e.g. r.in.bin() from R instead of do_GRASS("
r.in.bin", ...). I am using R a lot at the moment to write ecological
simulation models, and to use the commands directly makes the programs much
more readable as emacs highlights the commands. I will look into xml parsers
under R to geth the information out of the grass command.
The workhorse has to be a do_GRASS() talking to GRASS in a standardised
way (mirroring g.parser?). Whether you then generate aliases for it taking
the names of the first argument is a detail, but not a trivial one. You
will certainly need a NAMESPACE in R, and do_GRASS() will be several
orders of magnitude easier to debug. The GRASS command names are not
guaranteed to be unique seen from the R side - load a contributed package
into the R workspace with its own g.list(), say, and which one will you
get?
Roger
I haven't been following the GUI discussion, so wonder whether the
--interface-description output is cached anywhere? If not, do_GRASS()
would retrieve that first, and then try to insert given arguments, using
platform specific "glue" to move forward. Has the (excellent, by the
way)
progress on GUI provided a way of passing a "bubble" (say in XML) to
GRASS
commands, to avoid having to step around shell metacharacters? The same
for error handling? It feels as though g.parser will help a lot.
If the grass commands are created automatically and included into a package
(in addition to the flexible do_GRASS()), this would not be that relevant,
as the creation of the code only happens once (either at coding time of the
package or at compilation time - that would make the system much more
flexible as only GRASS commands / scripts installed be available).
Rainer
Roger
--
Glynn Clements <[EMAIL PROTECTED]>
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
View this message in context:
http://www.nabble.com/Plan-to-build-Package-to-use-GRASS-from-R-tp15712877p15731306.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: [EMAIL PROTECTED]
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
