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

> 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