server-side SLD support
Bart van den Eijnden (OSGIS)
bartvde at OSGIS.NL
Thu Nov 2 03:29:37 EST 2006
Paul,
the intention of the SLD keyword would be to be used in server-side WMS
implementations, to be used as the default style.
So I would not recommend using it in Chameleon client MAP files.
Maybe we are putting the scope of this too wide ..... ?
Best regards,
Bart
--
Bart van den Eijnden
OSGIS, Open Source GIS
http://www.osgis.nl
--------- Oorspronkelijk bericht --------
Van: Paul Spencer <pspencer at DMSOLUTIONS.CA>
Naar: MAPSERVER-DEV at LISTS.UMN.EDU <MAPSERVER-DEV at LISTS.UMN.EDU>
Onderwerp: Re: [UMN_MAPSERVER-DEV] server-side SLD support
Datum: 01/11/06 22:36
> 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/ |
> +-----------------------------------------------------------------+
>
>
More information about the mapserver-dev
mailing list