Hi dave,
I guess I don't agree in forcing the legend graphic to be exactly the size
requested by the WIDTH and HEIGHT parameters.
rationale:
1- as for the SLD 1.0 spec, page 62, WIDTH and HEIGHT are optional parameters,
and, more than that, they're _hints_. For that, I understand that the width
and height the user sent should be treated as its "preferred" dimensions, but
there is no obligation on fully respecting them, if it makes no sense.
2- I think client applications should be prepared to gracefully treat a legend
graphic larger than the size requested, like, for exaple, putting it on a
(html) table cell that expands as required bu lays out correctly on the
legend widget.
3- Generally, the width and height requested is thought for the size of a
single symbol, but most legend widgets expand vertically to adapt theirselves
to a larger graphic, instead of scaling down the graphic, since it would make
it unuseful for a large number of styling rules applied to a layer.
so, the GeoServer GetLegendGraphic operation was done to create a graphic with
the width requested by the WIDTH parameter, but to expand on height as needed
to meaningfully represent the styling rules without resulting in a illegible
image (i.e., with a lot of too small symbols in a 20x20px graphic)
further, the GetLegendGraphic operation is meant to return a representative
graphic of all the styling applied to a given layer, except if a specific
rule name is provided (through the RULE parameter), in which case the graphic
shall represent the styling of that specific rule.
what do you think?
cheers,
Gabriel.
On Monday 11 July 2005 18:12, dblasby@anonymised.com wrote:
Author: dblasby
Date: 2005-07-11 09:12:19 -0700 (Mon, 11 Jul 2005)
New Revision: 3668Modified:
trunk/geoserver/src/org/vfny/geoserver/wms/responses/DefaultRasterLegendPro
ducer.java
trunk/geoserver/src/org/vfny/geoserver/wms/responses/helpers/WMSCapsTransfo
rmer.java Log:
better support for correctly sized getlegendgraphic capabilities (see
source code comments - this is a bandaid)Modified:
trunk/geoserver/src/org/vfny/geoserver/wms/responses/DefaultRasterLegendPro
ducer.java
=================================================================== ---
trunk/geoserver/src/org/vfny/geoserver/wms/responses/DefaultRasterLegendPro
ducer.java 2005-07-11 15:54:40 UTC (rev 3667) +++
trunk/geoserver/src/org/vfny/geoserver/wms/responses/DefaultRasterLegendPro
ducer.java 2005-07-11 16:12:19 UTC (rev 3668) @@ -7,6 +7,7 @@
import java.awt.Canvas;
import java.awt.Color;
import java.awt.Graphics2D;
+import java.awt.geom.AffineTransform;
import java.awt.image.BufferedImage;
import java.awt.image.ImageObserver;
import java.util.ArrayList;
@@ -215,10 +216,34 @@
legendsStack.add(image);
}- this.legendGraphic = mergeLegends(legendsStack);
+ this.legendGraphic =
scaleImage(mergeLegends(legendsStack),request); }/**
+ * Scales the image so that its the size specified in the request.
+ * @hack -- there should be a much better way to do this. See
handleLegendURL() in WMSCapsTransformer. + * @param image
+ * @return
+ */
+ private BufferedImage scaleImage(BufferedImage
image,GetLegendGraphicRequest request) + {
+ final int w = request.getWidth();
+ final int h = request.getHeight();
+
+ BufferedImage scaledImage = new BufferedImage(w, h,
BufferedImage.TYPE_INT_ARGB); + Graphics2D graphics =
scaledImage.createGraphics();
+ graphics.setColor(BG_COLOR);
+ graphics.fillRect(0, 0, w, h);
+
+ AffineTransform xform = new AffineTransform();
+ xform.setToScale( ((double)w)/image.getWidth(),
((double)h)/image.getHeight() ); +
+ graphics.drawImage(image,xform,null );
+
+ return scaledImage;
+ }
+
+ /**
* Recieves a list of <code>BufferedImages</code> and produces a new
one * which holds all the images in <code>imageStack</code> one above the
* other.Modified:
trunk/geoserver/src/org/vfny/geoserver/wms/responses/helpers/WMSCapsTransfo
rmer.java
=================================================================== ---
trunk/geoserver/src/org/vfny/geoserver/wms/responses/helpers/WMSCapsTransfo
rmer.java 2005-07-11 15:54:40 UTC (rev 3667) +++
trunk/geoserver/src/org/vfny/geoserver/wms/responses/helpers/WMSCapsTransfo
rmer.java 2005-07-11 16:12:19 UTC (rev 3668) @@ -609,6 +609,17 @@
AttributesImpl attrs = new AttributesImpl();
attrs.addAttribute("", "width", "width", "",
String.valueOf(GetLegendGraphicRequest.DEFAULT_WIDTH)); +
+ //DJB: problem here is that we do not know the size of the
legend apriori - we need + // to make one and find its
height. Not the best way, but it would work quite well. +
// This was advertising a 20*20 icon, but actually producing ones of a
different size. + // An alternative is to just scale the
resulting icon to what the server requested, but this isnt +
// the nicest thing since warped images dont look nice. The client
should do the warping. +
+ //however, to actually estimate the size is a bit
difficult. I'm going to do the scaling + //so it obeys the
what the request says. For people with a problem with that should consider
+ //changing the default size here so that the request is
for the correct size. +
attrs.addAttribute("", "height", "height", "",
String.valueOf(GetLegendGraphicRequest.DEFAULT_HEIGHT));-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar
happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest
in dual core and dual graphics technology at this free one hour event
hosted by HP, AMD, and NVIDIA. To register visit
http://www.hp.com/go/dualwebinar
_______________________________________________
Geoserver-commits mailing list
Geoserver-commits@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-commits
--
Gabriel Roldán <groldan@anonymised.com>
Axios Engineering <http://www.axios.es>
CR/Basurtu-Kastrexana 70, Mod. 14
48002 - Bilbao, Spain
te. (+34) 94 441 63 84
fax (+34) 94 441 64 90
