[ZOO-Discuss] ZOO OnGoing Project : The Laurent Jégou Blog story

[nicolas bozon]

Hi all,

Yes ReLuc, we will publish the OGR demo and others shortly
This will be included in the zoo project website update

Cheers

Nick


2010/1/9 René-Luc D'Hont <rldhont at gmail.com>

>  Hi All,
>
> This story is a very good point to demonstrate the ZOO capabilities!
>
> Could we publish the ZOO OGR demo ?
>
> René-Luc D'Hont
> 3Liz
>
> Le 09/01/2010 02:28, Gérald Fenoy a écrit :
>
> Hi ZOO Tribe member,
> I have a story to share with you.
>
>
> -----------------------------------------
> Today, in the cold of France, *somebody* called me on phone and tell me
> that Lourent Jégou wrote an article on his blog [1] about using R with
> pyWPS.
> Laurent also mentioned that he did this choice, using pyWPS, cause ZOO
> Kernel is still unavailable (I use ZOO Kernel here, even if he spoke about
> "Zoo", in fact he means ZOO Kernel here). Oups, sorry for this point.
> So, *somebody* send me the link [2], unfortunately I wasn't in front of my
> computer so unable to read anything :). I asked him if the python code
> quoted in the article was available or not. As, he answered me it was, I
> told him that I call him back to tell him when the process was modified to
> be used from the ZOO Kernel.
>
> So I gone back on my computer and check this web page, fethcing the python
> code then copying the logic only included in the python file from the
> article  (no metadata, as metadata and logic is separated in ZOO Kernel).
>
> Here "the logic code" I talk about was pointed in the full ServiceProvider,
> providing only one service called discretise :
>
> import rpy2.robjects as robjects
> import sys
>
> def discretise(main,inputs,outputs):
>        # the following lines are need only because of
>        # strange issue specific to R displaying msg :
>        # Loading required package: class
>        try:
>                sys.stdout.close()
>        except:
>                pass
>        # The logic code
>        robjects.r('library(e1071)')
>        robjects.r('library(classInt)')
>        robjects.r('library(XML)')
>        robjects.r('data(jenks71)')
>        robjects.r('doc = xmlRoot(xmlTreeParse("%s"))' %
> inputs['donnees']['value'])
>        xsa = robjects.r.xmlSApply
>        jenksData = robjects.r('xmlSApply(doc, function(x)
> as.numeric(xmlSApply(x, xmlValue)))')
>        ci = robjects.r.classIntervals
>        tmp=int(inputs['nbClasses']['value'])
>        out = str(ci(jenksData, n = tmp, style =
> inputs['methode']['value']))
>        outputs["Result"]={"value": out,"dataType":"string"}
>        return 3
>
>
> Then I copied the hellof.zcfg metadata file (the ZOO Configuration File for
> the sample Fortran ServiceProvider) into a new one called discretise.zcfg. I
> tested ... it and it works :)
> In fact it shuldn't work but I know that ZOO Kernel is really permissive
> when passing arguments to ServiceProvider function.... This explains why the
> hellof.zcfg file was enough to run the process... Nevertheless, in some
> sens, that let devs make their tests on their new service provider before
> putting them publicly available all over the web..
> So I correct a bit the ZOO Configuration file to get a realistic
> DescribeProcess.
>
> Finally, few minutes was requested to turn a simple pyWPS service into a
> service from a ServiceProvider Python Based to be run from the ZOO Kernel. I
> called back *somebody* :)
>
> I know it's not such an interesting example, but it let me think that the
> ZOO Kernel is a good tool to easily use an already existing code as a WPS
> service, even if it was not (a service) at the begining. Please, correct me
> if I'm wrong.
>
> So, even if here we duplicated a WPS service to create a new one,
> comparison between two solutions can be easily made for everyone reading
> this story. It contains also a view about what have to be done to integrate
> your own  (Python here) code as a ServiceProvider providing WPS services
> through ZOO Kernel.
>
> Separation between metadata and services as a staring point, multi-language
> support in an embedded way to take control over service to provide.
>
> Parameters storeExecuteResponse was supported since the begining of ZOO
> Kernel development (cf. hello worlds from various embedded languages [3],
> [4] and [5]). It let users decide if they want to store the ExecuteResponse
> (on the current demonstration server we remove files quickly) to let him
> fetch/poll the statusLocation provided in the execute answer from its client
> application to show status of execution and be informed when the process was
> ended. It can be useful for applcication using a cache or something.
>
> -----------------------------------------
>
> [1] http://www.geotests.net/blog/
> [2]
> http://www.geotests.net/blog/article/mise-en-place-d-un-webservice-de-discretisation-en-utilisant-pywps-et-r
> [3]
> http://demo.zoo-project.org/zoo/?request=Execute&service=WPS&version=1.0.0&Identifier=hellof&DataInputs=S=Your%20Name%20Here@datatype=string&storeExecuteResponse=true
> [4]
> http://demo.zoo-project.org/zoo/?request=Execute&service=WPS&version=1.0.0&Identifier=HelloWorldJava&DataInputs=S=Your%20Name%20Here@datatype=string&storeExecuteResponse=true
> [5]
> http://demo.zoo-project.org/zoo/?request=Execute&service=WPS&version=1.0.0&Identifier=HelloPHP&DataInputs=S=Your%20Name%20Here@datatype=string&storeExecuteResponse=true
>
> -----------------------------------------
>
> *somebody* was abviously Nick !
>
> Hope to hear from you ZOO Tribe members,
>
>
> Djay
> Just a ZOO Monkey
> gerald.fenoy at geolabs.fr
>
>
> _______________________________________________
> Zoo-discuss mailing listZoo-discuss at gisws.media.osaka-cu.ac.jphttp://gisws.media.osaka-cu.ac.jp/mailman/listinfo/zoo-discuss
>
>
>
> _______________________________________________
> Zoo-discuss mailing list
> Zoo-discuss at gisws.media.osaka-cu.ac.jp
> http://gisws.media.osaka-cu.ac.jp/mailman/listinfo/zoo-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/zoo-discuss/attachments/20100109/28683ab5/attachment.html>