On Sat, Feb 5, 2011 at 6:49 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:
Well the annotation stuff would be good to put into gt-process. As I understand it there are a couple batches of processes as well...
Ok, let me hash out what I'd like to do if I had time.
First thing would be to take the annotations and the factories based
on them from
http://svn.codehaus.org/geoserver/trunk/src/extension/wps/wps-core/src/main/java/org/geoserver/wps/jts/
and bring them back into gt-process (and delete the dem example they
originated from).
This means taking all the annotations and process factories but the
SpringBeanProcessFactory,
which has Spring dependencies attached to it. That _could_ be
backported to GeoTools
in its own module but it really adds very few to the code and a lot in
terms of dependencies
(plus, old ones, old version of Spring GeoServer is using).
I'd rather make a comment in its base class that a Spring version
exists in GeoServer
for whoever needs it.
Second thing would be to modify the GeoServer WPS module to use the
gt2 annotations
(which means changing the imports of all processes).
- "JTS" processes could be folded into gt-process directly; or placed into a seperate gt-jts plugin?
I'd place it in its own plugin, because once they are around, they are
available: gt-process
should provide the machinery, but not the processes (btw, we should
also remove the example
processes in gt-process, or maybe better put them in the gt-process
tests to assess things are working).
There is one doubt I have though... the JTS processes are really just
exposing the atomic JTS
operations, have a look for yourself, here is the class that generates them:
http://svn.codehaus.org/geoserver/trunk/src/extension/wps/wps-core/src/main/java/org/geoserver/wps/jts/GeometryFunctions.java
Now, do we really need those processes in Geotools? I see their place
in a WPS, it makes all those
little utilities web accessible from javascript clients.
But in GeoTools? The Java programmer is better off using directly JTS....
- "Sextante" processes I think can be placed into their own module due to a license change. Should be a wrapper combined with a dependency on sextante jars. I could see adding it to gt-process directly; and having the wrapper only work if sexatante classes were available on the classpath. Using something like the "isAvailable" check we have for DataStores.
Sextante wrappers have been left behind in a community module because
they are nowhere
close to be functional and useful:
http://svn.codehaus.org/geoserver/trunk/src/community/wps-sextante/
The overall Sextante architecture is simple but it has been putting me
off quite a bit
as it is push designed, you invoke a process and it computes a result,
instead of
giving you a hollow object that will do the computation on demand like in JAI.
Designed that way it's just not possible to make it stream and scale.
Vector processes often miss error control for corner cases (e.g., it
expects a polygon
to polygon intersection to always return a polygon or a multipolygon, but it can
also return a point or a line), raster processes do not scale up
because they build
the result as a single in memory matrix.
There could be ways to make that better, for example use threading and blocking
queues to force the vector processes stream, and wrap the raster processes
in some JAI operation that makes them compute the result one tile at a time,
but it's quite a bit of work.
Add on top of that the existing binding situation, which is not too
great, and you
should get why I haven't been eager to push on this in my spare time.
Sextante raster has indeed quite a number of interesting processes so I hope
someone will sponsor the above push, or that someone simply decides to make
that happen in her spare time.
- moovida also had some work in this area; but I think he wrote his own wrapper already
Yeah, unfortunately that work depends on Java6 specific API so it is
off limits until
we can switch GeoTools and GeoServer to it.
That said the day we can upgrade the Java version we should be able to build a
GT process factory that plugs into OSM, or that directly interprets
the OSM annotations
Now, that is not all. The "gs" factory nowadays has a number of
processes that are
not GeoServer specific, have a look for yourself, the really GS
specific ones are
the ones that require GS specific API and/or registration in the app
context, but they
are just a minority:
http://svn.codehaus.org/geoserver/trunk/src/extension/wps/wps-core/src/main/java/org/geoserver/wps/gs/
Some of them are self contained, others depend on jai-tools, some work
on vectors,
other on rasters, others do conversions.
Imho they should be backported to disctinct Geotools plugins as well,
but I still
haven't make my mind up as to how to classify them.
By data type handled? That would give us three blocks, raster, vector
and conversion
processes.
By kind of operation? We do have topologic, statistical, and base
raster manipulation then.
The thing is, the classification should somehow imply the factory the
are registered with,
and thus part of their name WPS wise (the "gs", "jts", "gt" prefixes).
I already made sure the WPS docs contain a warning that process names
might change,
but the day we do I'd like to get that right so that we don't have to
change it again
later
So you see, there is indeed quite a bit of work.
The nice thing about is that it can be sliced up in more manageable parts
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
mob: +39 333 8128928
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
-------------------------------------------------------