Well with the map layer work sorted out (thanks mbedward and aaime) I can
return to what I wanted to work on after docs ...
With that in mind I am going to break out gt-process with an eye towards moving
it to supported status. I assume at this stage with geoserver wps being
released to the wild that the interfaces are stable/good enough.
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
Q: What about wps?
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.
Q: What about sextante?
My understanding is that the sextante license has changed; perhaps we could now
have a gt-process-sextante plugin in geotools.
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).
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.
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 ...
--
Jody Garnett
------------------------------------------------------------------------------
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
