[Zoo-discuss] BufferPy problem
Farkas H
farkas.dus at gmail.com
Sun Dec 30 14:32:30 PST 2012
Hi Gérald,
sorry for my late answer.
I've setup the kernel with revision 381 and the updated file ogr_sp.py.
The command ".\zoo_loader.cgi.." still doesn't work with my main.cfg.
Please find the log file here [1].
However the command works if I set the GDAL_DATA variable manually (as
previously).
Please find the log file here [2].
Please find my main.cfg here [3].
I'll create an account and also will open the ticket in the next days.
Http-Post and http-Get requests for BufferPy are both ok now.
I'm a little bit confused where the server puts the referenced
response data, if I set output asReference="true".
The server response:
...
<wps:Reference href="http://localhost:80///tmp/ms_tmp/BufferPy_Result_1029
88.xml" mimeType="text/xml" encoding="UTF-8" schema="http://schemas.opengis.net/
gml/3.1.0/base/feature.xsd"/>
...
Due to this response I would suspect the data in the apache file structure.
In my case the response file should be returned in
C:\OSGeo4W\apache\htdocs\tmp\ms_tmp\...
But the file is returned in C:\tmp\ms_tmp.
If the path [Sysdrive:]\tmp\ms_tmp\ doesn't exist the process fails.
Error message: "ZOO Kernel failed to process your request receiving
signal 11 = SIGSEGV"
Is there a context to the variables in the file main.cfg?
Could you please explain the variables tmpPath, tmpUrl and dataPath in
the main.cfg.
This update also fixes the following requests: IntersectPy,
DifferencePy, SymDifferencePy.
=> http://lists.osgeo.org/pipermail/zoo-discuss/2012-November/000874.html
The function UnionPy still doesn't work. Please find the error message here [4].
Currently I'm running http-Post requests directly on the server using
the following command:
curl -H "content-type: text/xml" -d @[http-Post_request_file.xml]
http://localhost/cgi-bin/zoo_loader.cgi
How can I send http-Post requests from the client?
Thanks for your support.
I hope to hear from you.
Regards,
Farkas
[1] ------------------------
Starting service ...
2.0
ERROR 1: Unrecognised geometry type <?xml>.
/vsimem//temp10
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.
'NoneType' object has no attribute 'GetLayer'
[2] ------------------------
Starting service ...
2.0
ERROR 1: Unrecognised geometry type <?xml>.
/vsimem//temp10
[3] ------------------------
[main]
encoding = utf-8
version = 1.0.0
serverAddress = http://localhost:80/
lang = de-DE,en-CA
tmpPath = /tmp/ms_tmp/
tmpUrl = /tmp/ms_tmp
dataPath = /Data/
[identification]
title = The Zoo WPS Development Server
abstract = Development version of ZooWPS. See http://www.zoo-project.org
fees = None
accessConstraints = none
keywords = WPS,GIS,buffer
[provider]
providerName=ZOO Project
providerSite=http://www.zoo-project.org
individualName=Farkas
positionName=Developer
role=Dev
addressDeliveryPoint=False
addressCity=False
addressAdministrativeArea=False
addressPostalCode=False
addressCountry=de
addressElectronicMailAddress=farkas.dus at gmail.com
phoneVoice=False
phoneFacsimile=False
[env]
PYTHONPATH=C:\Windows\system32\python27.zip;C:\Python27\DLLs;C:\Python27\lib;C:\Python27\lib\plat-win;C:\Python27\lib\lib-tk;C:\Python27;C:\Python27\lib\site-packages
GDAL_DATA=C:\Python27\Lib\site-packages\osgeo\data\gdal
[4] ------------------------
<?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/o
ws/1.1.0/owsExceptionReport.xsd" xml:lang="en-US" version="1.1.0">
<ows:Exception exceptionCode="NoApplicableCode">
<ows:ExceptionText>TRACE : Union
<type 'exceptions.AttributeError'>
Unable to run your python process properly. Please check the following messages
: [' File "C:\\OSGeo4W\\bin\\ogr_sp.py", line 203, in UnionPy\n tres=geometr
y1[i].Union(geometry2[j])\n', ' File "C:\\Python27\\lib\\site-packages\\osgeo\\
ogr.py", line 2758, in __getattr__\n raise AttributeError(key)\n']</ows:Excep
tionText>
</ows:Exception>
</ows:ExceptionReport>
On 28 December 2012 01:14, Gérald Fenoy <gerald.fenoy at geolabs.fr> wrote:
> 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
>
More information about the Zoo-discuss
mailing list