[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:
>
> On Thu, 28 Feb 2008, Rainer M Krug wrote:
>
>
> > 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...
>
>
> It is precisely manual tweaking that gets broken ...


That's why I would like to avoid it...

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


I agree completely. But for readability, I would still like to have these
wrappsers. But One could leave them for a later stage and to get do_GRASS()
working.

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?


Isn't that a general problem with using packages? There are several packages
which overwrite other functions in other packages and they give a warning
message when loading. But it would be nice to avoid these conflicts - one
could introduce these wrappers as g.list.GRASS().
As an emacs user, I would actually prefer using do.GRASS() instead of
do_GRASS() - but that is a minor point. As far as I know, there are no
conventions in R concerning this?

Rainer

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 <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
> >>
> >
> >
> >
> >
>
> --
>
> 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: Roger.Bivand at nhh.no
>
>


-- 

-- 
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/3da002a9/attachment-0001.html