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
