Sorry to be slow of brain, but I'm getting a bit lost now... Perhaps if I just explain what JMapPane currently does (plus the branch code updates) someone can help me to understand how this does, or doesn't, fit with the ideas being discussed.
There are two bounding rectangles: map and display. When zoomed in these can be the same, but at full extent the display bounds can be larger than the map bounds due to slack space. The map pane maintains its worldToScreen and screenToWorld AffineTransforms. There is currently no setter method. The transforms are used for mouse coords etc as well as being passed to the renderer's paint method (although the renderer does not honour the transform for grid coverages which is a long-standing issue that would be great to sort out). In the branch code, where rotation has been implemented, it is handled as an extra, concatenated transform (so that it is easy to undo). An item on my swing todo list is the ability to link map panes. An example use case is a small navigation pane showing a map at full extent linked to a larger, zoomed in pane. In this case a single viewport would not work. I guess one pane could clone the other's MapContent but then there are sync issues to handle if layers are added, removed etc. I don't bring this up as an objection to anything currently being discussed, but just as a use case I'd like to be able to support. Michael On 9 May 2011 09:38, Jody Garnett <jody.garn...@gmail.com> wrote: > 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
