[ZOO-Discuss] some problems with the zoo-services examples

[Gérald Fenoy]

Hi Marco,
thanks a lot for your feedbacks.

Le 22 oct. 2010 à 16:27, Marco Negretti a écrit :

> Hi,
> I installed the Zoo kernel and I guess that it works... the hello-py 
> example works.

Nice, indeed it sounds good.

> I'm trying to use the other examples in zoo-services dir but I had some 
> problems:
> 
> === gdal/translate ===
> I can't compile the service: when I launch the make command I have many 
> warning messages and this error message:
> 
> ./service.c:135: error: 'mtoupper' was not declared in this scope
> 
> Some ideas?

Sorry I missed this mtoupper call. This function disapear from the current tree. I will fix this one soon.

> 
> =======
> ogr/ogr2ogr
> I compiled the code and copied in my web server zoo dir
> Ogr2Ogr.zcfg and ogr_2_ogr_service.zo
> 
> I think that the Ogr2Ogr.zcfg is wrong:
> for example,
> line 1:        Title = Convert raster data from one format to another.
> line 21: (type of data input) : value = AAIGrid (Arc/Info ASCII Grid)
> ...and some other...
> 
> Isn't it a process for vector conversion?

You're right, it seems that we simply copy the gdal translate zcfg file here. Corrected, thanks.

> 
> I rewrited the Ogr2Ogr.zcfg, but the service doesn't work:
> <wps:ProcessFailed>
>     <ows:ExceptionReport xml:lang="en-US" version="1.1.0">
>     <ows:Exception exceptionCode="NoApplicableCode">
>         <ows:ExceptionText>No more information 
> available</ows:ExceptionText>
>         </ows:Exception>
>     </ows:ExceptionReport>
> </wps:ProcessFailed>
> 
> It's possible that I made some errors in my zcfg file, but... "No more 
> information available"
> Did someone try to use this examples?

This example was tested today and it works well. You have to know that this service will require that you set the dataPath variable in the main section of your main configuration file to the directory where your data is located. Indeed the ogr2ogr service concat the dataPath and the filename (shall be a simple filename not a path) to access the original datasource, then the service use the tmpPath to store the produced file (so this last shall also be set in the main section of your main configuration file). 

The new zcfg file was commited on the SVN source tree today. I've also modify the ogr2ogr_service code to add the specific error message when the service fails. This way we shall no more get the "No more information available" message displayed (except maybe for unhandled error :] ).

> 
> === ogr/base-vect-ops ===
> I compiled the code and copied in my web server zoo dir Buffer.zcfg and 
> ogr_service.zo.
> The service work properly, I send as input a WFS map with one polygon 
> and the service calculates the buffer, but the output is a .js file.
> 
> This is a part of service response:
> 
> <wps:ProcessOutputs>
>     <wps:Output>
>         <ows:Identifier>Result</ows:Identifier>
>         <ows:Title>Buffered Polygon</ows:Title>
>         <ows:Abstract>
>             GML stream describing the buffered polygon feature.
>         </ows:Abstract>
>         <wps:Reference href="http://localhost/tmp/Buffer_130521.js" 
> mimeType="text/plain" encoding="UTF-8"/>
>     </wps:Output>
> </wps:ProcessOutputs>
> 
> and this is an extract of the file .js with the buffer coordinates:
> { "type": "Polygon", "coordinates": [ [ [ 307875.325459, 5360132.252371 
> ], [ 307311.888640, 5360142.807357 ], [ 307309.284548, 5360142.924101 ],
> ...
>  [ 307835.808046, 5358896.308003 ], [ 307875.325459, 5360132.252371 ] ] ] }
> 
> How can I get a gml file as output?

First, you get the json string stored as an external file because the zcfg Result contains the asReference attribue set to true, you can set it to false to use the default behavior.

You can get the gml polygon stored as file simply by adding mimeType attribute to the ResponseDocument parameter and setting it to text/xml. So, you can something like : ResponseDocument=Result at mimeType=text/xml . You can even specify if you want base64 encoded string, using encoding attribute : ResponseDocument=Result at mimeType=text/xml at encoding=base64.

Note that you can get the result directly included in the Response document adding the asReference attribute to the ResponseDocument parameter and setting it to false (or true if you want to store it).

Note that in any case currently only the geometry was returned by the services so only the gml:polygon will be stored as external file. Your client shall then use the encoding, schema, mimeType and so on to know what is the format of the file it will have to open. We can re-adapt the current code to provide a full feature rather than only a geometry.

Hope to hear from you,
Best regards,

Gérald Fenoy
gerald.fenoy at geolabs.fr


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/zoo-discuss/attachments/20101023/e56c1857/attachment.html>