Migrate Process API to supported status
---------------------------------------
Key: GEOT-3688
URL: https://jira.codehaus.org/browse/GEOT-3688
Project: GeoTools
Issue Type: Improvement
Components: process
Affects Versions: 8.0-M1
Reporter: Jody Garnett
Priority: Minor
I assume at this stage with geoserver wps being released to the wild that the
interfaces are stable/good enough.
With that in mind here is a plan for taking the results of gt-process up to
supported status.
Thoughts:
- Documentation is already pretty good
- Most of the actual work should be merged into the geotools library (as it is
not worth while standing on its own)
Feedback:
- There was some confusion over why a Process data structure was needed; the
static methods are more handy for day to day coding obviously. With that in
mind a tutorial that covered the use of a ThreadPoolProcessExecutor (as a great
alternative to Swing worker) would be useful.
- The inclusion of process implementations "out of the box" is not good in a
controlled environment like GeoServer where the control of exactly what is
published is desired.
Planning:
1) gt-process
- Rescuing from aaime's experiment in geoserver (mostly annotations and a few
nice classes)
- Review and Document the base classes / annotations
- Write a small advanced tutorial showing how to make one process
- Migrate the processes implementations that were included as examples into
individual (and optional plugins)
2) gt-process-geometry
- Migrate GeometryProcessFactory from geoserver; this is still a good example
of how to use the annotations
3) gt-process-raster
- migrate raster to vector for gt-process
- not sure what else goes here; jgrasstools stole most of the reason for this
one to live
4) gt-process-feature
- not sure if we have many feature based processes yet; the ones in geoserver
are specific to their catalog near as I can tell (or perform simple things like
returning a "count")
5) Moving the good bits into the library
- the actual interfaces can move to gt-api
- the core implementations to gt-main (my preference) or gt-metadata depending
on if they are useful for raster processing?
- this would leave plugins/process as an optional plugin that contains only
basic "literal" processes
So at the end of the day:
- modules/library/api - contains the Process interface, ProcessFactory along
with DescribeProcess annotations etc...
- modules/library/main - contains the base factory implementations;
ThreadPoolProcessExecutor and so on
- modules/plugins/process - contains simple things often working on literals;
possibly a bridge to geotools functions
- modules/plugins/process-geometry
- modules/plugins/process-feature
- modules/plugins/process-raster
- modules/unsupported/wps - contains a client allowing web processing service
to be used in the same manner as a normal local process
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
