Hi Andrea; going to take your email as a general +1 for the requested
unsupported modules...
> > - 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
>
>
>
>
Okay I will keep that in mind; as author of those things on the geoserver side
I assume you can give me permission to copy them over.
> > 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?
>
>
>
Indeed the reason I am doing this work.
> > 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
> >
> >
> >
>
> 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.
>
>
>
Okay so gt-process-raster will make the cut; and hopefully grow over time.
> > 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.
>
>
>
Is that the ESRI definition of cookie cutter? Suppose I will find out.
> > 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).
>
>
>
Okay from that feedback I should move this into gt-metadata then.
> > 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.
This is what I am doing for the wps-shootout; it is just that I am not going to
go as far as making it supported.
> > 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.
>
>
>
So should I take it to geotools as an unsupported module? Perhaps it can
attract a developer.
> > 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).
>
>
>
Yes it does; and the wrapper has been produced so it can use the OMS3 metadata
and produce the geotools data structure we need to run... it is actually pretty
nice.
> > 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.
>
>
>
I think I will backport and keep the "gs" namespace. I have not reason in
annoying users if not needed.
Cheers,
Jody
------------------------------------------------------------------------------
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
