Hi there. I just submitted a patch with some basic WPS docs.
http://jira.codehaus.org/browse/GEOS-4350
To make it easier for people to read (and to see the graphics), I committed this first draft on 2.1.x. It should show up here after the next nightly build:
http://docs.geoserver.org/stable/en/user/extensions/wps/index.html
Feedback appreciated.
Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org
On Wed, Feb 2, 2011 at 2:15 AM, Mike Pumphrey <mike@anonymised.com> wrote:
Hi there. I just submitted a patch with some basic WPS docs.
http://jira.codehaus.org/browse/GEOS-4350
To make it easier for people to read (and to see the graphics), I committed this first draft on 2.1.x. It should show up here after the next nightly build:
http://docs.geoserver.org/stable/en/user/extensions/wps/index.html
Feedback appreciated.
A few notes:
- "the names of processes are case sensitive". Actually in OGC style
request that is normal,
all keys are case insenstive, all values are case sensitive. Process
names are no exception,
just like feature type names, coverage names, and wms layer names
- the buffer in the example returns a square... correct answer given
the params, but a little
outside what one would expect from a buffer operation
- in the geoserver processes paragraph you say "These functions have
the added bonus
of being able to operate on existing layers in GeoServer, and can
even write the output
to a new GeoServer layer".
Actually any process can work against existing GS layers, it just
needs to be able to
consume a feature collection or a grid coverage. And not even that
in some cases, the
JTS processes can feed off the GS layers via the internal WFS
request if that one is
chained in gs:CollectGeometries which turns the feature collection
into a single geometry
(it collects everything into a big multi-geometry)
- the trick GS uses to get data off the internal WFS/WCS is to use a special URL
for the wfs/wcs server, http://geoserver/wfs and
http://geoserver/wcs (if memory
serves me right) and that part is just a GS convention, it's not
anything that is
part of the standard
- that said GS can feed off any remote WFS/WCS just fine (provided the chosen
output format can be parsed by GS), and in general, but any remote call
whatsoever that returns something parseable (it might be a php
script returning GML
for example)
Cheers
Andrea
--
Ing. Andrea Aime
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584962313
fax: +39 0584962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-----------------------------------------------------
Thanks for the notes, Andrea, this is super helpful. Follow-ups, below.
all keys are case insenstive, all values are case sensitive.
Okay, but I do see that service=WPS works as well as service=wps. Just GeoServer being nice, though, I guess.
- the buffer in the example returns a square... correct answer given the params, but a little
outside what one would expect from a buffer operation
I was looking for an example that would be simple to understand from just looking at the coordinates. If I had created a circle (or polygon equivalent), it might be more real world, but the numbers might not be so understandable. But I could change the example, though, if you thought it valuable. It was just the first process I came up with.
Also, found it interesting that as is, the values were like -10.00000000067 instead of -10.0. 
- in the geoserver processes paragraph you say "These functions have the added bonus
of being able to operate on existing layers in GeoServer, and can even write the output
to a new GeoServer layer".
Actually any process can work against existing GS layers, it just
...
Okay. How should I categorize the differences between the gs: and the JTS: processes? (Or is there no important distinction?) I saw that the request builder had an extra entry for VECTOR_LAYER on the gs: processes, which is why I made the note.
- the trick GS uses to get data off the internal WFS/WCS is to use a special URL
for the wfs/wcs server, http://geoserver/wfs and
http://geoserver/wcs (if memory
serves me right) and that part is just a GS convention, it's not
anything that is
part of the standard
Okay, I'll make a note of that.
- that said GS can feed off any remote WFS/WCS just fine (provided the chosen
output format can be parsed by GS), and in general, but any remote call
whatsoever that returns something parseable (it might be a php
script returning GML
for example)
I'm pretty sure I follow this, but if an example lived somewhere it would be great to see it.
Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org
On 2/2/2011 4:43 AM, Andrea Aime wrote:
On Wed, Feb 2, 2011 at 2:15 AM, Mike Pumphrey<mike@anonymised.com> wrote:
Hi there. I just submitted a patch with some basic WPS docs.
http://jira.codehaus.org/browse/GEOS-4350
To make it easier for people to read (and to see the graphics), I committed this first draft on 2.1.x. It should show up here after the next nightly build:
http://docs.geoserver.org/stable/en/user/extensions/wps/index.html
Feedback appreciated.
A few notes:
- "the names of processes are case sensitive". Actually in OGC style
request that is normal,
all keys are case insenstive, all values are case sensitive. Process
names are no exception,
just like feature type names, coverage names, and wms layer names
- the buffer in the example returns a square... correct answer given
the params, but a little
outside what one would expect from a buffer operation
- in the geoserver processes paragraph you say "These functions have
the added bonus
of being able to operate on existing layers in GeoServer, and can
even write the output
to a new GeoServer layer".
Actually any process can work against existing GS layers, it just
needs to be able to
consume a feature collection or a grid coverage. And not even that
in some cases, the
JTS processes can feed off the GS layers via the internal WFS
request if that one is
chained in gs:CollectGeometries which turns the feature collection
into a single geometry
(it collects everything into a big multi-geometry)
- the trick GS uses to get data off the internal WFS/WCS is to use a special URL
for the wfs/wcs server, http://geoserver/wfs and
http://geoserver/wcs (if memory
serves me right) and that part is just a GS convention, it's not
anything that is
part of the standard
- that said GS can feed off any remote WFS/WCS just fine (provided the chosen
output format can be parsed by GS), and in general, but any remote call
whatsoever that returns something parseable (it might be a php
script returning GML
for example)Cheers
Andrea
On Wed, Feb 2, 2011 at 8:02 PM, Mike Pumphrey <mike@anonymised.com> wrote:
Thanks for the notes, Andrea, this is super helpful. Follow-ups, below.
all keys are case insenstive, all values are case sensitive.
Okay, but I do see that service=WPS works as well as service=wps. Just GeoServer being nice, though, I guess.
Yep, that's my understanding as well.
- the buffer in the example returns a square... correct answer given the params, but a little
outside what one would expect from a buffer operationI was looking for an example that would be simple to understand from just looking at the coordinates. If I had created a circle (or polygon equivalent), it might be more real world, but the numbers might not be so understandable. But I could change the example, though, if you thought it valuable. It was just the first process I came up with.
Yeah, a circle would be made of a lot of coordinates. No biggie.
Also, found it interesting that as is, the values were like -10.00000000067 instead of -10.0.
- in the geoserver processes paragraph you say "These functions have the added bonus
of being able to operate on existing layers in GeoServer, and can even write the output
to a new GeoServer layer".
Actually any process can work against existing GS layers, it just...
Okay. How should I categorize the differences between the gs: and the JTS: processes? (Or is there no important distinction?) I saw that the request builder had an extra entry for VECTOR_LAYER on the gs: processes, which is why I made the note.
JTS processes are made to expose jts capabilities and work on single geomtries.
GS processes... are all over the place, they do pretty much everything now.
There is a number of them that is specific to GS though, such as gs:Import
VECTOR_LAYER is something every process consuming feature collection will
have.
- the trick GS uses to get data off the internal WFS/WCS is to use a special URL
for the wfs/wcs server, http://geoserver/wfs and
http://geoserver/wcs (if memory
serves me right) and that part is just a GS convention, it's not
anything that is
part of the standardOkay, I'll make a note of that.
- that said GS can feed off any remote WFS/WCS just fine (provided the chosen
output format can be parsed by GS), and in general, but any remote call
whatsoever that returns something parseable (it might be a php
script returning GML
for example)I'm pretty sure I follow this, but if an example lived somewhere it would be great to see it.
Don't have stuff handy now (I'm stuck in bed with fever and the
notebook does not
have everything I need in working order) I'll try to look up more
examples when I get
back on my feet
Cheers
Andrea
--
Ing. Andrea Aime
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584962313
fax: +39 0584962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-----------------------------------------------------
Thanks, Andrea, and don't worry about the example. I updated the docs, and ported to trunk.
Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org
On 2/2/2011 11:21 AM, Andrea Aime wrote:
On Wed, Feb 2, 2011 at 8:02 PM, Mike Pumphrey<mike@anonymised.com> wrote:
Thanks for the notes, Andrea, this is super helpful. Follow-ups, below.
all keys are case insenstive, all values are case sensitive.
Okay, but I do see that service=WPS works as well as service=wps. Just GeoServer being nice, though, I guess.
Yep, that's my understanding as well.
- the buffer in the example returns a square... correct answer given the params, but a little
outside what one would expect from a buffer operationI was looking for an example that would be simple to understand from just looking at the coordinates. If I had created a circle (or polygon equivalent), it might be more real world, but the numbers might not be so understandable. But I could change the example, though, if you thought it valuable. It was just the first process I came up with.
Yeah, a circle would be made of a lot of coordinates. No biggie.
Also, found it interesting that as is, the values were like -10.00000000067 instead of -10.0.
- in the geoserver processes paragraph you say "These functions have the added bonus
of being able to operate on existing layers in GeoServer, and can even write the output
to a new GeoServer layer".
Actually any process can work against existing GS layers, it just...
Okay. How should I categorize the differences between the gs: and the JTS: processes? (Or is there no important distinction?) I saw that the request builder had an extra entry for VECTOR_LAYER on the gs: processes, which is why I made the note.
JTS processes are made to expose jts capabilities and work on single geomtries.
GS processes... are all over the place, they do pretty much everything now.
There is a number of them that is specific to GS though, such as gs:ImportVECTOR_LAYER is something every process consuming feature collection will
have.- the trick GS uses to get data off the internal WFS/WCS is to use a special URL
for the wfs/wcs server, http://geoserver/wfs and
http://geoserver/wcs (if memory
serves me right) and that part is just a GS convention, it's not
anything that is
part of the standardOkay, I'll make a note of that.
- that said GS can feed off any remote WFS/WCS just fine (provided the chosen
output format can be parsed by GS), and in general, but any remote call
whatsoever that returns something parseable (it might be a php
script returning GML
for example)I'm pretty sure I follow this, but if an example lived somewhere it would be great to see it.
Don't have stuff handy now (I'm stuck in bed with fever and the
notebook does not
have everything I need in working order) I'll try to look up more
examples when I get
back on my feetCheers
Andrea