Ciao Bryce, as Adrian correctly pointed out I am refactoring a bit the proposal in order to cope with some of Martin's suggestions. I hope that this process can become two ways anytime soon :-) Adrian, do not worry the proposal page will be updated as soon as I can spare some time (next week probably). I hope the same will soon apply to this one http://docs.codehaus.org/display/GEOTOOLS/Improve+support+of+RGB+coverages which came afterward an API change with no vote for it and still has no information on it. I hope the proposal process (and pain) applies to everyone for GeoTools.
Quick answers to your questions, Bryce: 1> a category is just a range with a label. I tried to attach transformation to it in order to do piecewise transforms 2> the actual intent of what we propos is not a framework for rendering, even though we plan to extend it in the future (even though I am not so sure the countouring is something you want there, but anyway we can discuss over that). Its goal is to try and implement the basic building blocks of the SLD 1.0 Raster Symbolizer, full stop. In order to be able to extend this a bit in the future I have defined a CoverageProcessingNode interface that can help with creating chains (or graphs) of processing nodes which can do whatever you want. Right now, as I said we focus only on parsing SLD 1.0 rastersymbolizer with a few minor extensions ( I will ad more info to the proposal page next week). Countouring and wind barbing could be added, but it would need to find a fit in the RasterSymbolizer schema. About the refactor. I like Martin's suggestions of factoring out the piecewise transformation part in order to move it to referencing an reuse it in other parts of the codebase. I am trying to do some efforts in that direction so that everyone is happy. This work is needed by the rastersymbolizer work but it has no reasons to stay inside renderer for long. Ciao, Simone. On Fri, Feb 29, 2008 at 8:05 AM, Adrian Custer <[EMAIL PROTECTED]> wrote: > Hey Bryce, > > The proposal has changed dramatically following last monday's IRC. > > It turns out what Alessio/Simone, needed was indeed a MathTransform > rather than a duplicate category system. If I understood correctly, > their symbolizer work needs a piecewise, 1D transform from the image > data set values to the, possibly multiple, colour ranges of their > rendered symbolics. Simone has started in on the work to create a > MathTransformBuilder1D (not sure of the name). > > Note that perhaps we will never update the proposal page, although > perhaps we should note that. The proposal page now has served its > purpose in announcing the effort, in showing a proposed design, and in > triggering the discussion by which Martin helped us resolve all our > conceptual misunderstandings of his coverage work which had led to all > those category classes in the first place. Hopefully we are now on a > more appropriate tack. > > Martin will have to answer you about the windbarbs which I know he has > 'left room' for in his coverage work since he plans to implement a > vector symbolizer for such vectors in his updated renderer during his > next project. > > --adrian > > > > > On Thu, 2008-02-28 at 18:23 -0700, Bryce L Nordgren wrote: > > Comments based solely on the wiki page and Monday's IRC. > > > > I think this proposal is going to add quite a bit of power to the > > downstream code (e.g. GeoServer). I confess I have trouble understanding > > what a "Category" is from the picture. Are these types of transforms? > > > > I like that SLD provided a "starter set" of symbolizations which we are now > > implementing. I like even better that it inspired a framework > > which--theoretically, at least--could be extended to cover cases SLD did > > not cover. To help me get my mind around the proposal, could someone > > briefly outline how the framework on the wiki would be extended to > > accomodate...say..."contouring"? This would be used to style a > > temperature coverage to show isotherms; or a pressure coverage to show > > isobars. > > > > Here's another twist: how would the new framework handle an extension for > > "wind barbs", where each raster cell has an east-west and a north-south > > component? Even more complex, we don't necessarily want > > one-symbol-per-gridcell. Maybe we only want one wind barb for every five > > cells. > > > > Just to be clear, I'm not asking anyone to implement these things. I just > > want to make sure that the framework "leaves room" for them in the > > hopefully-not-so-distant-future with little to no rewriting of brand new > > code. :) > > > > Bryce > > > > > > ------------------------------------------------------------------------- > > 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 > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > > ------------------------------------------------------------------------- > 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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
