+1 for putting it in library. This looks almost like it could go into 
main, but keeping it in a separate module is great if you can.

-0 for factories. I think this is a component that could in the future 
be used to build a transforming factory; I do not think that you should 
feel obliged to write one now.

Kind regards,
Ben.

On 14/06/13 20:22, Andrea Aime wrote:
> Hi,
> I'm writing you to start the process to graduate the gt-transform module
> to supported status.
>
> For those that don't know, the gt-transform module provides a way to
> create wrappers around SimpleFeatureSource/SimpleFeatureStore that do
> alter the attributes exposed via:
> * attribute selection
> * attribute renaming
> * creation of new attributes as expressions of other attributes
>
> All of the above is achieved by associating the new set of attributes
> each with a OGC Expression, like in the test cases, see the three
> methods setting up some transformations:
>
> https://github.com/geotools/geotools/blob/master/modules/unsupported/transform/src/test/java/org/geotools/data/transform/AbstractTransformTest.java
>
> The module takes care of all needed filter and name transformations, and
> if the transformations are invertible (that is, pretty much just
> attribute rename at the moment) then it also preserves the writability
> of the original SimpleFeatureStore.
>
> The test coverage is good (69%), IP wise there are no issues, wrote all
> the code myself (though I guess I need to add a review.txt in there,
> right?), there are no bug reports in jira.
> There are no docs, but I plan to add a page of docs turning the unit
> tests into examples along with the pull request that will graduate the
> module.
>
> Ah, the final location is a bit of a mystery... this thing is not a
> plugin in the strict sense, there is no factory and no store, you are
> supposed to call TransformFactory.transform(source, targetName,
> listOfAttributeDefinitions)
> in order to get the transformed source/store.
> As such is more similar to a ReprojectingFeatureCollection than a stand
> alone data store... so... where should it go? Library?
> However, setting up a factory and store is not un-thinkable, but it
> would be a bit odd to have a store whose one of the source params is
> another store...
>
> Any feedback?
>
> Cheers
> Andrea
>
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for
> more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
>
>
>
> _______________________________________________
> GeoTools-Devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>

-- 
Ben Caradoc-Davies <[email protected]>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to