Nope, watermarking is handled as post processing after the rendering process
> happened. Watermarking, and map decoration handling in general, is indeed the
> only
> cleanup we'd get in GeoServer land, updating the rest of the code to use
> MapContent/Layer looks like a mere refactoring otherwise (e.g., no other
> improvement I can see).
In uDig it is handled in a similar manner to DirectLayer; as such I would like
to port some of
that code to GeoTools using DirectLayer.
> Most of the classes in that picture are actually in GeoTools so you can see
> them
> already, but anyways, here is a list of pointers to the code:
> http://svn.osgeo.org/geotools/trunk/modules/library/render/src/main/java/org/geotools/map/DefaultMapContext.java
Generates bounds from the first layer; default styles are generated if needed.
> http://svn.osgeo.org/geotools/trunk/modules/library/render/src/main/java/org/geotools/map/GraphicEnhancedMapContext.java
>
This one provides: width, height, bgcolor, transparent.
The interesting one here is "transparent"; how is that used? (I don't see any
references to this in geotools).
I note that MapContent.getUserData() provides a place to store "extra"
application specific stuff of this nature.
> http://svn.codehaus.org/geoserver/trunk/src/wms/src/main/java/org/geoserver/wms/WMSMapContext.java
>
This one captures mapWidth, mapHeight, bgColor, transparent, tileSize, angle,
buffer.
The ones that effect the rendering process here are angle and buffer; I am
going to assume that you use the angle to generate an affine transform when
calling GTRender.paint.
> > I should point out that the change to MapContent has been done; and the
> > above code is still working correctly. Is renderer subclassed as well?
> The renderer is not, but I asked if you would deprecate the old classes
> and you confirmed. Don't want to increase deprecated code usage in GeoServer,
> thus I'm forced to refactor it to use the new classes.
Understood; I am not particularly interested in adding to your "volunteer"
workload; and would prefer to make a patch for you to review.
So far in this review we have identified three things:
- Pull up StyleLayer to make updating the renderer easier - done
- Look at how to handle affine transform in MapViewport (possibly sorted out
with medward based on gt-swing requirements)
- Review subclasses of MapContent and see if we can cover any new requirements.
Out of this the thing that is a gap for me is the relationship between:
a) map bounds -> screen size (these two values can be used generate an affine
transform
b) affine transform -> is this a replacement for the above; or is it just used
to rotate?
Reading code to answer my own question:
- the transform is called worldToScreen
- it is often generated by RendererUtilities.worldToScreenTransform(mapArea,
paintArea)
So if I understand; to apply a rotate code could perform the following:
AffineTransform t = RendererUtilities.worldToScreenTransform(mapArea,
paintArea);
t.transform(-paintArea.width/2,-paintArea.height/2);
t.rotate( angle );
t.transform(paintArea.width/2,paintArea.height/2);
So if we could take that calculation into MapViewport I would be happy; it
would make it easier for people writing a DirectLayer.
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
