Hi
I'm really not gml expert - happy, when my tools are able to read the
file, I give to them,
but maybe OpenLayers-devs (forwarding) would have some idea about this
issue?
Jachym
On 24.9.2011 22:30, Markus Schneider wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
BTW,
what do you think about OpenLayers sending gml:featureMembers as the
root element of the input parameter?
IMHO, this is rather bad GML practice, as it basically starts in the
middle of a GML encoded object.
I would prefer if the GML payload could be a complete FeatureCollection
with a surrounding element. I think this should improve interoperability
with WPS implementations / processes that use full-blown (and more
restrictive) GML parsers.
Best regards,
Markus
Am 24.09.2011 22:20, schrieb Jachym Cepicky:
Hi,
I had similar problem in PyWPS, so I can understand that issue. I"ll try
to have a look at that issue.
Just for the record, original author of OpenLayers.Format.WPS* is Bart
van den Eijnden, I'm working on the gui right now (ExtJS 3.x)
jachym
On 24.9.2011 22:15, Markus Schneider wrote:
Hi Jachym,
thanks for the quick response.
I found the reason for the problem with deegree. When validating the
request in Eclipse, it returns
The content of element 'wps:ResponseForm' is not complete. One of
'{"http://www.opengis.net/wps/1.0.0":ResponseDocument,
"http://www.opengis.net/wps/1.0.0":RawDataOutput}' is expected.
If the empty ResponseDocument element is omitted from the request, it
works fine (it's optional in the schema). Alternatively, one can specify
the mandatory ResponseForm child elements:
...
<wps:ResponseForm>
<wps:ResponseDocument>
<wps:Output>
<ows:Identifier
xmlns:ows="http://www.opengis.net/ows/1.1";>BufferedGML</ows:Identifier>
</wps:Output>
</wps:ResponseDocument>
</wps:ResponseForm>
...
Best regards and thanks for your work on the client (will have a look as
soon as I find the time),
Markus
P.S.: If a request doesn't work, deegree usually provides hints in the
ExceptionReport that point to the cause of the problem. For the original
request, it returns:
<?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";
xsi:schemaLocation="http://www.opengis.net/ows/1.1
http://schemas.opengis.net/ows/1.1.0/owsExceptionReport.xsd";
version="1.1.0">
<ows:Exception exceptionCode="NoApplicableCode">
<ows:ExceptionText> At least one of following parameters is
required
but missing: [{http://www.opengis.net/wps/1.0.0}ResponseDocument,
{http://www.opengis.net/wps/1.0.0}RawDataOutput].</ows:ExceptionText>
</ows:Exception>
</ows:ExceptionReport>
Am 24.09.2011 21:26, schrieb Jachym Cepicky:
Execute request attached (I suppose, something will be misconfigured at
the client side, so please let me know)
Tested on
http://85.25.95.86:8080/wps-bakeoff-2011/services
and
http://geoprocessing.demo.52north.org:8081/wps/WebProcessingService
Jachym
On 24.9.2011 21:21, Markus Schneider wrote:
Hi Jachym,
cool news!
I would like to understand what's wrong with deegree here (and maybe
it's even the same with 52 North). Could you send me the XML Execute
request that fails?
Best regards,
Markus
Am 24.09.2011 03:26, schrieb Jachym Cepicky:
Hi,
I have written simple test page, which will test the new
OpenLayers.Format.WPS* classes on each server, I have access to. Here
are some results.
So far, tested only Deegree, 52North, Geoserver and Zoo (I know their
public address), PyWPS (I have it on localhost, public server does
not
work now).
Results:
========
GetCapabilities: all passed
DescribeProcess (buffer): all passed
Execute (gml 3.1 input):
pywps and zoo did well,
geoserver returned correct exception (expecting Geometry, not
Feature),
52North and Deergree failed (Error 500)
I think, that is great result!
Hints:
======
Geoserver
---------
Why do you accept only geometry, not FeatureMember as input ?
Deegree and 52north
-------------------
I have no idea, why I got HTTP Error 500: Internal Server Error
you can see the input POST execute request in firebug, when you
run the
test
the problem can be also on OpenLayers side
Howto
=====
1) Copy the attached document to OpenLayers (2.11+)
examples/directory
2) adjust OpenLayers.ProxyHost (at the beginning of the "init"
function)
to where your script lives
3) open in firefox, open firebug (or equivalent tools), hit the
button
and watch
4), Oh, I nearly forgot to mention, you need to fix one small
issue in
OpenLayers, patch attached
http://trac.osgeo.org/openlayers/ticket/3517
We can now drop support for pywps/WPS.js :-) Let there be only the
*one*
OpenLayers-based WPS client.
Jachym
_______________________________________________
WPS-dev mailing list
wps-...@lists.opengeospatial.org
https://lists.opengeospatial.org/mailman/listinfo/wps-dev
_______________________________________________
WPS-dev mailing list
wps-...@lists.opengeospatial.org
https://lists.opengeospatial.org/mailman/listinfo/wps-dev
- --
Markus Schneider
l a t / l o n GmbH
Aennchenstrasse 19 53177 Bonn, Germany
phone ++49 +228 184960 fax ++49 +228 1849629
http://www.lat-lon.de http://www.deegree.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk5+PeAACgkQLM5hjXxU/E7s9wCdFeQ9ed9/JMec0voxbAvW8s+r
sqAAoIC4isdSTJqFBJljcVQxIqtksJvh
=gJjt
-----END PGP SIGNATURE-----
_______________________________________________
Dev mailing list
d...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/openlayers-dev
