[Geoserver-devel] WPS DescribeProcess storeSupported

GeoServer GeoServer Developer
1

Hi,
I need to set storeSupported=true in the DescribeProcess xml response.

<wps:ProcessDescriptions xml:lang=“en” service=“WPS” version=“1.0.0” xsi:schemaLocation=“http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd”> <ProcessDescription wps:processVersion=“1.0.0” statusSupported=“false” storeSupported=“false”>
ows:Identifiergs:TranscodeRaster</ows:Identifier>
ows:Title/ows:Abstract/

With the @DescribeProcess tag in the java class implementing the process you can set the Identifier, Title and other useful xml elements, but I couldn’t find any way to set the storeSupported attribute.

Any idea?

2

On Sat, Oct 29, 2011 at 8:59 AM, Gianni Barrotta
<gianni.barrotta@anonymised.com> wrote:

Hi,
I need to set storeSupported=true in the DescribeProcess xml response.

<wps:ProcessDescriptions xml:lang="en" service="WPS" version="1.0.0"
xsi:schemaLocation="http://www.opengis.net/wps/1.0.0
http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd&quot;&gt; <ProcessDescription
wps:processVersion="1.0.0" statusSupported="false" storeSupported="false">
<ows:Identifier>gs:TranscodeRaster</ows:Identifier>
<ows:Title/><ows:Abstract/>
<DataInputs>
----------------
----------------

With the @DescribeProcess tag in the java class implementing the process you
can set the Identifier, Title and other useful xml elements, but I couldn't
find any way to set the storeSupported attribute.

Any idea?

In the current framework store support is not part of the process
responsibilites,
it's part of the WPS container responsibilities.
GeoServer WPS supports store on all requests, just fails to advertise it:
http://jira.codehaus.org/browse/GEOS-4832

I guess for processes that already generate files it would be useful to have
some facility to just use the generated file.
I guess the process could trade some specific argument type that GeoServer
treats in a special way, something that has both a reference to a file and
the knowledge of its mime type, could be something like:

class BynaryParameter {
  URL file;
  String mime;
}

But then the process should also be able to report the supported mime types.
I guess those would have to be declared in a new annotation somehow, and
then find their way up, via the GeoTools process api, into the DescribeProcess

Hmm... sounds feasible, but it would require quite a bit of changes around
in the code.

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

3

On Sat, Oct 29, 2011 at 10:33 AM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

On Sat, Oct 29, 2011 at 8:59 AM, Gianni Barrotta
<gianni.barrotta@anonymised.com> wrote:

Hi,
I need to set storeSupported=true in the DescribeProcess xml response.

<wps:ProcessDescriptions xml:lang="en" service="WPS" version="1.0.0"
xsi:schemaLocation="http://www.opengis.net/wps/1.0.0
http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd&quot;&gt; <ProcessDescription
wps:processVersion="1.0.0" statusSupported="false" storeSupported="false">
<ows:Identifier>gs:TranscodeRaster</ows:Identifier>
<ows:Title/><ows:Abstract/>
<DataInputs>
----------------
----------------

With the @DescribeProcess tag in the java class implementing the process you
can set the Identifier, Title and other useful xml elements, but I couldn't
find any way to set the storeSupported attribute.

Any idea?

In the current framework store support is not part of the process
responsibilites,
it's part of the WPS container responsibilities.
GeoServer WPS supports store on all requests, just fails to advertise it:
http://jira.codehaus.org/browse/GEOS-4832

Hmm... nope, I was wrong, in fact we have no support for store=true, so the
current behavior is correct, we don't advertise it because it's not there.

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

4

Thank’s Andrea; so we can say that the current WPS implementation does not support storing and status, that are not mandatory according to the standarda, but reccomended when managing big datasets.
I’m I wrong?
We are actually able right now to store a zip file and retrive just the url to the client (as literal data in the output stream of the servlet, I mean…); to accomplish to the Ogc Standard, we should retrive an xml whith the url embedded inside a ows:Identifierresult</ows:Identifier>; e.g.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<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:ogc=“http://www.opengis.net/ogc” 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:Identifierorg.n52.wps.server.algorithm.SimpleBufferAlgorithm</ows:Identifier>
wps:DataInputs
wps:Input
ows:Identifierdata</ows:Identifier>
<wps:Reference schema=“http://schemas.opengis.net/gml/3.1.1/base/feature.xsd” xlink:href=“http://giv-wps.uni-muenster.de:8080/geoserver/wfs?SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&TYPENAME=ns1:tasmania_roads&SRS=EPSG:4326&OUTPUTFORMAT=GML3” method=“GET”/>
</wps:Input>
wps:Input
ows:Identifierwidth</ows:Identifier>
wps:Data
<wps:LiteralData dataType=“xs:double”>0.05</wps:LiteralData>
</wps:Data>
</wps:Input>
</wps:DataInputs>
wps:ResponseForm
<wps:ResponseDocument storeExecuteResponse=“false” lineage=“false” status=“false”>
<wps:Output asReference=“true” schema=“http://schemas.opengis.net/gml/3.1.1/base/feature.xsd” mimeType=“text/xml” encoding=“UTF-8”>
ows:Identifierresult</ows:Identifier>
ows:Titleresult</ows:Title>
ows:Abstractresult</ows:Abstract>
</wps:Output>
</wps:ResponseDocument>
</wps:ResponseForm>
</wps:Execute>

So to move to the statusSupported I see two new features:

  1. add storeSupported= true to the DescribeProcess mechanism
  2. retrive the xml response with the url inside.

Am I on the right way?

On Sat, Oct 29, 2011 at 10:46 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Sat, Oct 29, 2011 at 10:33 AM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

On Sat, Oct 29, 2011 at 8:59 AM, Gianni Barrotta
<gianni.barrotta@anonymised.com872…> wrote:

Hi,
I need to set storeSupported=true in the DescribeProcess xml response.

<wps:ProcessDescriptions xml:lang=“en” service=“WPS” version=“1.0.0”
xsi:schemaLocation=“http://www.opengis.net/wps/1.0.0
http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd”>
ows:Identifiergs:TranscodeRaster</ows:Identifier>
ows:Title/ows:Abstract/

With the @DescribeProcess tag in the java class implementing the process you
can set the Identifier, Title and other useful xml elements, but I couldn’t
find any way to set the storeSupported attribute.

Any idea?

In the current framework store support is not part of the process
responsibilites,
it’s part of the WPS container responsibilities.
GeoServer WPS supports store on all requests, just fails to advertise it:
http://jira.codehaus.org/browse/GEOS-4832

Hmm… nope, I was wrong, in fact we have no support for store=true, so the
current behavior is correct, we don’t advertise it because it’s not there.

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

5

On Sat, Oct 29, 2011 at 11:04 AM, Gianni Barrotta
<giannibarrotta@anonymised.com> wrote:

Thank's Andrea; so we can say that the current WPS implementation does not
support storing and status, that are not mandatory according to the
standarda, but reccomended when managing big datasets.
I'm I wrong?

The common GeoServer way of doing streaming wps processes make it
possible to handle larger datasets even without store and status, but
dumb processes, or processes leveraging external tools, or very very
large data sets do require both asynch and store.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<wps:Execute service="WPS" version="1.0.0"
xmlns:wps="http://www.opengis.net/wps/1.0.0&quot;
xmlns:ows="http://www.opengis.net/ows/1.1&quot;
xmlns:ogc="http://www.opengis.net/ogc&quot;
xmlns:xlink="http://www.w3.org/1999/xlink&quot;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;
xsi:schemaLocation="http://www.opengis.net/wps/1.0.0
http://schemas.opengis.net/wps/1.0.0/wpsExecute_request.xsd&quot;&gt;

<ows:Identifier>org.n52.wps.server.algorithm.SimpleBufferAlgorithm</ows:Identifier>
<wps:DataInputs>
<wps:Input>
<ows:Identifier>data</ows:Identifier>
<wps:Reference
schema="http://schemas.opengis.net/gml/3.1.1/base/feature.xsd&quot;
xlink:href="http://giv-wps.uni-muenster.de:8080/geoserver/wfs?SERVICE=WFS&amp;VERSION=1.0.0&amp;REQUEST=GetFeature&amp;TYPENAME=ns1:tasmania_roads&amp;SRS=EPSG:4326&amp;OUTPUTFORMAT=GML3&quot;
method="GET"/>
</wps:Input>
<wps:Input>
<ows:Identifier>width</ows:Identifier>
<wps:Data>
<wps:LiteralData dataType="xs:double">0.05</wps:LiteralData>
</wps:Data>
</wps:Input>
</wps:DataInputs>
<wps:ResponseForm>
<wps:ResponseDocument storeExecuteResponse="false" lineage="false"
status="false">
<wps:Output asReference="true"
schema="http://schemas.opengis.net/gml/3.1.1/base/feature.xsd&quot;
mimeType="text/xml" encoding="UTF-8">
<ows:Identifier>result</ows:Identifier>
<ows:Title>result</ows:Title>
<ows:Abstract>result</ows:Abstract>
</wps:Output>
</wps:ResponseDocument>
</wps:ResponseForm>
</wps:Execute>

So to move to the statusSupported I see two new features:
1) add storeSupported= true to the DescribeProcess mechanism
2) retrive the xml response with the url inside.

Am I on the right way?

To declare status supported = true or store supported = true
one has actually to make changes to the way the WPS works,
it's not just a matter of changing storeSupported=true,
there is a lot of work to be done.

Mind, if you look at the other WPS threads in the devel list
you should already know I'm about to add asynch execution
support, which also implies store support.

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

6

Yes, I see.
Let me know how to contribute to this feature.

Regards,
Gianni.

On Sat, Oct 29, 2011 at 11:34 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Sat, Oct 29, 2011 at 11:04 AM, Gianni Barrotta
<giannibarrotta@anonymised.com> wrote:

Thank’s Andrea; so we can say that the current WPS implementation does not
support storing and status, that are not mandatory according to the
standarda, but reccomended when managing big datasets.
I’m I wrong?

The common GeoServer way of doing streaming wps processes make it
possible to handle larger datasets even without store and status, but
dumb processes, or processes leveraging external tools, or very very
large data sets do require both asynch and store.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<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:ogc=“http://www.opengis.net/ogc”
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:Identifierorg.n52.wps.server.algorithm.SimpleBufferAlgorithm</ows:Identifier>
wps:DataInputs
wps:Input
ows:Identifierdata</ows:Identifier>
<wps:Reference
schema=“http://schemas.opengis.net/gml/3.1.1/base/feature.xsd”
xlink:href=“http://giv-wps.uni-muenster.de:8080/geoserver/wfs?SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&TYPENAME=ns1:tasmania_roads&SRS=EPSG:4326&OUTPUTFORMAT=GML3”
method=“GET”/>
</wps:Input>
wps:Input
ows:Identifierwidth</ows:Identifier>
wps:Data
<wps:LiteralData dataType=“xs:double”>0.05</wps:LiteralData>
</wps:Data>
</wps:Input>
</wps:DataInputs>
wps:ResponseForm
<wps:ResponseDocument storeExecuteResponse=“false” lineage=“false”
status=“false”>
<wps:Output asReference=“true”
schema=“http://schemas.opengis.net/gml/3.1.1/base/feature.xsd”
mimeType=“text/xml” encoding=“UTF-8”>
ows:Identifierresult</ows:Identifier>
ows:Titleresult</ows:Title>
ows:Abstractresult</ows:Abstract>
</wps:Output>
</wps:ResponseDocument>
</wps:ResponseForm>
</wps:Execute>

So to move to the statusSupported I see two new features:

  1. add storeSupported= true to the DescribeProcess mechanism
  2. retrive the xml response with the url inside.

Am I on the right way?

To declare status supported = true or store supported = true
one has actually to make changes to the way the WPS works,
it’s not just a matter of changing storeSupported=true,
there is a lot of work to be done.

Mind, if you look at the other WPS threads in the devel list
you should already know I’m about to add asynch execution
support, which also implies store support.

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

7

On Sun, Oct 30, 2011 at 9:26 AM, Gianni Barrotta
<giannibarrotta@anonymised.com> wrote:

Yes, I see.
Let me know how to contribute to this feature.

I could use some testing once the code is done, both in terms of checking the
implementation satisfies the spec (which has more or less just one paragraph
on the topic) and that it works as expected with common process calls.

Another useful thing could be to patch the existing processes (at least some of
them) to take a ProgressListener argument and have them report progress
and eventually support cancellation.

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

8

I could use some testing once the code is done, both in terms of checking the
implementation satisfies the spec (which has more or less just one paragraph
on the topic) and that it works as expected with common process calls.

In the Briseide project we are using the 53North WPS Orchestration, which satisfies the standard on status and store; I think could be a good way to test this new feature of geoserver wps.

Another useful thing could be to patch the existing processes (at least some of
them) to take a ProgressListener argument and have them report progress
and eventually support cancellation.

We can start with all the processes working on raster data (like FeatureExtraction, RasterAlgebra or GeorectifyCoverage,…).

Cheers,

Gianni.

On Sun, Oct 30, 2011 at 9:39 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Sun, Oct 30, 2011 at 9:26 AM, Gianni Barrotta
<giannibarrotta@anonymised.com> wrote:

Yes, I see.
Let me know how to contribute to this feature.

I could use some testing once the code is done, both in terms of checking the
implementation satisfies the spec (which has more or less just one paragraph
on the topic) and that it works as expected with common process calls.

Another useful thing could be to patch the existing processes (at least some of
them) to take a ProgressListener argument and have them report progress
and eventually support cancellation.

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf