I like storing the style infos, and the approach works well when setting up
with an image (rather than get legend graphics call).
Can I suggest a scary alternative, what about generating and storing the
image on disk. The image has a width and height after all, and you could
refer to it farther that get legend graphics?
Since you have to paint the thing anyways is it worth keeping the image?
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
