The process api is used to capture GeoTools processes so they can be run in a nice threadsafe fashion

Table of Contents:

Sub pages;



The GeoTools Process API has been defined as:


Here is the plan for taking the gt-process concepts to supported status.

  1. setting the stage
  2. backport annotations from geoserver along with supporting infrastructure
  3. gt-process
  4. gt-process-feature
  5. gt-process-geometry
  6. gt-process-raster
  7. docs

Testing ideas

Most of the processes are backported from GeoServer, where they were tested by exercising the WPS api and using the testing facilities provided by GeoServer.

Need to replicate some of that at least partially:


Contains the Process interface, ProcessFactory along with DescribeProcess annotations etc...



RasterToVectory code may wish to be wrapped up as an opperation; and the internals replaced a JAITools operator.


Contains the base factory implementations; ThreadPoolProcessExecutor and so on.


Contains simple things often working on literals:


From GeoServer:


From GeoServer:


gt-swing (unsupported)

gt-wps (unsupported)

Contains a client allowing web processing service to be used in the same manner as a normal local process

Out of the above list the wps module is the odd one out; there is no way to make that one go to supported status without backing; especially with WPS 2.0 specification on the horizon. If anyone has an interested customer (or employer) they are more than welcome to develop against it.

gt-sextante (unsupported - requires volunteer)

My understanding is that the sextante license has changed; perhaps we could now have a gt-process-sextante plugin in geotools.

Yep, if someone is interesting in maintaining it there is a set of rough bindings available in GeoServer
community land.
I basically gave up on integrating it because it uses a push model, it's too hard to make it scale to large
quantities of data, raster processes do not use tiling for input/output, vector can do streaming only if not
chained... I mean, making clever use of thread (one per process), blocking queues, JAI wrappers that
call the process tile by tile it might be possible to get it going but it's a lot of work.
A plain wrapping is easier but would be bound to memory... meh... not exciting at all.


Q: What about jgrasstools?

It already supports the process api; it should just need to change its dependencies a bit (to just depend on gt-api and/or gt-main). Although there is probably a license incompatibility.

Q: What about geoserver?

The plugins are optional; my hope is that geoserver could transition to their use (for geometry etc...) without changing anything from the users point of view. While users are warned that in the user guide that these things may change there is no reason to go out of our way to rock the boat.

As such processes that have been prototyped in the geoserver code base should keep their prefix:

When updating GeoServer:

#. change imports to:

 import org.geotools.process.factory.DescribeParameter;
 import org.geotools.process.factory.DescribeProcess;
 import org.geotools.process.factory.DescribeResult;
  1. Change "WPSException" to "ProcessException"
  2. This transition has gone as expected: GEOS-4706 Cut over to GeoTools port of GSProcess implementations


JG" Is that the ESRI definition of Cookie Cutter?
AA: We have a clip process optimized for rectangles and a ESRI style polygon overlay that keeps attributes of both intersected featuers in the result. I'm also working to make a more generic clip process that will work with any shape, not just rectangles, but found issues with bbox filters and reprojected feature collections that prevent me from committing it, I guess I need another weekend of work to clean that mess before the process can be committed.

Q: What about uDig?

I am going to push the process user interface into uDig; it already lists any geotools processes in the catalog.

Q: What about gt-swing?

I have missplaced the process wizard and need to find it in an older branch of GeoTools. Michael if the process api is actually added to gt-api could we restore the process wizard to gt-swing? It would not require any additional dependencies

Conversation Points