[Zoo-discuss] BufferPy problem

Thu Dec 27 16:14:15 PST 2012

Dear Farkas,
Thanks a lot for your feedbacks.

it seems strange to me that the GDAL_DATA settings in the [env] section is not working. Can you share with us your main.cfg file ?
Maybe you can open a ticket in the Trac system [1] and then attache a file to the ticket ?

For the issue about timeout when using POST requests, can you try again with a brand new ZOO-Kernel using the current SVN trunk please ? It should work with revision 381 ([2]).
If the problem still occur for GET request, can you please provide an example URLs you used ?

You may try to update to the new version of base-vector-ops-py available from revision 382 [3] but it should work with old one too.

The number of vertices depends on libraries used from the service.

To add debugging messages in the service  code you just need to add some lines like : "print >> sys.stderr,'My message'" then look into the apache error_log to make sure they appear.

Hope to hear back from you,
Best regards,

[1] http://zoo-project.org/trac/newticket
[2] http://zoo-project.org/trac/changeset/381
[3] http://zoo-project.org/trac/changeset/382

Gérald Fenoy
gerald.fenoy at geolabs.fr

Le 27 déc. 2012 à 16:08, Farkas H <farkas.dus at gmail.com> a écrit :

> Hi Gérald,
> 
> thank you for your quick response.
> 
> I found one problem.
> The [env] GDAL_DATA variable in the main.cfg is not recognized properly.
> 
> You can find the error messages after executing the buffer request via
> cmd ".\zoo_loader.cgi ..." here [1].
> The error messages of the .log file you can find here [2].
> 
> I've deleted the GDAL_DATA in the main.cfg and I've set the variable
> globally in Windows or in cmd.
> After that the buffer request of the topp:states layer works via cmd
> (.\zoo_loader.cgi ...).
> But there is still the following error at the end of the log file:
> 
> ERROR 1: Unrecognised geometry type <?xml>.
> This error also affects other requests (CentroidPy, ConvexHullPy, ...).
> 
> 
> The buffer request of the topp:states layer is still timed out via
> http-Get or via http-Post.
> The error occures with and without caching. The cache files are ok.
> The apache user can access the cache files.
> 
> Besides that I'm wondering that the buffer features have about ten
> times more vertices than the original features.
> Is there an explanation for that?
> 
> Could you give me an example how I can add debugging information to
> the Python script.
> 
> Hope to hear from you.
> 
> Regards,
> Farkas
> 
> [1]
> ERROR 1: Unrecognised geometry type <?xml>.
> ERROR 4: Unable to open EPSG support file gcs.csv.
> Try setting the GDAL_DATA environment variable to point to the
> directory containing EPSG csv files.
> Unable to load file input data !!!
> 
> [2]
> Content-Type: text/xml; charset=utf-8
> Status: 200 OK
> 
> <?xml version="1.0" encoding="utf-8"?>
> <ows:ExceptionReport xmlns:ows="http://www.opengis.net/ows/1.1"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:xlink="http://www.w3.org/1999/xlink"
> xsi:schemaLocation="http://www.opengis.net/ows/1.1
> http://schemas.opengis.net/ows/1.1.0/owsExceptionReport.xsd"
> xml:lang="en-US" version="1.1.0">
>  <ows:Exception exceptionCode="NoApplicableCode">
>    <ows:ExceptionText>TRACE : object of type 'NoneType' has no len()
> <type 'exceptions.TypeError'>
> Unable to run your python process properly. Please check the following
> messages : ['  File "C:\\OSGeo4W\\bin\\ogr_sp.py", line 103, in
> BufferPy\n    while i < len(geometry):\n']</ows:ExceptionText>
>  </ows:Exception>
> </ows:ExceptionReport>
> 
> 
> 
> On 26 December 2012 17:44, Gérald Fenoy <gerald.fenoy at geolabs.fr> wrote:
>> Dear Farkas,
>> merry Christmas, I think you should try running to run the same request from the command line directly by running cmd, then change directory to the ZOO-Kernel path and run the following command :
>> 
>> .\zoo_loader.cgi "<YOUR_REQUEST>" 2> log
>> 
>> Note that you may also add some debugging messages at each steps (for each geometry treated by the service) in the python script to get more information. Did you take a look at the cache file ? Is it correct / valid ? In other case you may try to remove the file then try again the same query. Does the apache user get the right to access the cache file ?
>> 
>> At the first step I thought it was only a timeout issue following log messages you provided, sorry I made a mistake here. The issue seems to come from another place. But I really think better to first check the cache file.
>> 
>> Hope to hear back from you and to be able to support you next time.
>> 
>> Best regards
>> 
>> Gérald Fenoy
>> gerald.fenoy at geolabs.fr
>> 
>> Le 25 déc. 2012 à 22:34, Farkas H <farkas.dus at gmail.com> a écrit :
>> 
>>> Hi Gérald,
>>> 
>>> first I want to wish you a merry Christmas.
>>> Thank you for your response.
>>> 
>>> For this test I used zoo-kernel from 2012-12-18 without any further
>>> developments.
>>> The response time on the client side for calculating seven buffers for
>>> the topp:tasmania_water_bodies layer from http://demo.opengeo.org
>>> takes about three seconds via HSDPA without caching. There is no
>>> timeout variable set in the httpd.conf file during OSGeo4W
>>> installation. The standard apache timeout is five minutes. The
>>> response time for calculating 49 buffers for the topp:states layer
>>> from the same server should take less than five minutes. What do you
>>> mean?
>>> 
>>> Even after I've set the timeout variable to 3600 [seconds] (60
>>> minutes) I got no response.
>>> 
>>> When the tiemout was reached (after 5 or 60 minutes) I got the
>>> following error message in the OSGeo4W apache log file:
>>> "Script timed out before returning headers: zoo_loader.cgi".
>>> I think the problem is not the server timeout.
>>> 
>>> Thank you for your occasional support.
>>> 
>>> Regards,
>>> Farkas
>>> 
>>> 
>>> On Dec 23, 2012 12:01 PM, "Gérald Fenoy" <gerald.fenoy at geolabs.fr> wrote:
>>>> 
>>>> Hi Farkas,
>>>> I guess that the issue doesn't come from the ZOO-Kernel itself but from the configuration of your web server which return a timeout.
>>>> 
>>>> It should simply mean that the web server consider that the ZOO-Kernel took too much time to handle the request. Which may be the case when you are using huge dataset. You should take a look into your web server configuration to fix this issue.
>>>> 
>>>> Hope you can confirm that the issue can be solved by setting longer timeout limit in your webserver configuration.
>>>> Best regards,
>>>> 
>>>> Gérald Fenoy
>>>> gerald.fenoy at geolabs.fr
>>>> 
>>>> Le 20 déc. 2012 à 21:52, Farkas H <farkas.dus at gmail.com> a écrit :
>>>> 
>>>>> Hi everyone,
>>>>> 
>>>>> this http-Post buffer request [1] (BufferPy, buffers around features
>>>>> from layer topp:tasmania_water_bodies, 7 features) works.
>>>>> If I change the layer to topp:states (49 features) the request doesn't
>>>>> work [2]. You find the error message here [3].
>>>>> If I buffer just one feature from the states layer the request works
>>>>> [4]. Every single feature works.
>>>>> 
>>>>> I've noticed this behavior in other layers. One feature works the
>>>>> whole layer doesn't work.
>>>>> It looks like that the request from a certain number of objects does
>>>>> not work anymore.
>>>>> 
>>>>> What's wrong?
>>>>> 
>>>>> I appreciate any advice.
>>>>> 
>>>>> Regards,
>>>>> Farkas
>>>>> 
>>>>> [1]
>>>>> <wps:Execute service="WPS" version="1.0.0"
>>>>> xmlns:wps="http://www.opengis.net/wps/1.0.0"
>>>>> xmlns:ows="http://www.opengis.net/ows/1.1"
>>>>> xmlns:xlink="http://www.w3.org/1999/xlink"
>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>>> xsi:schemaLocation="http://www.opengis.net/wps/1.0.0
>>>>> http://schemas.opengis.net/wps/1.0.0/wpsExecute_request.xsd">
>>>>> <ows:Identifier>BufferPy</ows:Identifier>
>>>>> <wps:DataInputs>
>>>>> <wps:Input>
>>>>> <ows:Identifier>InputPolygon</ows:Identifier>
>>>>> <ows:Title>water bodies</ows:Title>
>>>>> <wps:Reference xlink:href="http://demo.opengeo.org/geoserver/ows?Request=GetFeature&Service=WFS&Version=1.0.0&Typename=topp:tasmania_water_bodies"/>
>>>>> </wps:Input>
>>>>> <wps:Input>
>>>>> <ows:Identifier>BufferDistance</ows:Identifier>
>>>>> <ows:Title>Emergency area.</ows:Title>
>>>>> <wps:Data>
>>>>> <wps:LiteralData>0.01</wps:LiteralData>
>>>>> </wps:Data>
>>>>> </wps:Input>
>>>>> </wps:DataInputs>
>>>>> <wps:ResponseForm>
>>>>> <wps:ResponseDocument storeExecuteResponse="false">
>>>>> <wps:Output asReference="true">
>>>>> <ows:Identifier>Result</ows:Identifier>
>>>>> </wps:Output>
>>>>> </wps:ResponseDocument>
>>>>> </wps:ResponseForm>
>>>>> </wps:Execute>
>>>>> 
>>>>> [2]
>>>>> ...
>>>>> <wps:Reference xlink:href="http:...;Typename=topp:states"/>
>>>>> ...
>>>>> 
>>>>> [3]
>>>>> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
>>>>> <html><head>
>>>>> <title>504 Gateway Time-out</title>
>>>>> </head><body>
>>>>> <h1>Gateway Time-out</h1>
>>>>> <p>The gateway did not receive a timely response
>>>>> from the upstream server or application.</p>
>>>>> </body></html>
>>>>> 
>>>>> [4]
>>>>> ...
>>>>> <wps:Reference xlink:href="http:...;Typename=topp:states&FeatureID=states.1"/>
>>>>> ...
>>>>> _______________________________________________
>>>>> Zoo-discuss mailing list
>>>>> Zoo-discuss at lists.osgeo.org
>>>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/zoo-discuss
>>>> 
>>> _______________________________________________
>>> Zoo-discuss mailing list
>>> Zoo-discuss at lists.osgeo.org
>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/zoo-discuss
>> 
> _______________________________________________
> Zoo-discuss mailing list
> Zoo-discuss at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/zoo-discuss