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

Rainer M Krug r.m.krug at gmail.com
Thu Feb 28 04:46:57 EST 2008


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:
> >>
> >> 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 the others *are* still available through namespaces, if the
> contributed package author used a NAMESPACE.


Yes - that's true. I haven't used namespaces so far, but I think I should.

> 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?
>
>
> Please note that generic methods dispatch on the .* of names for S3
> (old-style) classes. I don't think that "GRASS" is used as an S3 class
> name, but if it was, you'd get badly hurt by that. You need to look at the
> class/method system too.
>
> For example, summary.lm() is a different method from summary.default(),
> and both are used as summary() dispatching on the class of the first
> argument. I used to use "." in function names but now largely avoid it for
> this reason. do.GRASS would be a "do" method for an object of S3 class
> "GRASS". Visual editor concerns are minor by comparison. This will also
> (as you can see) impact the use of regular GRASS command names as R
> functions.


I think you convinced me. But the _ is so unhandy under EMACS... But I will
stick with it as it makes sense.
I looked into the XML package for R, and it looks promising for
parsing the return
value from --interface-description. I'll follow this line of ideas and let
you know of any progress.
But if the xml needs to be evaluated each time do_GRASS() is called, it will
slow it down considerably. I think the use of a cached version of the
interface description (in an Rdata file probably or in an additional XML
structure?) will be the most efficient way of doing it. It could be updated
at the first call of a GRASS command with do_GRASS() or manually whenever
GRASS is updated.

Rainer

Roger
>
>
> >
> > 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
> >>
> >>
> >
> >
> >
>
> --
> 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/d459413f/attachment-0001.html


More information about the grass-dev mailing list