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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
