Thanks for taking some time to review martin...
On Fri, Feb 22, 2008 at 4:17 PM, Martin Desruisseaux <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] a écrit : > > Please take a look and review at > > http://docs.codehaus.org/display/GEOTOOLS/Raster+Symbolizer+support > > I had a quick look to the interfaces at: > > http://svn.geotools.org/geotools/branches/2.4.x_rs/modules/library/render/src/main/java/org/geotools/renderer/coverage/category/ > > I noticed that those interfaces are pretty close to the API that I created in > org.geotools.coverage, except that they are interfaces rather than classes, > and: > Yes, they are. I do not remember if Alessio mentioned that in the proposal, but if yuo remember when we talked at FOSS4g back in october I mentioned that I had a few weeks to revisit the category and geophysics thing and this is what I have been able to do using that time. As you might remember, I would like to separate the geophysics non geophysics duality from the coverage themselves so that we stop running into the duality images vs models this is trying to push some time in that direction. > * CategoryList has been made public, while it was package-privated in my > implementation. Which CategoryList's service are required that can not > be assured by SampleDimension (extending the later if needed)? I was not 100% sure about this, so for the moment I just tried to underline basic behavior using interfaces. The point for this is that you can create new categorylists reusing the provided implementation and feed an agnostic sampledimension which would simply rely on the interface and add behavior as/if needed. > And does > CategoryUtilities really needs to be public? It could be in the package scope, but then people extending this code in the future would have to stick with this package naming in order to reuse these methods. I would have to check again those methods to give a final answer. > > * Category (and CategoryList) has been splitted in some subinterfaces: > TransformCategory, VizualizationCategory. Each of them contains a single > method. Why this extra-level of complexity? Why not just keep the > extra-method > in a single Category class, like I did, and just returns null if there is no > transform? I am not a fan of null values even though I have used them a lot in the past :-). I tried to make these classes easy to understand for people. If I just need a simple category I do not want to specify a transformation and a color. > Is it for type-safety? That was another reason. > Furthermore TransformCategory.getTransform() > is confusing. Is it a "sample to geophysics" transform? > If not, which kind of > transform is it, for what purpose? And why TransformCategory extends > MathTransform1D in addition of having a getTransform() method? Is it the > same > transform? If so why this duplication? I quickly checked the code and i agree with you that the getTransform method should not be part of the interface because it is an implementation detail. I am going to move it to the DefaultTransformCategory implementation. Let me point out that the transform is a generic transform, so it can be a sample to geophysics as it could be a custom transformation to implement custom contrast enhancement on rgb images (like for example a piecewise that actually works, not like th JAI one, or it could be a logarihmic one, etc. etc.). > Why Category.getRange() has been > renamed getInputRange() in your flavor, given that a category is not a > transformer with input and output (the "sample to geophysics" transform > is, but not the category itself). > You are right, going to apply this change. I am going to share more thoughts during the weekend on this since I think it could be a good starting point to improve the geophysics non gephysics duality. Simone. > > > Martin > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > -- ------------------------------------------------------- Eng. Simone Giannecchini President /CEO GeoSolutions S.A.S. Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 333 8128928 http://www.geo-solutions.it ------------------------------------------------------- ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
