Had another look at the proposal, setup as it is it will be harder than
necessary to handle
> the switch of StreamingRenderer the Layer/MapContext API as the design of
> streaming
> renderer is style oriented, and the hierachy of Layer has getStyle() just as
> an afterthought.
>
> This is problematic in that it's the style that tells you if a layer is
> active, what parts of
> the data you're going to read and so on. It's the style that tells you if a
> raster layer
> is going to be painted as raster or as vector (one can apply a polygon
> symbolizer to
> rasters and just have the bounds be painted).
>
>
>
I see. The intension was to only apply style to things that could use it.
> So I'd say that a first step to get things moving would to be a StyledLayer
> class
> acting as the base class of FeatureLayer, GridReaderLayer and CoverageLayer
>
> /**
> * Styled layer: data, in some form, with a style. The opposite of a
> DirectLayer,
> * that draws itself instead of declaring what data to be painted, and how
> */
> StyledLayer extends Layer {
> getStyle();
> setStyle(...)
> }
>
>
>
Introducing StyledLayer should be perfectly fine.
> The second thing that is not clear in my mind is the relationship between
> DirectLayer
> paint method, the MapViewport in a MapContent, and GTRenderer various paint
> methods.
>
>
>
Perhaps I should call it "DrawLayer" - let us look at the method(s):
public abstract void draw(Graphics2D graphics, MapContent map, MapViewport
viewport);
paint(Graphics2D, Rectangle, AffineTransform)
paint(Graphics2D, Rectangle, Envelope)
paint(Graphics2D, Rectangle, Envelope, AffineTransform)
paint(Graphics2D, Rectangle, ReferencedEnvelope)
paint(Graphics2D, Rectangle, ReferencedEnvelope, AffineTransform)
> So the MapViewport contains the current area on screen... which is pretty much
> the same information provided to the paint methods, but in a different way.
>
>
>
I see; so perhaps we could simplify the paint methods? MapViewport does contain
a lot of the same information; but is missing the affine transformation (which
I think was added after this work?).
My preference would be to add affine transformation to MapViewport (it would
allow for rotation I guess); and have a paint method that takes a MapViewport
for consistency.
> And then the renderer should provide the direct layers with a viewport, but
> one derived from the paint method arguments... Isn't this confusing?
>
>
>
It was my hope that this would be "documenting" and not confusing. MapViewport
ties this information together; with javadocs and test cases; making it harder
to screw up?
Jody ------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
