Hi Justin, As the author of the vector to raster bits I'd be happy to see that factory folded into another. It is not separate for any good reason.
Michael On 14 August 2012 09:23, Justin Deoliveira <jdeol...@opengeo.org> wrote: > Hi all, > > Recently on the geoserver list a thread was started regarding how processes > in geotools are organized into factories. Long story short the outcome was > that a better organization is desired. > > The organization we currently have is this: > > factory: GeometryProcessFactory > prefix: JTS > description: Simple JTS based spatial analysis methods > > factory: FeatureGSProcessFactory > prefix: gs > description: Geospatial Feature Process Factory > > factory: VectorToRasterFactory > prefix: gt > description:Rasterize features > > To add to the mix, we also have processes which are only registered as part > of geotools, but for the most part live in geotools: > > factory: SpringBeanProcessFactory > prefix: gs > description: GeoServer custom processes > > > I propose we rethink this organization and would like some feedback on the > following. > > 1. Push all non-geoserver specific processes back into GeoTools factories > > Currently all the processes in the process-raster module are only registered > through the geoserver specific factory. I vote we create a > RasterGSProcessFactory to mirror the FeatureGSProcessFactory and leave the > geoserver specific factory to those factories that are truly specific to > geoserver (like gs:Import, etc...) > > > 2. Fold VectorToRasterFactory to an existing factory > > Currently this factory only publishes one process. It could easily be folded > into an existing factory. > > > 3. Reorganize factory prefixes and descriptions > > The current grouping is fairly arbitrary. What we came up with on the > geoserver list was to group into a very coarse set of categories based on > the type of data the process operates on. There are a couple of ways to go > about this so I present multiple options: > > > A. Categorization based strictly on the type of input: geometry, vector, or > raster. With that the factories become: > > 1. GeometryProcessFactory with prefix "geo" > 2. FeatureProcessFactory with prefix "ft" > 3. CoverageProcessFactory with prefix "cov" > > B. Same as (A) but with different names/prefixes > > 1. GeometryProcessFactory with prefix "geo" > 2. VectorProcessFactory with prefix "vec" > 3. RasterProcessFactory with prefix "ras" > > C. Categorization based on "space" (raster vs vector). Geometry would remain > the same and those processes that both input/output as vector would remain > in the vector category and those that have both input/output as raster would > remain in the raster category. Those that cross the divide would get a > fourth "transform" category: > > 1. GeometryProcessFactory with prefix "geo" > 2. VectorProcessFactory with prefix "vec" > 3. RasterProcessFactory with prefix "ras" > 4. TransformProcessFactory with prefix "tx" > > > 4. Deprecation > > The biggest problem with this reorganization is that it changes process > names/identifiers. Which is problematic since we do have users making use of > the names as they stand today. So we would have to come up with some > deprecation scheme. I can think of a couple of ways to do this. > > A. Add notion of process factory alias > > The idea here would be to change the process factories official prefix but > still support the old one. This one is tricky since to be backward > compatible the factory would have to return both sets of names.... both the > new and the old resulting in a lot of duplication. > > B. Add a single "deprecated" factory > > The idea here would be to create a single factory to handle all the > deprecations and changes. In the factory we would maintain a set of names > and the factories/new names they map to. The nice thing about a single > factory would be it would be easy to remove all the deprecates just by not > including the factory. > > I am sure there are other ways to solve this one as well. Interested to hear > ideas. > > > -Justin > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > GeoTools-Devel mailing list > GeoTools-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
