[Tilecache] getLegendGraphic

[Christopher Schmidt]

On Fri, Mar 07, 2008 at 03:28:28PM +0700, Chris Brown wrote:
> Hi Chris,
> 
> Thanks for the quick thorough response. I hear where you are coming from and
> agree with you as in it would simply be a case of updating the static image
> each time you update a layer and clear the cache. Sorry I'm not familiar
> with Mapnik but would I be right in saying that it's a non-WMS complient
> backend?

Right, it's just a rendering backend. (It does have a WMS server, but I
don't believe that there is anything from the rendering backend, rather
than the WMS server demo, that does rendering of legend graphics, nor am
I sure whether the WMS server demo includes a wMS GetLegend support.)

> What you've said has reminded me that TileCache is a caching engine that
> caters to more than just WMS so can logically only support a subset of
> functionality which is common to each of the supported backends.

Or fake the functionality itself: Capabilities, for example, are
generated by TileCache itself, rather than by the backends. A
LegendGraphic support could be added in this way.

> When I was thinking of GetLegendGraphic I was thinking of something whereby
> the legend graphic is stored in the cache the first time it's loaded from
> the WMS, then is reloaded when the cache is cleared, as it the case with
> standard tiles, but now understand why this is not in line with the vision
> of TileCache.

That's not entirely unreasonable. I'd support doing this via a URL in
the config, possibly with a default for a WMS layer that knows how to do
a GetLegendGraphic request if nothing is specified.

Of course, there's a problem here, in that the caches are all designed
for tiles: They accept a tile object, and generate a cache key based on
that. So there would have to be some kind of additional cache support
for the differnt caches that knows how to store more files that aren't
tiles, for each cache (Memory, Disk, S3). Now you may start to see why I
was slightly hesitant to jump right into this one :)

> The use case that I am seeing quite often now is the WMS engine and WMS-C
> sitting on the same server and only WMS-C being exposed to the outside
> world, which is why I ask if you have you ever thought of doing something
> that caters exclusively to WMS, maybe as a separate branch? 

I think that even if it catered only to WMS, solving the above problem
would be an issue. But more directly, if you're using TileCache in this
way, you're probably 'doing it wrong' :) I probably wouldn't reject
patches to do this if they were well implemented, but I'm definitely not
particularly excited about implementing more of WMS than it currently
does.

> For me
> personally it would be great to see TileCache support all of the features of
> WMS. If a feature which is in the specification is not supported by the
> backend then the exception from the WMS is just passed onto the client via
> TileCache. This way the system isn't catering to the lowest common
> denominator in WMS backend implementations.

I don't think that all of the WMS operations make sense for TileCache.
Implementing a pass-through is somewhat against the design. Implementing
exceptions is fine, but it simply results in more complex code for
limited benefit. 

TileCache isn't a proxy, despite the fact that some people use it as
one, and turning it into a proxy feels kinda out of scope, even for a
branch: the code is definitely not designed with that in mind, and itw
ould be slightly complex to hack.

> [Off Topic]
> 
> Something else that I've often thought would be useful for a tool like
> TileCache that sits between the map server and the client is the
> generalization of non-image requests. 

That's easy. WPServer does that. Simply set up a 'simplify' action, and
in your OpenLayers based client, configure a WFS layer which has a URL
of something like
OpenLayers.ProxyHost = "/wpserver/wps.cgi/simplify.gml?tolerance=5&url=";
new OpenLayers.Layer.WFS("name", "http://remotehost/wfslayer");

This will pass all the URLs through wpserver, which will simplify them.
You'll want to update the tolerance on the fly, probaby to be equal to
the map.resolution. 

Note that this is not a well-documented piece of software, and I've
probably screwed something up; unfortunately, I've misplaced my
'simplify remote wfs' example of WPServer. If you're really interested
in it, bringing it back to the OpenLayers mailing list and asking for
help is fine. 

> I would love to use SVG (or even VML)
> more on the client but it is often impossible over the web due to the size
> of the XML documents for complex shapes. 

I don't buy that that's the limit. OpenLayers, at least, suffers under
the display of the data, *not* under the loading and parsing. 

> Something that sat in the middle,
> performed a generalizing algorithm like the Douglas Peucker and returned the
> simplified shape in SVG could open up a whole new world of possibilities in
> the world of vector based web mapping. I asked about this on the OSGEO irc,
> and it was said that there is something in the pipeline for generalization
> but nothing has come of it yet.

Not sure who said that; I never saw the question asked, but certainly
that type of tool is easy to build, and already exists in wpserver,
though not in a trivially pre-packaged form. Perhaps you were asking
about particular software, in which case your answer was tailored to
your question :)

Regards,
-- 
Christopher Schmidt
MetaCarta