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 don't see how a category called TransformCategory extending category and MathTransform1D can be confusing. It is a category that specify a 1D transform between input values and output values. This transform can be anything. > 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. Btw, I realize that I could add a child page to explain more in detail the rationale behind this and also how it could be used on coverage. 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
