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

[Roger Bivand]

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

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