<br><br><div><span class="gmail_quote">On 28/02/2008, <b class="gmail_sendername">Roger Bivand</b> <<a href="mailto:Roger.Bivand@nhh.no">Roger.Bivand@nhh.no</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Thu, 28 Feb 2008, Rainer M Krug wrote:<br> <br> <br>> On 28/02/2008, Roger Bivand <<a href="mailto:Roger.Bivand@nhh.no">Roger.Bivand@nhh.no</a>> wrote:<br> >><br> >><br> >><br> >><br> >> Glynn Clements wrote:<br>
>>><br> >>><br> >>> Rainer M Krug wrote:<br> >>><br> >>>> Sorry for crossposting, but I think this can be of interest for GRASS<br> >> and<br> >>>> R<br> >>>> users.<br>
>>>><br> >>>> I am planning to write a package to make the use of GRASS from R<br> >> easier.<br> >>>> The<br> >>>> idea is to wrap the system call to execute the GRASS command into an R<br>
>>>> command of the same name.<br> >>>> e.g:<br> >>>> r.to.vect <- function(..., intern=TRUE, ignore.stderr=FALSE)<br> >>>> {<br> >>>> comm <- paste( "r.to.vect ", ..., sep="" )<br>
>>>> print(comm)<br> >>>> system( comm, intern=intern, ignore.stderr=ignore.stderr )<br> >>>> }<br> >>>><br> >>>> My questions are:<br> >>>><br>
>>>> 1) Is this a good way of doing it, or is giving a named list to the<br> >>>> function<br> >>>> more usefull?<br> >>><br> >>> If R provides a way to pass individual arguments (argc/argv), use that<br>
>>> instead of contructing a shell command as a string. Otherwise, you are<br> >>> likely to run into problems with shell metacharacters in argument<br> >>> values.<br> >>><br> >><br>
>>> (Replying in Nabble because Rainer's posting has been swallowed by<br> >>> threading everywhere else)<br> >>><br> >>> This is the key sympton, seen recently in a similar interface to SAGA,<br>
>>> where the package author carelessly converted all "/" to "\" (it is only<br> >>> on Windows), thus destroying a valid r.mapcalc-like operation.<br> >>><br> >>> It is made worse by differences between Unixen and Windows in handling<br>
>>> stdout and stderr, and by differences between CygWin and MSYS in what<br> >> the<br> >>> GRASS commands are called in system() - MSYS wants an *.exe.<br> ><br> ><br> > R has a mechanism to detect the OS and, and that could be used to deal with<br>
> "/" or "\" issues as well as other differences (one thing I haven't<br> > considered yet as) .<br> > One way of dealing with the different OS concerning stderr and stdout would<br> > be using the command system() in R as it already adresses these issues (as<br>
> far as I know) and I managed to write usable wrappers around a few of the<br> > grass commands, including r.mapcalc. But especially r.mapcalc required<br> > manual tweaking...<br> <br> <br>It is precisely manual tweaking that gets broken ...</blockquote>
<div> </div>That's why I would like to avoid it...<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> ><br> >><br> >>>> 2) Is there a way to obtain easily all commands from GRASS and the<br>
>>>> parameters possible and required?<br> >>><br> >>> You can obtain a list of commands by enumerating the $GISBASE/bin and<br> >>> $GISBASE/scripts directories. Nearly all commands support the<br>
>>> --interface-description switch, which outputs details of all of the<br> >>> options in XML. There are several other switches which output the same<br> >>> information in different formats; see the g.parser manpage for<br>
>>> details.<br> >><br> >>> ---<br> >>> Actually, the interface problem for R is almost exactly the same as for<br> >>> all the other front ends - think of R as a CLI-UI. Using XML in R to set<br>
>>> up commands going from R to GRASS might not be impossible, where there<br> >>> would be only one command - do_GRASS(), taking the GRASS command as its<br> >>> required argument, and relying on the GRASS GUI to put up a dialogue. If<br>
>>> there were further arguments, then they would be used in the context of<br> >>> the requested command.<br> ><br> ><br> > That sounds like a good approach and as a starting point - as ultimately I<br>
> would like to be able to call e.g. r.in.bin() from R instead of do_GRASS("<br> > r.in.bin", ...). I am using R a lot at the moment to write ecological<br> > simulation models, and to use the commands directly makes the programs much<br>
> more readable as emacs highlights the commands. I will look into xml parsers<br> > under R to geth the information out of the grass command.<br> <br> <br>The workhorse has to be a do_GRASS() talking to GRASS in a standardised<br>
way (mirroring g.parser?). Whether you then generate aliases for it taking<br> the names of the first argument is a detail, but not a trivial one. You</blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
will certainly need a NAMESPACE in R, and do_GRASS() will be several<br> orders of magnitude easier to debug. </blockquote><div><br>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.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The GRASS command names are not</blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
guaranteed to be unique seen from the R side - load a contributed package<br> into the R workspace with its own g.list(), say, and which one will you<br> get?</blockquote><div> <br>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().<br>
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?<br><br>Rainer<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Roger<br> <br><br> ><br> ><br> >>><br> >>> I haven't been following the GUI discussion, so wonder whether the<br> >>> --interface-description output is cached anywhere? If not, do_GRASS()<br>
>>> would retrieve that first, and then try to insert given arguments, using<br> >>> platform specific "glue" to move forward. Has the (excellent, by the<br> >> way)<br> >>> progress on GUI provided a way of passing a "bubble" (say in XML) to<br>
>> GRASS<br> >>> commands, to avoid having to step around shell metacharacters? The same<br> >>> for error handling? It feels as though g.parser will help a lot.<br> ><br> ><br> > If the grass commands are created automatically and included into a package<br>
> (in addition to the flexible do_GRASS()), this would not be that relevant,<br> > as the creation of the code only happens once (either at coding time of the<br> > package or at compilation time - that would make the system much more<br>
> flexible as only GRASS commands / scripts installed be available).<br> ><br> > Rainer<br> ><br> >><br> >>> Roger<br> >><br> >>> --<br> >>> Glynn Clements <<a href="mailto:glynn@gclements.plus.com">glynn@gclements.plus.com</a>><br>
>><br> >>> _______________________________________________<br> >>> grass-dev mailing list<br> >><br> >>> <a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>
>><br> >>> <a href="http://lists.osgeo.org/mailman/listinfo/grass-dev">http://lists.osgeo.org/mailman/listinfo/grass-dev</a><br> >>><br> >>><br> >><br> >> --<br> >> View this message in context:<br>
>> <a href="http://www.nabble.com/Plan-to-build-Package-to-use-GRASS-from-R-tp15712877p15731306.html">http://www.nabble.com/Plan-to-build-Package-to-use-GRASS-from-R-tp15712877p15731306.html</a><br> >> Sent from the Grass - Dev mailing list archive at <a href="http://Nabble.com">Nabble.com</a>.<br>
>><br> >> _______________________________________________<br> >> grass-dev mailing list<br> >><br> >> <a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br> >><br>
>> <a href="http://lists.osgeo.org/mailman/listinfo/grass-dev">http://lists.osgeo.org/mailman/listinfo/grass-dev</a><br> >><br> ><br> ><br> ><br> ><br> <br> --<br> <br>Roger Bivand<br> Economic Geography Section, Department of Economics, Norwegian School of<br>
Economics and Business Administration, Helleveien 30, N-5045 Bergen,<br> Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43<br> e-mail: <a href="mailto:Roger.Bivand@nhh.no">Roger.Bivand@nhh.no</a><br> <br> </blockquote>
</div><br><br clear="all"><br>-- <br><br>-- <br>Rainer M. Krug, Dipl. Phys. (Germany), MSc Conservation Biology (UCT)<br><br>Plant Conservation Unit Department of Botany<br>University of Cape Town<br>Rondebosch 7701<br>South Africa