Can I have a small rant in response to this.
The legend URL does not have to call get legend graphics, and the goal for
each image is not quite the same.
In a GetCapabilities doc we just want the image, as we already have the
title sitting in parsed form in the get capabilities data structure.
Solve this problem by throwing a no titles option into your get legend
graphic URL, return a consistent 20x20 image and let's move on with life.
Got a group layer? Return a 20x20 group icon.
Jody
On Saturday, May 31, 2014, Andrea Aime <[email protected]> wrote:
> Hi,
> here we have a report http://jira.codehaus.org/browse/GEOS-6245 about
> legend graphic url not reporting the real width and height of the legend
> images.
>
> In fact we are reporting a static 20x20 size, but the spec says:
> "<Format>
> element in LegendURL indicates the MIME type of the logo image, and the
> attributes
> width and height state the size of the image in pixels."
>
> Now, the code that builds legend graphic is rather complex, and I'm sure
> it will
> get worse over time (think support for label font preview,
> categorize/interpolate,
> better handling of multiple feature type styles), so I have doubts about
> the maintainability
> of an approach that would compute the output size without actually painting
> the legend.
>
> Painting the legend, getting the image and grabbing its size is easy
> enough,
> but doing so for each and every style/layer in the caps document might
> take a toll.
>
> I've considered an approach in which the BufferedImage/Graphics used in
> the code are mocks, just to speed up things, but it will not really work,
> partly because the code works by building several internal bufferd images
> and asembling them later, and partly because we need to measure font
> metrics, and that requires a real graphics (and we could not just share
> a singleton one, these operations are not thread safe).
>
> So.. short of that, I was wondering about maintaining a cache of the
> style legend sizes in the StyleInfo metadata. Which could work,
> but we'd need to make a few changes around to know when the style
> changed, namely:
> * store in the metadata map the width/height and date when they were last
> computed
> * have the catalog store in the metadata map an information about when the
> styleinfo was last changed (which should be easy, and sort of useful for
> other purposes too)
>
> The other annoying bit is that running the get caps would end up modifying
> the styles that do not have the cached infos (an OGC operation that
> modifies
> the catalog contents woud be a first, and it would need to grab the
> configuration lock to work (hum... maybe just when a styleinfo write is
> needed...)
>
> An alternative could be to keep the info about width/height/last compute
> in a separate in memory cache, or store them on disk as sidecar files,
> but the nice thing about the styleinfo storage is that we basically have it
> already there when we build the style, and it would help scale up to large
> catalogs.
>
> Thoughts?
>
> Cheers
> Andrea
>
>
>
> --
> ==
> Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
> for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
>
--
Jody Garnett
------------------------------------------------------------------------------
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
