On Sun, Jul 3, 2011 at 9:57 AM, Jody Garnett <[email protected]> wrote:
> 1) gt-process
> - Rescuing from aaime's experiment in geoserver (mostly annotations and a
> few nice classes)
>
Yep. Those are not exactly finished, there would be more work to do to
handle, for example,
processes returning multiple outputs better, but so far they proved quite
effective in speeding
up process creation.
> - 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)
>
Or drop them altogheter. The current ones are not efficient, most of them
have a better implementation
on the GeoServer side. All the FeatureToFeatureProcess classes are memory
bound for example.
There are some good ideas on both sides (the base class approach is nice for
example), would be best to merge them
>
> 2) gt-process-geometry
> - Migrate GeometryProcessFactory from geoserver; this is still a good
> example of how to use the annotations
>
Yeah, still a good example I guess.
In GS it makes a lot of sense to expose JTS operations as processes, in
GeoTools not so much.
Maybe it would be useful in uDig?
> 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
>
I beg to disagree, jgrasstool license is GPL, for most basic processes a
re-implementation under
LGPL would be probably preferrable. In any case we cannot host or depend on
jgrasstools code
in GeoTools. GeoServer could instead, the license is compatible, the
processers in the Horton
machine are interesting should anyone need hydrological modelling in WPS
(and provided it
makes sense to do that on remote services instead of a desktop
application).
The GeoServer ones are GPL too of course but we have a tradition of
backporting the reusable
stuff in GeoTools, not sure what is the jgrasstools stance on this topic.
> 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")
>
There is a good bunch which are interesting on their own, buffer, cookie
cutter, intersection, overlap and so on.
>
> 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
>
Processes can handle whatever, they can be pure vector, pure raster, mix, or
completely non spatial
(reporting processes, send mail processes, and so on, the typical stuff
found in a ETL/workflow system).
>
> 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.
>
Would be nice for WPS cascading... but have no resources to put on that one
right now.
>
> 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.
>
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).
>
It supports the geotools process api? I thought it was using another process
API. (open modelling framework or something
like that).
>
> 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.
>
It's largely up to you. We need some way to keep on calling
gs:RectangularClip that way even if you
backport it to GeoTools. That said, the GS user guide warns that processes
are still in a state of
flux and they could change over time.
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
-------------------------------------------------------
------------------------------------------------------------------------------
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
