[Chameleon] New Widget :-D

[Godwin, Elizabeth]

See inline :-)

> I agree.  The legend template system doesn't work well with 
> WMS layers 
> for getting legend graphics.  Definitely a problem.
> 
> Are you replacing the legend templates entirely?  Will this be a 
> hardcoded representation of the legend or will it be 
> user-configurable in some way?

Right now it's all hard coded.  All layers are displayed in the Legend
list.  However, it's a good idea to improve it with a type of templating
system.  For the moment it's using lists with javascript and css to
handle collapsing the list into layers.  But it's terribly flawed :-(  -
first crack at it.  

> >  
> > SO... one of the issues I'm running into, is that as it 
> stands, or as
> > far as I can tell, Chameleon doesn't store/know which 
> servers/services 
> > are capable of handling SLD information.  And that is 
> something I would 
> > like to know.  For my application.  I imagine this is 
> useful for others 
> > using Chameleon for OGC purposes also.
> 
> I would say that Chameleon just doesn't know the information 
> since it is 
> not carried with contexts.  However, it is available in the 
> capabilities 
> of a given server ... 
> WMT_MS_Capabilities/Capability/UserDefinedSymbolization
> 
>    <UserDefinedSymbolization SupportSLD="1" UserLayer="0" 
> UserStyle="1" 
> RemoteWFS="0"/>
> 
> 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 ...

That would be nice...  The user would be able to know why something
didn't work, instead of it just not having an effect.  ie.. applying an
SLD to a layer that doesn't support it results in no change.  As a user,
they may think it's because the SLD is busted.  or Chameleon is busted.
Knowing it's the service's limitation is ideal.

> 
> >  
> > In my widget, I would like to perform a getlegendgraphic 
> request when
> > relevant.  Relevent is servers that support this.  I would 
> also like 
> > error checking, so if it's capable, but there's an 
> error...show message 
> > not image.  This is where javascript wouldn't help me.
> >  
> > My first thought was to use the pear HTTP_Request function 
> to evaluate
> > if the getlegendgraphic response is xml (error) or an image 
> mime type, 
> > but if there is some utility I should use instead..then I'd 
> like to know. 
> 
> you could set the img src to the getlegendgraphic request url 
> and set an 
> onerror handler in the img tag so that if the request failed, 
> you could 
> replace the image with a standard 'unknown' image or something

AH!  I was searching everywhere for something client-side and I couldn't
figure it out.  This could very well work.  Maybe even in my HTML
templates.  Won't look as nice of course :-(

> 
> >  
> > 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.

If I only knew where to start....

Context documents sometimes have LegendURL info stored, but it's not
reliable.  And not necessarily indicative of SLD/getLegendGraphic
capabililities.

>>  AND CVS access (Paul???)  I'll give back the 
> final results 
> > to the community. 
> 
> right ... getting on this right now.

Excellent. 

Thanks Paul,

Liz