<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> > On 28/02/2008, Roger Bivand <<a href="mailto:Roger.Bivand@nhh.no">Roger.Bivand@nhh.no</a>> wrote:<br> >><br> >> 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<br> >> 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<br>
>> 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<br> >> 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<br> >> would<br> >>> be using the command system() in R as it already adresses these issues<br>
>> (as<br> >>> far as I know) and I managed to write usable wrappers around a few of<br> >> 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 ...<br> ><br> ><br> > That's why I would like to avoid it...<br> ><br> >><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<br> >> for<br> >>>>> all the other front ends - think of R as a CLI-UI. Using XML in R to<br>
>> 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<br> >> its<br>
>>>>> required argument, and relying on the GRASS GUI to put up a dialogue.<br> >> If<br> >>>>> there were further arguments, then they would be used in the context<br> >> of<br>
>>>>> the requested command.<br> >>><br> >>><br> >>> That sounds like a good approach and as a starting point - as ultimately<br> >> I<br> >>> would like to be able to call e.g. r.in.bin() from R instead of<br>
>> 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<br> >> much<br>
>>> more readable as emacs highlights the commands. I will look into xml<br> >> 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<br> ><br> > will certainly need a NAMESPACE in R, and do_GRASS() will be several<br>
>> orders of magnitude easier to debug.<br> ><br> ><br> > I agree completely. But for readability, I would still like to have these<br> > wrappsers. But One could leave them for a later stage and to get do_GRASS()<br>
> working.<br> ><br> > The GRASS command names are not<br> ><br> > 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?<br> ><br> ><br> > Isn't that a general problem with using packages? There are several packages<br> > which overwrite other functions in other packages and they give a warning<br> > message when loading.<br>
<br> <br>But the others *are* still available through namespaces, if the<br> contributed package author used a NAMESPACE.</blockquote><div><br>Yes - that's true. I haven't used namespaces so far, but I think I should. <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;"> > But it would be nice to avoid these conflicts - one<br> > could introduce these wrappers as g.list.GRASS().<br>
> As an emacs user, I would actually prefer using do.GRASS() instead of<br> > do_GRASS() - but that is a minor point. As far as I know, there are no<br> > conventions in R concerning this?<br> <br> <br>Please note that generic methods dispatch on the .* of names for S3<br>
(old-style) classes. I don't think that "GRASS" is used as an S3 class<br> name, but if it was, you'd get badly hurt by that. You need to look at the<br> class/method system too.<br> <br> For example, summary.lm() is a different method from summary.default(),<br>
and both are used as summary() dispatching on the class of the first<br> argument. I used to use "." in function names but now largely avoid it for<br> this reason. do.GRASS would be a "do" method for an object of S3 class<br>
"GRASS". Visual editor concerns are minor by comparison. This will also<br> (as you can see) impact the use of regular GRASS command names as R<br> functions.</blockquote><div><br>I think you convinced me. But the _ is so unhandy under EMACS... But I will stick with it as it makes sense.<br>
I looked into the XML package for R, and it looks promising for parsing the <span class="q" id="q_1185f44191570a8e_3">return value from --interface-description. I'll follow this line of ideas and let you know of any progress.<br>
But if the xml needs to be evaluated each time do_GRASS() is called, it will slow it down considerably. I think the use of a cached version of the interface description (in an Rdata file probably or in a</span><span class="q" id="q_1185f44191570a8e_3">n additional XML structure</span><span class="q" id="q_1185f44191570a8e_3">?) will be the most efficient way of doing it. It could be updated at the first call of a GRASS command with do_GRASS() or manually whenever GRASS is updated.<br>
<br>Rainer<br></span></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> > Rainer<br> ><br> > 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,<br> >> 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<br>
>> 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<br>
>> package<br> >>> (in addition to the flexible do_GRASS()), this would not be that<br> >> relevant,<br> >>> as the creation of the code only happens once (either at coding time of<br> >> 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> >>>><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> >><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