<div>Rpad is a really nice tool, I didn't know it. But do you think it could be a way to solve my problem? I need to do gis analysis too, it's not just about dealing with R code... I know client/server isn't an easy subject but it seems to be the only way I can consider to interface the bash scripting code I will produce (I'm abandoning the idea to write a C modulea!!!) in a platform-independent way.
<br>Look at this <a href="http://les-ejk.cz/?cat=pywps">http://les-ejk.cz/?cat=pywps</a></div>
<div>Giovanni<br><br>2006/10/23, Roger Bivand <<a href="mailto:Roger.Bivand@nhh.no">Roger.Bivand@nhh.no</a>>:<br>> On Mon, 23 Oct 2006, G. Allegri wrote:<br>> <br>> > Thanks Roger for the complete answer!
<br>> > I know it sounds quite strange what I'm trying to do, and maybe it<br>> > isn't the best way to do it.<br>> > What I meant to do is an interactive (through a GUI interface to<br>> > develop) tool to elaborate hydrogeochemical datas about acquifer
<br>> > pollution defense. It should be used by an end-user as a Decision<br>> > Support System tool. It will use raster and vector input data to be<br>> > treated with mapalgebra and geostatisitcal analysis. The worst problem
<br>> > is that it should be, somehow, platform independent.<br>> <br>> If platform-independent, then a client-server model with the client being<br>> a web browser looks attractive. In that case, I would look seriously at
<br>> either MapServer (and Tyler Mitchell's book Web Mapping Illustrated) if<br>> most of the user interaction is in map form, or at Rpad:<br>> <br>> <a href="http://www.rpad.org/Rpad/">http://www.rpad.org/Rpad/
</a><br>> <br>> Look at <a href="http://www.rpad.org/Rpad/InterruptionMap.Rpad">http://www.rpad.org/Rpad/InterruptionMap.Rpad</a><br>> <br>> to see a very nice example. You'll need to look at load balancing<br>
> carefully, but here the web server and R are running on the server,<br>> producing pages with Javascript for interaction for the user. A lot of the<br>> hard work has already been done, and because of the split between client
<br>> and server, you can update the server-side compute engine without the user<br>> needing to install anything.<br>> <br>> I think this is as close as you can get - using embedded R will mean a lot<br>> more work, especially with maintenance. Note the comments on the Rpad site
<br>> about security, you will need to run the server with care.<br>> <br>> R can also be embedded within Apache, but I guess that Rpad is better for<br>> you. To be honest, it might well be worth paying someone with
<br>> Javascript/Perl/Apache etc. experience to help, none of these are suitable<br>> for non-specialists if the server is to be kept secure, really, but the<br>> same applies to any client-server model running across the Internet.
<br>> <br>> Roger<br>> <br>> > I'm not a professional programmer, I'm a geologist, and surely it<br>> > would be easiar to work with scripting then C coding, but it gets<br>> > harder to develop the "wizard" interface...
<br>> > In regard using R in an interactive way: I would like to "grep" simply<br>> > the output (as standard output or ascii file) and then use it for my<br>> > purposes.<br>> > Could you suggest me a way to implement this "stange" architecture?
<br>> > Giovanni<br>> ><br>> > P.S.: I'm considering the web interface way too...<br>> ><br>> ><br>> ><br>> > 2006/10/23, Roger Bivand <<a href="mailto:Roger.Bivand@nhh.no">Roger.Bivand@nhh.no
</a>>:<br>> > > On Mon, 23 Oct 2006, G. Allegri wrote:<br>> > ><br>> > > > I need to use R and gstat functionalities inside a module I'm writing.<br>> > ><br>> > > Why? What OS/platform? Unless you are doing something very peculiar, you
<br>> > > will waste an inordinate amount of time, where a shell script will get you<br>> > > there simply and be several orders of magnitude easier to debug. Be aware<br>> > > that R functions are often best used interactively because user choices
<br>> > > and error conditions do matter.<br>> > ><br>> > > > To embed R in a C program libRmath should be used.<br>> > ><br>> > > No, that is just to use the math functions. See Section
8.1 in<br>> > ><br>> > > <a href="http://cran.r-project.org/doc/manuals/R-exts.html">http://cran.r-project.org/doc/manuals/R-exts.html</a><br>> > ><br>> > > for Unixalikes (building R as a shared library, most likely
libR.so).<br>> > ><br>> > > > First question:<br>> > > > Is it possible to load gstat package from the R standalone library?<br>> > ><br>> > > Yes, like any package, but why?
<br>> > ><br>> > > > Second question:<br>> > > > Is there another way to do it when working inside a GRASS module? The<br>> > > > question raises because, with regard to spgrass6, there's no way to
<br>> > > > use it from a module (except by making a shell process call from C)...<br>> > ><br>> > > Well, you can use the GRASS API to populate the appropriate R object<br>> > > structures in C (see the GRASS5 GRASS package C code).
<br>> > ><br>> > > > am I wrong?<br>> > ><br>> > > Yes, because you will never (at least for a definition of never being<br>> > > greater than the number of developer hours taken to write and maintain
<br>> > > gstat and the R/GRASS interface) be able to do this robustly, taking<br>> > > account of all possible error conditions (identical points passed to gstat<br>> > > for example), and track changes in the different software environments
<br>> > > (something that works only with GRASS version x.y.z, R version a.b.c,<br>> > > gstat version d.e.f, sp version g.h.i, etc. There is simply too much being<br>> > > patched for a welded-hood C solution to be worth the development and
<br>> > > maintenance cost.<br>> > ><br>> > > By the way, you didn't say what you want to do that needs this level of<br>> > > automation; if you had, it might be easier to understand your very strange
<br>> > > design choices and resource commitments.<br>> > ><br>> > > > Thanks,<br>> > > > Giovanni<br>> > > ><br>> > > > _______________________________________________
<br>> > > > statsgrass mailing list<br>> > > > <a href="mailto:statsgrass@grass.itc.it">statsgrass@grass.itc.it</a><br>> > > > <a href="http://grass.itc.it/mailman/listinfo/statsgrass">
http://grass.itc.it/mailman/listinfo/statsgrass</a><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>> 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> </div>