[Chameleon] New Widget :-D

[Godwin, Elizabeth]

regarding Chameleon and SLD awareness (comments below text)...

> Unfortunately, grabbing this information is expensive (time 
> wise) when 
> loading dynamic layers through a context unless some sort of 
> local cache 
> of WMS servers is kept.  I suppose it would be ideal if every 
> layer that 
> was added could trigger a download of the capabilities if it wasn't 
> already in the cache ...
> 
..snip..
  
> > Alternatively (or in addition...?), if a metadata tag was added to 
> > each
> > layer when it is added to the map object that specifies if 
> it handles 
> > SLDs/getLegendGraphic, that would be nice.  Since Mapserver 
> applies SLDs 
> > to normal non-OGC layers nicely, this can also be something 
> that applies 
> > to all map layers.  Also, if it's in the mapfile, I can 
> grab it from my 
> > widget.  :-)
> 
> yeah ... that would be nice but that information is not 
> available from 
> the context AFAIK.  If it is, it would be easy (relatively) 
> to add it to 
> the metadata.  For layers coming through the WMSBrowser, it would be 
> possible to modify the wmsparse to capture that additional 
> information 
> and store it in the wms cache.  However, it is not trivial to change 
> wmsparse and its not likely this would happen any time soon.

How not trivial?  I'm thinking this would be a wise investment into
Chameleon if it's going to be effective with WMS and SLD.  I'll do it..
I'm needing to know where to start.  I don't need a walk through of the
code... But what is the relationship between the cached capabilities,
the servers dbf files, and the metadata that is added to the layers when
they are added by WMS browse?

So far I've noticed that there are cached getCapabilities files.  And
that some info is grabbed from these and stored in a server cache (dbf
file).  Would this be the best place to store the info?  Are servers
from layers added from a context document added to the server cache?  I
am thinking not.  

What about this...
- assume here that when a layer is added via WMS browser, metadata is
added to the layer file indicating if the layer is capable of handling
SLD.  Say canSLD=<0|1> When added through a context document, it is not.
- when a user wants to apply an SLD to a layer (using UploadSLD), canSLD
= 0, then an error is presented so User knows SLD cannot be applied.  If
canSLD=1, then it can and operation continues, SLD is applied, legend is
also updated, life is good.  If there is no canSLD metaelement, then the
capabilities file is sought out.  first in cache, then on web.  Metadata
value is set in layer.

Handling a context file is another issue.  As far as the specs go..  if
any styling is set in the context document, it can be assumed that the
layer can handle it.  Another option which could reasonably added to the
spec would be the addition of a "sld" parameter in the Layer element.
Currently there is just "queryable" and "hidden".

Now... as a client of WMS, there are better ways Chameleon and/or
Mapserver could handle saving of SLD info in a context document.  Right
now..  if an SLD has been applied, the wms_sld_body is set to auto.  So
when a context is saved...  sld styling is not added to the context.  I
would recommend that this be changed.  The specs account already for SLD
body being included directly in the context document.  Since Mapserver
is already capable of sending this SLD body to a foreign server in a
getMap request, I don't see it would be much work to dump that into the
context document.  In fact I would say that it would be an asset to
Mapserver's already expanding handling of OGC specs. (bug 887)  I'll
post this comment on the Mapserver list too...

I know that was long-winded.  Hopefully you read through it :-)

Cheers,

Liz