[Chameleon] New Widget :-D

[Paul Spencer]

don't think I responded to this ... comments inline again

Godwin, Elizabeth wrote:
> 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?

wmsparse is written in C and is tricky to modify to capture new 
information.  A better solution (one that we've already started towards) 
is to make wmsparse a php extension and integrate it with sqlite so that 
we have much more flexibility for working with these files.

If you want to attempt something with the current code, however:

* servers.dbf - one record per server

* capab.dbf - one record per layer in a capabilities document.  Layers 
are associated with servers by some index

* bbox.dbf - contains possibly multiple bbox entries per layer.  Layer 
has an index in this file, and each record has a 'next bbox' entry as well

* s[X]srs.txt - srs information for server [X] (index in servers.dbf). 
SRS information is stored one line per layer and layers have an index 
into this file (by line number)

* style.dbf - style information such as name, title, legendurl, 
leg_height, leg_width, leg_format, stylesheet, and styleurl.  Same 
structure as bbox (first style index in capab.dbf, next_id points to 
subsequent styles

a[1]abstract.txt - abstract information, structure same way as s[X]srs.txt

wmsbrowse uses code from common/phpwms to extract information from the 
dbf files and sets the various metadata from that.  In particular, 
server_data_manager.php has a function getLayerObj() that does all the 
steps.

To modify the information captured by wmsparse, you need to modify 
wmsparse itself to pull out the various new pieces  you need and modify 
the following php files:

common/phpwms/dbf.php
common/phpwms/server_data_manager.php
common/phpwms/phpwms.default.php

and it has to be either backwards compatible with the old dbf structure, 
have an upgrade mechanism, or force everyone to clear their old dbfs - hish


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

nope ... but they could be ... see server_data_manager.php, it has all 
the methods to do this sort of stuff

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

you have to first capture this information when parsing the capabilities

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

good luck with modifying the spec any time soon ;)  As suggested, the 
most compliant way with what is available would be to check the server 
cache and add the server if it is not there.  Slow but effective I guess

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

did you file a bug for this?

> 
> I know that was long-winded.  Hopefully you read through it :-)
> 
> Cheers,
> 
> Liz
> 
> 

-- 
+-----------------------------------------------------------------+
|Paul Spencer                           pspencer at dmsolutions.ca   |
+-----------------------------------------------------------------+
|Applications & Software Development                              |
|DM Solutions Group Inc                 http://www.dmsolutions.ca/|
+-----------------------------------------------------------------+