Closed sbalasub closed 10 years ago
My guess here is that this is a very slow process. I can see that the request is still pending.
@dwins @volaya can either of you confirm this is a slow process or not? If it is, I guess we should leave it out of our testing since we're not doing async processes here anyway.
Looks like it should actually be pretty fast, it adapts the raster to the feature collection interface rather than building any intermediate data structure. I'll try it out on my machine and see if I can get any better insight.
I tested against some of the tiny rasters from GeoServer's sample data and the response was pretty much instantaneous. There is an issue if the raster band names are not valid XML tag names but you get an error report in that situation.
Maybe the error is specific to the data that you were using? Could I get access to that?
I just forwarded the data @dwins by e-mail to you
Yes, on my machine it returns almost instantly with the dem25 dataset as well. So possibly it is an intermittent error with the machine Sudha is using for testing, or maybe it is a bug that has been fixed between that version and geoserver master. I think we should wait a bit and see if it recurs with the branch we set up for phase4.
your proposal makes sense @dwins thanks for checking this
On second thought, maybe it is just that the request should be for a smaller region. On a local connection it takes almost 2 minutes to receive the full response to that one. If nothing is displayed on the client until the full response is received and parsed I could see how Sudha might think there was a problem.
$ curl http://localhost:8080/geoserver/wps -Hcontent-type:application/xml -d@rasteraspointcollection.xml -v > /dev/null
* Adding handle: conn: 0x21d6fa0
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x21d6fa0) send_pipe: 1, recv_pipe: 0
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* About to connect() to localhost port 8080 (#0)
* Trying ::1...
* Connected to localhost (::1) port 8080 (#0)
> POST /geoserver/wps HTTP/1.1
> User-Agent: curl/7.32.0
> Host: localhost:8080
> Accept: */*
> content-type:application/xml
> Content-Length: 1412
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
} [data not shown]
< HTTP/1.1 200 OK
* Server Apache-Coyote/1.1 is not blacklisted
< Server: Apache-Coyote/1.1
< Content-Disposition: inline; filename=result.xml; subtype=wfs-collection
< Content-Type: text/xml; subtype=wfs-collection/1.1
< Transfer-Encoding: chunked
< Date: Wed, 08 Oct 2014 18:22:32 GMT
<
{ [data not shown]
100 130M 0 130M 100 1412 1230k 12 0:01:57 0:01:48 0:00:09 914k
* Connection #0 to host localhost left intact
That process basically creates one point for each cell in the raster layer, so if the layer is rather big, the process will be fast (the algorithm is not complex at all), but sending the data later can take quite a while. Maybe trying with a different layer resolution will provide a quicker response.
However, i insist that this is not what we have to test for the wps-gui. We do not have to test every geoserver process, but instead the wps chaining stuff. We should not spend time on this.
agreed @volaya so let's close this one then
@volaya @bartvde I agree the focus should be on the gui but unless I tested everything or most of it, cannot rule out all client side issues / bugs.
Request Payload:
No response gets returned.