[STATSGRASS] using R and gstat inside a C module
G. Allegri
giohappy at gmail.com
Sat Oct 28 06:08:43 EDT 2006
Thanks Song!
This is exactly what I was thinking in these days... I will try to develop
my own system during november. Keep in contact and tell me, if you want,
your improvements.
A question: where is it possible to download pywps? The old page has broken
links to the package, and the one beeing built on gforge isn't ready yet...
Maybe cvs?
Kind regards,
Giovanni A.
P.S.: I've just subscribed pywps-devel mailing-list.
2006/10/28, xianfeng song <song.osgeo at gmail.com>:
>
> Dear Allegri,
>
> The integration of R and PyWPS is a Python solution. The RPy package
> play an important role!
> 1)Writing your analysis-function scripts using R, and then those
> functions could be called RPy.
> 2)then making a PyWPS process that deliveries your R functions over web
> by importing RPy module.
> This is a solution using standard web service, see my demo at
> http://zihuan.gucas.ac.cn/webgis/PyWPS_GNUR_Example.html
>
> Python is a easy-to-use script language, you may just program your CGI
> using Python + RPy + R.
> Later I will post pywps-devel at wald.intevation.de a brief summery about
> my testing work. you may have a look if you are interested.
>
> Kind regards,
> Song
>
> On 2006-10-24 2:35, Markus Neteler wrote:
> > On Mon, Oct 23, 2006 at 07:38:51PM +0200, G. Allegri wrote:
> > > 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.
> > > Look at this [1]http://les-ejk.cz/?cat=pywps
> >
> > As far as I know, pywps has been recently integrated with R.
> > I cc the author (who may be offline for a week) to give
> > further details.
> >
> > Markus
> >
> >
> > > Giovanni
> > >
> > > 2006/10/23, Roger Bivand <[2]Roger.Bivand at nhh.no>:
> > > > On Mon, 23 Oct 2006, G. Allegri wrote:
> > > >
> > > > > Thanks Roger for the complete answer!
> > > > > I know it sounds quite strange what I'm trying to do, and maybe
> it
> > > > > isn't the best way to do it.
> > > > > What I meant to do is an interactive (through a GUI interface
> to
> > > > > develop) tool to elaborate hydrogeochemical datas about
> acquifer
> > > > > pollution defense. It should be used by an end-user as a
> Decision
> > > > > Support System tool. It will use raster and vector input data
> to be
> > > > > treated with mapalgebra and geostatisitcal analysis. The worst
> problem
> > > > > is that it should be, somehow, platform independent.
> > > >
> > > > If platform-independent, then a client-server model with the
> client
> > > being
> > > > a web browser looks attractive. In that case, I would look
> seriously at
> > > > either MapServer (and Tyler Mitchell's book Web Mapping
> Illustrated) if
> > > > most of the user interaction is in map form, or at Rpad:
> > > >
> > > > [3]http://www.rpad.org/Rpad/
> > > >
> > > > Look at [4]http://www.rpad.org/Rpad/InterruptionMap.Rpad
> > > >
> > > > to see a very nice example. You'll need to look at load balancing
> > > > carefully, but here the web server and R are running on the
> server,
> > > > producing pages with Javascript for interaction for the user. A
> lot of
> > > the
> > > > hard work has already been done, and because of the split between
> client
> > > > and server, you can update the server-side compute engine without
> the
> > > user
> > > > needing to install anything.
> > > >
> > > > I think this is as close as you can get - using embedded R will
> mean a
> > > lot
> > > > more work, especially with maintenance. Note the comments on the
> Rpad
> > > site
> > > > about security, you will need to run the server with care.
> > > >
> > > > R can also be embedded within Apache, but I guess that Rpad is
> better
> > > for
> > > > you. To be honest, it might well be worth paying someone with
> > > > Javascript/Perl/Apache etc. experience to help, none of these are
> > > suitable
> > > > for non-specialists if the server is to be kept secure, really,
> but the
> > > > same applies to any client-server model running across the
> Internet.
> > > >
> > > > Roger
> > > >
> > > > > I'm not a professional programmer, I'm a geologist, and surely
> it
> > > > > would be easiar to work with scripting then C coding, but it
> gets
> > > > > harder to develop the "wizard" interface...
> > > > > In regard using R in an interactive way: I would like to "grep"
> simply
> > > > > the output (as standard output or ascii file) and then use it
> for my
> > > > > purposes.
> > > > > Could you suggest me a way to implement this "stange"
> architecture?
> > > > > Giovanni
> > > > >
> > > > > P.S.: I'm considering the web interface way too...
> > > > >
> > > > >
> > > > >
> > > > > 2006/10/23, Roger Bivand <[5]Roger.Bivand at nhh.no >:
> > > > > > On Mon, 23 Oct 2006, G. Allegri wrote:
> > > > > >
> > > > > > > I need to use R and gstat functionalities inside a module
> I'm
> > > writing.
> > > > > >
> > > > > > Why? What OS/platform? Unless you are doing something very
> peculiar,
> > > you
> > > > > > will waste an inordinate amount of time, where a shell script
> will
> > > get you
> > > > > > there simply and be several orders of magnitude easier to
> debug. Be
> > > aware
> > > > > > that R functions are often best used interactively because
> user
> > > choices
> > > > > > and error conditions do matter.
> > > > > >
> > > > > > > To embed R in a C program libRmath should be used.
> > > > > >
> > > > > > No, that is just to use the math functions. See Section 8.1in
> > > > > >
> > > > > > [6]http://cran.r-project.org/doc/manuals/R-exts.html
> > > > > >
> > > > > > for Unixalikes (building R as a shared library, most likely
> > > libR.so).
> > > > > >
> > > > > > > First question:
> > > > > > > Is it possible to load gstat package from the R standalone
> > > library?
> > > > > >
> > > > > > Yes, like any package, but why?
> > > > > >
> > > > > > > Second question:
> > > > > > > Is there another way to do it when working inside a GRASS
> module?
> > > The
> > > > > > > question raises because, with regard to spgrass6, there's
> no way
> > > to
> > > > > > > use it from a module (except by making a shell process call
> from
> > > C)...
> > > > > >
> > > > > > Well, you can use the GRASS API to populate the appropriate R
> object
> > > > > > structures in C (see the GRASS5 GRASS package C code).
> > > > > >
> > > > > > > am I wrong?
> > > > > >
> > > > > > Yes, because you will never (at least for a definition of
> never
> > > being
> > > > > > greater than the number of developer hours taken to write and
> > > maintain
> > > > > > gstat and the R/GRASS interface) be able to do this robustly,
> taking
> > > > > > account of all possible error conditions (identical points
> passed to
> > > gstat
> > > > > > for example), and track changes in the different software
> > > environments
> > > > > > (something that works only with GRASS version x.y.z, R
> version
> > > a.b.c,
> > > > > > gstat version d.e.f, sp version g.h.i, etc. There is simply
> too much
> > > being
> > > > > > patched for a welded-hood C solution to be worth the
> development and
> > > > > > maintenance cost.
> > > > > >
> > > > > > By the way, you didn't say what you want to do that needs
> this level
> > > of
> > > > > > automation; if you had, it might be easier to understand your
> very
> > > strange
> > > > > > design choices and resource commitments.
> > > > > >
> > > > > > > Thanks,
> > > > > > > Giovanni
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > statsgrass mailing list
> > > > > > > [7]statsgrass at grass.itc.it
> > > > > > > [8]http://grass.itc.it/mailman/listinfo/statsgrass
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > 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: [9]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: [10]Roger.Bivand at nhh.no
> > > >
> > > >
> > >
> > >
> > > References
> > >
> > > Visible links
> > > 1. http://les-ejk.cz/?cat=pywps
> > > 2. mailto:Roger.Bivand at nhh.no
> > > 3. http://www.rpad.org/Rpad/
> > > 4. http://www.rpad.org/Rpad/InterruptionMap.Rpad
> > > 5. mailto:Roger.Bivand at nhh.no
> > > 6. http://cran.r-project.org/doc/manuals/R-exts.html
> > > 7. mailto:statsgrass at grass.itc.it
> > > 8. http://grass.itc.it/mailman/listinfo/statsgrass
> > > 9. mailto:Roger.Bivand at nhh.no
> > > 10. mailto:Roger.Bivand at nhh.no
> >
> > > _______________________________________________
> > > statsgrass mailing list
> > > statsgrass at grass.itc.it
> > > http://grass.itc.it/mailman/listinfo/statsgrass
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-stats/attachments/20061028/b9de02cf/attachment.html
More information about the grass-stats
mailing list