server-side SLD support

[Steve Lime]

I thought about the selectability too, could be a mapfile writing
option. The key is it's one or the other (all classes
initially or styles initially), not a mix.

Steve

>>> Paul Spencer <pspencer at dmsolutions.ca> 11/01/06 6:35 PM >>>
An editing application (we did one in Chameleon called Studio) works  
with classes in mapscript and can save the result as a style sheet.   
You can load a style sheet (creating the classes) then modify the  
classes using mapscript.

Another thing to consider is a framework like Chameleon where the  
mapfile is saved as part of the user session.  What would be the  
impact there?  In that (specific) case, it would be desirable to just  
save the classes and not the SLD ... especially if it is a URL  
reference and someone changes the remote SLD ... could have an  
interesting result!

I think (since this only impacts mapscript) that the behaviour could  
be explicitly selected by the application, depending on the application

Cheers

Paul

On 1-Nov-06, at 6:03 PM, Steve Lime wrote:

> Why would someone want to mix SLD and MapServer classes? Is there an
> obvious
> use case? I like the idea (for non-OWS use as well), but would prefer
> keeping things
> simple.
>
> Steve
>
>>>> Daniel Morissette <dmorissette at MAPGEARS.COM> 11/1/2006 3:30 PM >>>
> Yewondwossen Assefa wrote:
>>
>>  I am more leaning to say that we should not save the classes
> generated,
>> but only the SLD (marking the classes as temporary as you suggested).
>
>> But when we talk about save, it is done through mapscript, so the
> users
>> will have the ability to manipulate the classes before saving the map
>
>> and next reload of the map will givent diffrent result.
>> If it is a documented and acceptable limitation, I do not see any
>> problem discarding the new classes created.
>>
>
> This kind of inconsistent behavior makes me nervous. What you propose
> reopens the questions that I sent earlier this morning.
>
> I mean someone could load a mapfile with MapScript, not knowing  
> that it
>
> contained a SLD ref. Then modify a few classes (including some coming
> from a SLD) or insert new classes and save the map, expecting the
> changes to be saved, but then because the MapScript code was not
> SLD-aware the changes would actually be lost and odd side-effects  
> might
>
> happen next time the saved map is loaded.
>
> I'm also not clear on whether the current ApplySLD() method is
> sufficient for MapScript apps to interact with this feature if you  
> plan
>
> to maintain both the SLD ref and a set of temporary classes in memory.
>
>>> Maybe if we don't allow people to mix SLD and CLASSes, it would make
>
>>> life easier? But still the generated classes would need to be
> removed
>>> and the SLD keyword written upon saving.
>>>
>>  I still think we should allow the mixing of SLD and CLASS elements
> and
>> mark SLD generated classes as "non savable"
>>
>
> Mixing SLD and CLASS elements would be nice, but if that becomes the
> source of odd side-effects for apps that are not SLD-aware then that's
>
> not good.
>
> Daniel
> -- 
> Daniel Morissette
> http://www.mapgears.com/

+-----------------------------------------------------------------+
|Paul Spencer                          pspencer at dmsolutions.ca    |
+-----------------------------------------------------------------+
|Chief Technology Officer                                         |
|DM Solutions Group Inc                http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+