[GRASS-dev] Plan to build Package to use GRASS from R

[Rainer M Krug]

On 28/02/2008, Roger Bivand <Roger.Bivand at nhh.no> 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...

>
> >> 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.


> >
> > 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 <glynn at gclements.plus.com>
>
> > _______________________________________________
> > grass-dev mailing list
>
> > grass-dev at lists.osgeo.org
>
> > 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
>
> grass-dev at lists.osgeo.org
>
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 

-- 
Rainer M. Krug, Dipl. Phys. (Germany), MSc Conservation Biology (UCT)

Plant Conservation Unit Department of Botany
University of Cape Town
Rondebosch 7701
South Africa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-dev/attachments/20080228/b53ee0fb/attachment.html