On Sat, Feb 5, 2011 at 6:49 AM, Jody Garnett <[email protected]> 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 ------------------------------------------------------- ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
