<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;">
<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 and<br> >> R<br> >> users.<br> >><br>
>> I am planning to write a package to make the use of GRASS from R 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 the<br> > GRASS commands are called in system() - MSYS wants an *.exe.</blockquote><div><br>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) . <br>
</div>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...<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> >> 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.</blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> ><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 way)<br>
> progress on GUI provided a way of passing a "bubble" (say in XML) to 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.</blockquote>
<div><br>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).<br>
</div><br>Rainer<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> > 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: <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> </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