Ciao a tutti, As Alessio pointed out we would like to spend a few time on the StreamingRenderer to make a but (hopefully better). I am in netherland right now and unfortunately the hotel internet access is kind of unstable, anyhow could we have an informat IRC meeting about this?
SImone. On 4/18/06, Alessio Fabiani <[EMAIL PROTECTED]> wrote: > Hi Dave, > I would like to help you, we have just to decide who does what. > I noticed that there are some problems when calculating the scaleDenominator > too due to the axis order. > > > On 4/18/06, Andrea Aime <[EMAIL PROTECTED]> wrote: > > David Blasby ha scritto: > > > (sending this out quickly for the IRC meeting) > > > > > > Okay, I've been fixing up the StreamingRenderer the last little while, > > > and here's what I think needs to be done. Most of these are just little > > > clean-up to get rid of the evidence of a long period of people slapping > > > stuff into it. > > > > > > > > > A) The path through the renderer is a bit confused. For example, where > > > is CRS transformation done? Its actually done by wrapping the > > > FeatureReader in a CRS-transforming feature reader. But, there's also > > > code (now in LiteShape2 - it used to be partially in LiteShape2 and > > > partially in the Graphics2D segment Iterators) that takes a geometry, > > > decimates it, transforms it,then does a pixel-level generalization. The > > > CRS transformation code should be done here since you can save a bunch > > > of complex math by generalizing first. Its also just really confusing > > > to read since there's 3 sets of generalization code! There's other > > > cases of confusion. > > > > By all means, reproject only after decimation. It's very very slow to do > > that before decimation. Reprojection in feature readers is thought for > > people that actually have to use the geometry in some kind of spatial > > analysis or editing, and need it in a different CRS, it was never intended > > for rendering. > > > > > B) All the Graphics2D Iterators need to be re-written. I just rewrote > > > the LiteIterator (which can get re-used by all the other Iterators). > > > The Iterators are extreamly difficult to read. > > > > > > Once (A) is done, this should be much easier since they seem to be > > > "doing too much" right now. > > > > I don't know the current state, but last time I commited them, they > > were doing exactly what needed: decimate, reproject and iterate. > > Remove one element and you'll pay quite a performance hit. If you like, > you > > can move decimation and reprojection in another class, but never reproject > > before decimating. > > > > > C) The renderer should be segmented into two classes. The first one > > > should be concerned with "setting things up". These are things like > > > dealing with the MapContext, optimizing the styles, getting optimized > > > FeatureReaders. The second will basically take the FeatureTypeStyle[] > > > (which has the Graphics2D and actual Styles) and FeatureReader and do > > > the actual drawing. This break is currently in the Renderer > > > approximately at the function > "processStylers()"/"processSymbolizers()". > > > > > > This will allow for more code-reuse, and simplify the current (giant) > > > class. Its not too much work since the renderer is conceptually already > > > broken up like this. It will make it very easy to write a parallel > > > renderer that would render more than one layer at a time (good for > > > multiprocessor machines and/or datasets that block while reading from > > > the disk/network/socket). > > > > Yes, good idea. Well, ideally it should be broken in three, and have > > data stores provide directly Java2d shapes instead of JTS geometries (plus > > a wrapper class that does the transformation for datastores that can only > > generated JTS geometries). Ideally, this should remove the need for a > > special ShapefileRenderer, if you see what I mean. > > > > > The end result will be a renderer that is much easier to understand and > > > maintain. I'd bet there will be minor speed improvements too. > > > Anyone got any time to help in this? > > > > Not at the moment, sorry. I'm still playing on UMLGraph :-( > > Cheers > > Andrea > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > > that extends applications into web and mobile media. Attend the live > webcast > > and join the prime developer group breaking into this new coding > territory! > > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > > _______________________________________________ > > Geotools-devel mailing list > > [email protected] > > > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > > > > > -- > --------------------------------------------------------- > Alessio Fabiani > Software Engineer > > http://docs.codehaus.org/display/~afabiani > > --------------------------------------------------------- -- °°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°° Simone Giannecchini Software Engineer Freelance Consultant http://simboss.wordpress.com/ "Canterò le mie canzoni per la strada ed affronterò la vita a muso duro un guerriero senza patria e senza spada con un piede nel passato e lo sguardo dritto e aperto nel futuro." °°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°° ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
