[GRASS-dev] Plan to build Package to use GRASS from R
Roger Bivand
Roger.Bivand at nhh.no
Thu Feb 28 04:52:12 EST 2008
On Thu, 28 Feb 2008, Roger Bivand 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.
Initial trials indicate that the XML package can parse the grass interface
DTD and the --interface-description output, but I haven't put them
together yet. If you know XML, this appears to be a fruitful way to use
tried mechanisms used in ongoing development for generating templates
within R to build command strings for system(). Some grass modules don't
support --interface-description, but I think not many.
Roger
>> > > >
>> > > > > ---
>> > > > > 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.
>
>> 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.
>
> 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
More information about the grass-dev
mailing list