Call for comments -RFC 39

[Yewondwossen Assefa]

Hi all,

  I have put together an RFC outlining changes that could be done to be
able to support Named styles in WMS/SLD. I would appreciate your
comments on it:

   http://mapserver.gis.umn.edu/development/rfc/ms-rfc-39

Thanks

--
----------------------------------------------------------------
Assefa Yewondwossen
Software Analyst

Email: assefa@...
http://www.dmsolutions.ca/

Phone: [phone] (ext 14)
Fax:   [phone]
----------------------------------------------------------------

[Frank Warmerdam]

Yewondwossen Assefa wrote:
> Hi all,
>
>  I have put together an RFC outlining changes that could be done to be
> able to support Named styles in WMS/SLD. I would appreciate your
> comments on it:
>
>   http://mapserver.gis.umn.edu/development/rfc/ms-rfc-39

Assefa,

I've read it over and it seems reasonable, but I'm not clear on whether
CLASSes are the right level to break out styles.  I can imagine two
alternatives:

1) Do it at the layer level.  Basically if you want a WMS layer to support
two styles, create two different layer objects, and somehow declare style
names for them with a new keyword.  There is already a way of grouping
mapserver layers together to appear as a single WMS layer, right?

One benefit of this approach is that it would also be possible to offer
different styling options that don't directly map to classification.  For
instance, you could have raster layers that use different scaling options
(not based on classification) represented as distinct styles via WMS.

2) Do it at the STYLE level.  Actually declare style names in the styles
and have these selectable in a somewhat similar fashion to what you are
proposing.

--

One concern I have with your approach, and with option "2" is that in a
multi-style layer, the default rendering will be a sort of mis-mash of
the styles since the default is that all classes are in effect.  Perhaps
if multiple styles are defined, the default (WMS and regular mode) would
be to use the first of the styles instead of all of them.

I don't have an iron in this fire, so I don't feel strongly about this.
I'm just trying to throw up a few options based on mild unease with the
presented solution.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@...
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

[Stephen Woodbridge]

Yewondwossen Assefa wrote:

> Hi all,
>
>  I have put together an RFC outlining changes that could be done to be
> able to support Named styles in WMS/SLD. I would appreciate your
> comments on it:
>
>   http://mapserver.gis.umn.edu/development/rfc/ms-rfc-39
>
> Thanks
>

Assefa,

Thank you for a well written RFC. I have a couple of questions/comments.

When I think of "NamedStyles", I think of a section of the mapfile that
just has a bunch of STYLE blocks, that can be reused anywhere by
referencing there names. This make the STYLE object reusable via the
name reference. Also redefining a STYLE only needs to be done in one
place not N places, which greatly simplifies the mapfile maintenance.

The advantage of this is that it modularizes the mapfile and compresses
it greatly. It would be great to define a 13/11 red/white casement road
STYLE and then reference it multiple times in my mapfile via its name
for example.

Your proposal instead moves us in the opposite direction of adding more
text tags to the layers and making them more verbose and less
comprehensible.

Was thought given to anything similar to my description about? What
other implementations were considered and rejected? Why? if any.

Would the above idea be compatible with WMS/SLD issues you are trying to
solve or could it be adapted to this problem?

What are the levels of effort of these two implementations?

Thanks,
   -Steve W

[Bart van den Eijnden-3]

Hi Assefa,

so the CLASSGROUP would act as the default style if there are classes
within the same LAYER with different GROUPs defined? Maybe mention
this explicitly in the proposal.

Also, styles can have a title and an abstract next to a name. How
would one set this? Using METADATA like "wms_style_myclassgroup_title"
etc.?

Basically I feel the need for a higher object, something like THEME or
CLASSIFICATION which groups together a set of classes. This would also
make it easier to re-use blocks of classes between several layers
without having to copy/paste them. But I can understand if this is
outside of the scope of this RFC :-)

Best regards,
Bart

On Nov 15, 2007 3:50 PM, Yewondwossen Assefa <yassefa@...> wrote:

> Hi all,
>
>   I have put together an RFC outlining changes that could be done to be
> able to support Named styles in WMS/SLD. I would appreciate your
> comments on it:
>
>    http://mapserver.gis.umn.edu/development/rfc/ms-rfc-39
>
> Thanks
>
> --
> ----------------------------------------------------------------
> Assefa Yewondwossen
> Software Analyst
>
> Email: assefa@...
> http://www.dmsolutions.ca/
>
> Phone: [phone] (ext 14)
> Fax:   [phone]
> ----------------------------------------------------------------
>

[Yewondwossen Assefa]

Frank Warmerdam wrote:

> Yewondwossen Assefa wrote:
>> Hi all,
>>
>>  I have put together an RFC outlining changes that could be done to be
>> able to support Named styles in WMS/SLD. I would appreciate your
>> comments on it:
>>
>>   http://mapserver.gis.umn.edu/development/rfc/ms-rfc-39
>
> Assefa,
>
> I've read it over and it seems reasonable, but I'm not clear on whether
> CLASSes are the right level to break out styles.  I can imagine two
> alternatives:
>
> 1) Do it at the layer level.  Basically if you want a WMS layer to support
> two styles, create two different layer objects, and somehow declare style
> names for them with a new keyword.  There is already a way of grouping
> mapserver layers together to appear as a single WMS layer, right?
>
> One benefit of this approach is that it would also be possible to offer
> different styling options that don't directly map to classification.  For
> instance, you could have raster layers that use different scaling options
> (not based on classification) represented as distinct styles via WMS.
>

  I actually did not think of this approch. Yes there is a possibility
to group layers (for wms purpose) using I believe the group parameter. I
am not convinced though that it is reasonable to ask to duplicate layers
in the map file to be able to specify styles although I might be wrong.

> 2) Do it at the STYLE level.  Actually declare style names in the styles
> and have these selectable in a somewhat similar fashion to what you are
> proposing.
>

  In my opinion I think this approach is also good. I was inclined to
break it at the class level for a couple of reasons:
  * the "Style" terminology used in the SLD is more or less equivalent
to one or several classes in MapServer. The SLD defines UserStyle and
NamedStyle as being equivalent and c
  * MapServer currently generates a UserStyle including all the classes
that are are available in the layer. Having the break at the class level
would allow this to continue working without much changes
  * Since we advertise 'styles' per layer, It seemed more logical to
allow this setting to "select"  classes instead of selecting styles.

Not sure what others think about this particular issue.

> --
>
> One concern I have with your approach, and with option "2" is that in a
> multi-style layer, the default rendering will be a sort of mis-mash of
> the styles since the default is that all classes are in effect.  Perhaps
> if multiple styles are defined, the default (WMS and regular mode) would
> be to use the first of the styles instead of all of them.
>

The way I was thinking is that if someone is setting a wms server and
want to advertise several styles, he would setup a default
representation initially doing something like this in this mapfile:

   layer
     classgroup "default"
     class
       group "default"
     end
     class
       group "anotherstyle"
     end

This would allow to have a default style available if STYLES is not
given (or draws the layer using MapServer in mode-map)

> I don't have an iron in this fire, so I don't feel strongly about this.
> I'm just trying to throw up a few options based on mild unease with the
> presented solution.
>

  Thanks for the comments.


--
----------------------------------------------------------------
Assefa Yewondwossen
Software Analyst

Email: assefa@...
http://www.dmsolutions.ca/

Phone: [phone] (ext 14)
Fax:   [phone]
----------------------------------------------------------------

[Yewondwossen Assefa]

Steve,

Stephen Woodbridge wrote:

> Yewondwossen Assefa wrote:
>> Hi all,
>>
>>  I have put together an RFC outlining changes that could be done to be
>> able to support Named styles in WMS/SLD. I would appreciate your
>> comments on it:
>>
>>   http://mapserver.gis.umn.edu/development/rfc/ms-rfc-39
>>
>> Thanks
>>
>
> Assefa,
>
> Thank you for a well written RFC. I have a couple of questions/comments.
>
> When I think of "NamedStyles", I think of a section of the mapfile that
> just has a bunch of STYLE blocks, that can be reused anywhere by
> referencing there names. This make the STYLE object reusable via the
> name reference. Also redefining a STYLE only needs to be done in one
> place not N places, which greatly simplifies the mapfile maintenance.
>
> The advantage of this is that it modularizes the mapfile and compresses
> it greatly. It would be great to define a 13/11 red/white casement road
> STYLE and then reference it multiple times in my mapfile via its name
> for example.
>
> Your proposal instead moves us in the opposite direction of adding more
> text tags to the layers and making them more verbose and less
> comprehensible.
>
> Was thought given to anything similar to my description about? What
> other implementations were considered and rejected? Why? if any.
>

> Would the above idea be compatible with WMS/SLD issues you are trying to
> solve or could it be adapted to this problem?
>

  I agree with you (and Bart who made the same remarks), that have a
representation table (RST) at some higher level and being able to access
the "styles" by name in the layer would be a great addition. We could
have something similar to what we do with symbol files and attach the
RST to a map file.  I used the term NamedStyles in the RFC since that is
what is used in the SLD specifications and I understand that outside the
SLD world it's interpretation could lead to a confusion.

  But I think, I am not addressing the RST support in this RFC, at least
not intentionally :)
  I also think that even if we had this RST concept in MapServer, I
would still need to find a way to define/publish  several mutually
exclusive styles on a layer. The mechanism proposed I think could well
be applied even if  Mapserver implements an RST

> What are the levels of effort of these two implementations?
>

  I did not estimate really what It would take to implement and RST in
Mapserver although this idea has been floating around for a long time.
It would be interesting to see in details how this would be implemented.
I am convinced that it could be a good addition to Mapserver.


Thnaks
> Thanks,
>   -Steve W
>


--
----------------------------------------------------------------
Assefa Yewondwossen
Software Analyst

Email: assefa@...
http://www.dmsolutions.ca/

Phone: [phone] (ext 14)
Fax:   [phone]
----------------------------------------------------------------

[Yewondwossen Assefa]

Bart van den Eijnden wrote:
> Hi Assefa,
>
> so the CLASSGROUP would act as the default style if there are classes
> within the same LAYER with different GROUPs defined? Maybe mention
> this explicitly in the proposal.
>

  Yes. I will explicitly add this.

> Also, styles can have a title and an abstract next to a name. How
> would one set this? Using METADATA like "wms_style_myclassgroup_title"
> etc.?
>

  I realize that but wanted to use for now the style name as the title.
Using a metadata is a good idea I think

> Basically I feel the need for a higher object, something like THEME or
> CLASSIFICATION which groups together a set of classes. This would also
> make it easier to re-use blocks of classes between several layers
> without having to copy/paste them. But I can understand if this is
> outside of the scope of this RFC :-)
>
  I agree with this, I think this is what Steve raised too and I hope I
mostly answered to this in that e-mail.


Thnaks

> Best regards,
> Bart
>
> On Nov 15, 2007 3:50 PM, Yewondwossen Assefa <yassefa@...> wrote:
>> Hi all,
>>
>>   I have put together an RFC outlining changes that could be done to be
>> able to support Named styles in WMS/SLD. I would appreciate your
>> comments on it:
>>
>>    http://mapserver.gis.umn.edu/development/rfc/ms-rfc-39
>>
>> Thanks
>>
>> --
>> ----------------------------------------------------------------
>> Assefa Yewondwossen
>> Software Analyst
>>
>> Email: assefa@...
>> http://www.dmsolutions.ca/
>>
>> Phone: [phone] (ext 14)
>> Fax:   [phone]
>> ----------------------------------------------------------------
>>
>

--
----------------------------------------------------------------
Assefa Yewondwossen
Software Analyst

Email: assefa@...
http://www.dmsolutions.ca/

Phone: [phone] (ext 14)
Fax:   [phone]
----------------------------------------------------------------

[Frank Warmerdam]

Yewondwossen Assefa wrote:

>> 1) Do it at the layer level.  Basically if you want a WMS layer to
>> support
>> two styles, create two different layer objects, and somehow declare style
>> names for them with a new keyword.  There is already a way of grouping
>> mapserver layers together to appear as a single WMS layer, right?
>>
>> One benefit of this approach is that it would also be possible to offer
>> different styling options that don't directly map to classification.  For
>> instance, you could have raster layers that use different scaling options
>> (not based on classification) represented as distinct styles via WMS.
>>
>
>  I actually did not think of this approch. Yes there is a possibility to
> group layers (for wms purpose) using I believe the group parameter. I am
> not convinced though that it is reasonable to ask to duplicate layers in
> the map file to be able to specify styles although I might be wrong.

Assefa,

Well, I can see that this does result in even more duplication.

>> 2) Do it at the STYLE level.  Actually declare style names in the styles
>> and have these selectable in a somewhat similar fashion to what you are
>> proposing.
>>
>
>  In my opinion I think this approach is also good. I was inclined to
> break it at the class level for a couple of reasons:
>  * the "Style" terminology used in the SLD is more or less equivalent to
> one or several classes in MapServer. The SLD defines UserStyle and
> NamedStyle as being equivalent and c
>  * MapServer currently generates a UserStyle including all the classes
> that are are available in the layer. Having the break at the class level
> would allow this to continue working without much changes
>  * Since we advertise 'styles' per layer, It seemed more logical to
> allow this setting to "select"  classes instead of selecting styles.
>
> Not sure what others think about this particular issue.

Yes, I see your point.

>> One concern I have with your approach, and with option "2" is that in a
>> multi-style layer, the default rendering will be a sort of mis-mash of
>> the styles since the default is that all classes are in effect.  Perhaps
>> if multiple styles are defined, the default (WMS and regular mode) would
>> be to use the first of the styles instead of all of them.
>>
>
> The way I was thinking is that if someone is setting a wms server and
> want to advertise several styles, he would setup a default
> representation initially doing something like this in this mapfile:
>
>   layer
>     classgroup "default"
>     class
>       group "default"
>     end
>     class
>       group "anotherstyle"
>     end
>
> This would allow to have a default style available if STYLES is not
> given (or draws the layer using MapServer in mode-map)

I believe I had misunderstood.  So the classgroup declaration just defines
which style group will be used by default if it is not overridden using
STYLE= or another override mechanism?  This makes sense, but perhaps need
to be made as clear as possible in eventual documentation.

I am supportive of this RFC.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@...
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

[Yewondwossen Assefa]

Frank, all

> I believe I had misunderstood.  So the classgroup declaration just defines
> which style group will be used by default if it is not overridden using
> STYLE= or another override mechanism?  This makes sense, but perhaps need
> to be made as clear as possible in eventual documentation.
>

  I have added a note in the RFC to clarify a bit more the use of
CLASSGROUP.


I would like to push for more comments or a vote on this.

Thanks

--
----------------------------------------------------------------
Assefa Yewondwossen
Software Analyst

Email: assefa@...
http://www.dmsolutions.ca/

Phone: [phone] (ext 14)
Fax:   [phone]
----------------------------------------------------------------

[Daniel Morissette]

Yewondwossen Assefa wrote:

> Bart van den Eijnden wrote:
>> Basically I feel the need for a higher object, something like THEME or
>> CLASSIFICATION which groups together a set of classes. This would also
>> make it easier to re-use blocks of classes between several layers
>> without having to copy/paste them. But I can understand if this is
>> outside of the scope of this RFC :-)
>>
>  I agree with this, I think this is what Steve raised too and I hope I
> mostly answered to this in that e-mail.
>
>

Guys,

Sorry for being late to the game... hopefully it's not too late.

What bugged me initially was the use of text strings as class group
names and the fact that we'd need to do string comparisons to match
class group names for every class evaluation when rendering... leading
to a guaranteed performance hit unless we do something to cache the
results of the string comparisons.

I am also (like Bart) trying to find a way that we could add a higher
level object to group classes instead of using text tags inside the
current classes. That new level of object would correspond to SLD Styles
but since the keyword STYLE is already used for something else in
MapServer we cannot use it here. I was looking for a name for this new
beast and could not find one... until I read Bart's THEME idea... I
think this may be what we need.

Here is an example of what I'm thinking, adapting your RFC-29 example to
use the THEME concept:

LAYER
  ...
  USETHEME "group1"
  ...
  THEME
    NAME "group1"
    CLASS
      NAME "name1"
      ...
    END
    CLASS
      NAME "name3"
      ...
    END
  END
  THEME
    NAME "group2"
    CLASS
      NAME "name2"
      ...
    END
  END
  ...


For the time being, classes defined at the top-level of a layer (i.e.
not part of a THEME block) would be part of the "default" theme... this
way old mapfiles continue to work.

Then the day we want to implement the concept of "style table"... err...
I mean "theme table" at the mapfile level, we would allow the definition
of THEMES at the top level in a map, or in an external THEMESET file to
be consistent with SYMBOLSET/FONTSET terminology.

Just some late Friday afternoon thinking... I'm really not sure we got
all bases covered... and this definitely does not map perfectly to the
RST concept that I and Assefa used to work with in a previous life, but
at least that would be closer.

Daniel
--
Daniel Morissette
http://www.mapgears.com/

[Yewondwossen Assefa]

Daniel Morissette wrote:

> Yewondwossen Assefa wrote:
>> Bart van den Eijnden wrote:
>>> Basically I feel the need for a higher object, something like THEME or
>>> CLASSIFICATION which groups together a set of classes. This would also
>>> make it easier to re-use blocks of classes between several layers
>>> without having to copy/paste them. But I can understand if this is
>>> outside of the scope of this RFC :-)
>>>
>>  I agree with this, I think this is what Steve raised too and I hope I
>> mostly answered to this in that e-mail.
>>
>>
>
> Guys,
>
> Sorry for being late to the game... hopefully it's not too late.
>

  No. I am expecting Steve to comment on this. I guess It is never too
late until maybe the votes has started.

> What bugged me initially was the use of text strings as class group
> names and the fact that we'd need to do string comparisons to match
> class group names for every class evaluation when rendering... leading
> to a guaranteed performance hit unless we do something to cache the
> results of the string comparisons.
>

Good point. What we could do to address this is to cache the results
(the classe indexes of valid classes when a CLASSSGROUP is defined) at
the first call to msShapeGetClass. This would be done for around vector
drawing/querying functions. The cache would be reset after drawing the
layer.

> I am also (like Bart) trying to find a way that we could add a higher
> level object to group classes instead of using text tags inside the
> current classes. That new level of object would correspond to SLD Styles
> but since the keyword STYLE is already used for something else in
> MapServer we cannot use it here. I was looking for a name for this new
> beast and could not find one... until I read Bart's THEME idea... I
> think this may be what we need.
>
> Here is an example of what I'm thinking, adapting your RFC-29 example to
> use the THEME concept:
>
> LAYER
>  ...
>  USETHEME "group1"
>  ...
>  THEME
>    NAME "group1"
>    CLASS
>      NAME "name1"
>      ...
>    END
>    CLASS
>      NAME "name3"
>      ...
>    END
>  END
>  THEME
>    NAME "group2"
>    CLASS
>      NAME "name2"
>      ...
>    END
>  END
>  ...
>
>
> For the time being, classes defined at the top-level of a layer (i.e.
> not part of a THEME block) would be part of the "default" theme... this
> way old mapfiles continue to work.
>
> Then the day we want to implement the concept of "style table"... err...
> I mean "theme table" at the mapfile level, we would allow the definition
> of THEMES at the top level in a map, or in an external THEMESET file to
> be consistent with SYMBOLSET/FONTSET terminology.
>

I like the idea of the Theme concept.  I have not looked into the
details of implementation but I believe the changes needed in MapServer
to accommodate a new theme/class/style architecture would be substantial
  Would you agree with that?
  When/if we decide to add the concept of themset and restructure the
current architecture, we could possibly review/deprecate the way
classgroups are proposed in this RFC. But this restructuring would
definitely need more discussion (for example how so we factor into this
the idea of using SLD instead of classes, would it be possible to use an
sld as a themeset, ...).
At the end what this RFC was trying to address was a specific user need
with minimal impact on the current MapServer architecture.


> Just some late Friday afternoon thinking... I'm really not sure we got
> all bases covered... and this definitely does not map perfectly to the
> RST concept that I and Assefa used to work with in a previous life, but
> at least that would be closer.
>
> Daniel


--
----------------------------------------------------------------
Assefa Yewondwossen
Software Analyst

Email: assefa@...
http://www.dmsolutions.ca/

Phone: [phone] (ext 14)
Fax:   [phone]
----------------------------------------------------------------

[Steve Lime]

My Appologies, I haven't been watching mapserver-dev closely for the last couple
of days. I gotta kill the auto filing for mapserver-dev and mapserver-users...

After reading Daniel's most recent comments I guess I kinda like the theme idea
too. That said, it's a good more disruptive than the group idea, at least for mapfile
parsing and mapscript access. I think the theme idea would be easier to implement
for the drawing and query code, just reference the right theme and proceed like
now. Which to pick...

For mapfile parsing we could handle themes the way we handled moving things
like COLORs from a classObj to a styleObj. The parser still recognizes COLOR at
the class level but actually stuffs that value into style[0]. So, if a CLASS were
encountered at the layerObj level you'd in essence be populating theme[0] in
the layerObj. So, you could maintain mapfile backwards compatibility. There would
always be at least one theme.

The bigger problem would be MapScript I think. I wonder if all the layer methods
for accessing classes would fall apart. Perhaps not if the theme index were optional
and defaulted to 0 so code like $layer->getClass(0); could possibly still work.

All the copying code etc... would need to be fixed to deal with one more level of
hierarchy.

So, the theme idea touches a lot more code but feels like less of a kludge. Is there
enough funding to pursue that extra work?

Also, depending on how backwards compatibility with mapfiles (I'm sure that can be
made to work) and mapscript is an issue I'm not sure this feels like a 5.2 modification,
more like a 6.0. If compatible, 5.2, if compatibility is broken, then 6.0.

Steve

>>> Yewondwossen Assefa <yassefa@...> 11/26/07 4:40 PM >>>
Steve,

  If you have a chance, can you comment on this. I would like to have
your inputs before either going forward with a vote or retract the RFC.

Thanks

Steve Lime wrote:

> I need to take a look at this and compare notes with the discussion we had a bit ago. I'll
> try to do that in the next few days.
>
> Steve
>
>>>> On 11/20/2007 at 2:53 PM, in message <4743495D.6000903@...>,
> Yewondwossen Assefa <yassefa@...> wrote:
>> Frank, all
>>
>>> I believe I had misunderstood.  So the classgroup declaration just defines
>>> which style group will be used by default if it is not overridden using
>>> STYLE= or another override mechanism?  This makes sense, but perhaps need
>>> to be made as clear as possible in eventual documentation.
>>>
>>   I have added a note in the RFC to clarify a bit more the use of
>> CLASSGROUP.
>>
>>
>> I would like to push for more comments or a vote on this.
>>
>> Thanks
>
>

--
----------------------------------------------------------------
Assefa Yewondwossen
Software Analyst

Email: assefa@...
http://www.dmsolutions.ca/

Phone: [phone] (ext 14)
Fax:   [phone]
----------------------------------------------------------------

[Yewondwossen Assefa]

  Thanks for the comments.

  You have mentioned several aspects of changes that need to occur to be
able to introduce a level above classes and also keep full backward
compatibly. I have not assessed all the changes needed and beside those
you mentioned, quickly going trough mapserver.h and doing a grep to see
where layer->classs/numclasses gives another aspect of the changes needed.

  I have no doubt that the theme concept is a better architecture. But I
find myself thinking that at the end of the day, the user would get the
same functionality either ways, (of course one being more intuitive),
there would be no risk of backward compatibility issues or major
disruptiveness in the MapServer architecture and I think this has also
merits and should be weighted against the "perfect" architecture.
  I also mentioned in earlier e-mail that there is nothing preventing us
from deprecating one way of doing this if/when the theme concept is
introduced. I put "if" because the idea of a higher level object on top
of the class object is absolutely not new and was briefly discussed when
I initially worked on the SLD support and realized the need of it, and
that was in 2003.  For some reason (possibly funding/time/demand ), It
was never pursued. This is not an indication that it will not be
implemented soon, but just to note that it could also take several years
before something is done.

I am not sure at this time if I will have time/funding to do changes
needed for the theme. I also think that this feels more like something
to be done for a major release with all other considerations such as
reviewing the way we approach styling, the use of a styling file, etc ...

  Best Regards,

Steve Lime wrote:

> My Appologies, I haven't been watching mapserver-dev closely for the last couple
> of days. I gotta kill the auto filing for mapserver-dev and mapserver-users...
>
> After reading Daniel's most recent comments I guess I kinda like the theme idea
> too. That said, it's a good more disruptive than the group idea, at least for mapfile
> parsing and mapscript access. I think the theme idea would be easier to implement
> for the drawing and query code, just reference the right theme and proceed like
> now. Which to pick...
>
> For mapfile parsing we could handle themes the way we handled moving things
> like COLORs from a classObj to a styleObj. The parser still recognizes COLOR at
> the class level but actually stuffs that value into style[0]. So, if a CLASS were
> encountered at the layerObj level you'd in essence be populating theme[0] in
> the layerObj. So, you could maintain mapfile backwards compatibility. There would
> always be at least one theme.
>
> The bigger problem would be MapScript I think. I wonder if all the layer methods
> for accessing classes would fall apart. Perhaps not if the theme index were optional
> and defaulted to 0 so code like $layer->getClass(0); could possibly still work.
>
> All the copying code etc... would need to be fixed to deal with one more level of
> hierarchy.
>
> So, the theme idea touches a lot more code but feels like less of a kludge. Is there
> enough funding to pursue that extra work?
>
> Also, depending on how backwards compatibility with mapfiles (I'm sure that can be
> made to work) and mapscript is an issue I'm not sure this feels like a 5.2 modification,
> more like a 6.0. If compatible, 5.2, if compatibility is broken, then 6.0.
>
> Steve
>

>>>> Yewondwossen Assefa <yassefa@...> 11/26/07 4:40 PM >>>
> Steve,
>
>   If you have a chance, can you comment on this. I would like to have
> your inputs before either going forward with a vote or retract the RFC.
>
> Thanks
>
> Steve Lime wrote:
>> I need to take a look at this and compare notes with the discussion we had a bit ago. I'll
>> try to do that in the next few days.
>>
>> Steve
>>
>>>>> On 11/20/2007 at 2:53 PM, in message <4743495D.6000903@...>,
>> Yewondwossen Assefa <yassefa@...> wrote:
>>> Frank, all
>>>
>>>> I believe I had misunderstood.  So the classgroup declaration just defines
>>>> which style group will be used by default if it is not overridden using
>>>> STYLE= or another override mechanism?  This makes sense, but perhaps need
>>>> to be made as clear as possible in eventual documentation.
>>>>
>>>   I have added a note in the RFC to clarify a bit more the use of
>>> CLASSGROUP.
>>>
>>>
>>> I would like to push for more comments or a vote on this.
>>>
>>> Thanks
>>
>
>

--
----------------------------------------------------------------
Assefa Yewondwossen
Software Analyst

Email: assefa@...
http://www.dmsolutions.ca/

Phone: [phone] (ext 14)
Fax:   [phone]
----------------------------------------------------------------

[Steve Lime]

Then I guess we're facing a "better than nothing" decision. Which is ok by me
(I'm often function over form) with the option later of changing if warranted.

Steve

>>> Yewondwossen Assefa <yassefa@...> 11/29/07 1:23 PM >>>

  Thanks for the comments.

  You have mentioned several aspects of changes that need to occur to be
able to introduce a level above classes and also keep full backward
compatibly. I have not assessed all the changes needed and beside those
you mentioned, quickly going trough mapserver.h and doing a grep to see
where layer->classs/numclasses gives another aspect of the changes needed.

  I have no doubt that the theme concept is a better architecture. But I
find myself thinking that at the end of the day, the user would get the
same functionality either ways, (of course one being more intuitive),
there would be no risk of backward compatibility issues or major
disruptiveness in the MapServer architecture and I think this has also
merits and should be weighted against the "perfect" architecture.
  I also mentioned in earlier e-mail that there is nothing preventing us
from deprecating one way of doing this if/when the theme concept is
introduced. I put "if" because the idea of a higher level object on top
of the class object is absolutely not new and was briefly discussed when
I initially worked on the SLD support and realized the need of it, and
that was in 2003.  For some reason (possibly funding/time/demand ), It
was never pursued. This is not an indication that it will not be
implemented soon, but just to note that it could also take several years
before something is done.

I am not sure at this time if I will have time/funding to do changes
needed for the theme. I also think that this feels more like something
to be done for a major release with all other considerations such as
reviewing the way we approach styling, the use of a styling file, etc ...

  Best Regards,

Steve Lime wrote:

> My Appologies, I haven't been watching mapserver-dev closely for the last couple
> of days. I gotta kill the auto filing for mapserver-dev and mapserver-users...
>
> After reading Daniel's most recent comments I guess I kinda like the theme idea
> too. That said, it's a good more disruptive than the group idea, at least for mapfile
> parsing and mapscript access. I think the theme idea would be easier to implement
> for the drawing and query code, just reference the right theme and proceed like
> now. Which to pick...
>
> For mapfile parsing we could handle themes the way we handled moving things
> like COLORs from a classObj to a styleObj. The parser still recognizes COLOR at
> the class level but actually stuffs that value into style[0]. So, if a CLASS were
> encountered at the layerObj level you'd in essence be populating theme[0] in
> the layerObj. So, you could maintain mapfile backwards compatibility. There would
> always be at least one theme.
>
> The bigger problem would be MapScript I think. I wonder if all the layer methods
> for accessing classes would fall apart. Perhaps not if the theme index were optional
> and defaulted to 0 so code like $layer->getClass(0); could possibly still work.
>
> All the copying code etc... would need to be fixed to deal with one more level of
> hierarchy.
>
> So, the theme idea touches a lot more code but feels like less of a kludge. Is there
> enough funding to pursue that extra work?
>
> Also, depending on how backwards compatibility with mapfiles (I'm sure that can be
> made to work) and mapscript is an issue I'm not sure this feels like a 5.2 modification,
> more like a 6.0. If compatible, 5.2, if compatibility is broken, then 6.0.
>
> Steve
>

>>>> Yewondwossen Assefa <yassefa@...> 11/26/07 4:40 PM >>>
> Steve,
>
>   If you have a chance, can you comment on this. I would like to have
> your inputs before either going forward with a vote or retract the RFC.
>
> Thanks
>
> Steve Lime wrote:
>> I need to take a look at this and compare notes with the discussion we had a bit ago. I'll
>> try to do that in the next few days.
>>
>> Steve
>>
>>>>> On 11/20/2007 at 2:53 PM, in message <4743495D.6000903@...>,
>> Yewondwossen Assefa <yassefa@...> wrote:
>>> Frank, all
>>>
>>>> I believe I had misunderstood.  So the classgroup declaration just defines
>>>> which style group will be used by default if it is not overridden using
>>>> STYLE= or another override mechanism?  This makes sense, but perhaps need
>>>> to be made as clear as possible in eventual documentation.
>>>>
>>>   I have added a note in the RFC to clarify a bit more the use of
>>> CLASSGROUP.
>>>
>>>
>>> I would like to push for more comments or a vote on this.
>>>
>>> Thanks
>>
>
>

--
----------------------------------------------------------------
Assefa Yewondwossen
Software Analyst

Email: assefa@...
http://www.dmsolutions.ca/

Phone: [phone] (ext 14)
Fax:   [phone]
----------------------------------------------------------------

[Daniel Morissette]

I'm usually for keeping things simple... I just not convinced that the
CLASSGROUP proposal will necessarily result in a simpler codebase at the
end of the day. I'm also worried about potential performance hits and
code complexity.

All that extra mechanic to deal with caching of the string comparisons
on the class group names, the addition of an extra (hidden) member
inside the class object to cache the result, and the modifications to
all places that deal with classes to skip/ignore classes that don't
match the current classgroup will definitely add code complexity.

OTOH, with a higher level object such as THEME, of course we need to
update all places that access classes to make them aware of the theme
object, but once that's done, the resulting code should be cleaner (or I
would hope so anyway).

I don't even think my THEME suggestion could be called a "perfect"
solution either... the perfect solution would be as you suggested, to
rethink the way we approach styling, the use of style files, etc... and
that would take quite a bit of time and thinking.

And in that context we could conclude that implementing THEMEs without
thinking about the long term direction of styling and style tables may
not be a good idea either since we're not sure if THEME is what we'll be
using at that time... which takes us back to the "better than nothing"
CLASSGROUP solution.

I guess I'm not sure any more...

Daniel

Steve Lime wrote:

> Then I guess we're facing a "better than nothing" decision. Which is ok by me
> (I'm often function over form) with the option later of changing if warranted.
>
> Steve
>
>>>> Yewondwossen Assefa <yassefa@...> 11/29/07 1:23 PM >>>
>
>   Thanks for the comments.
>
>   You have mentioned several aspects of changes that need to occur to be
> able to introduce a level above classes and also keep full backward
> compatibly. I have not assessed all the changes needed and beside those
> you mentioned, quickly going trough mapserver.h and doing a grep to see
> where layer->classs/numclasses gives another aspect of the changes needed.
>
>   I have no doubt that the theme concept is a better architecture. But I
> find myself thinking that at the end of the day, the user would get the
> same functionality either ways, (of course one being more intuitive),
> there would be no risk of backward compatibility issues or major
> disruptiveness in the MapServer architecture and I think this has also
> merits and should be weighted against the "perfect" architecture.
>   I also mentioned in earlier e-mail that there is nothing preventing us
> from deprecating one way of doing this if/when the theme concept is
> introduced. I put "if" because the idea of a higher level object on top
> of the class object is absolutely not new and was briefly discussed when
> I initially worked on the SLD support and realized the need of it, and
> that was in 2003.  For some reason (possibly funding/time/demand ), It
> was never pursued. This is not an indication that it will not be
> implemented soon, but just to note that it could also take several years
> before something is done.
>
> I am not sure at this time if I will have time/funding to do changes
> needed for the theme. I also think that this feels more like something
> to be done for a major release with all other considerations such as
> reviewing the way we approach styling, the use of a styling file, etc ...
>
>   Best Regards,
>
> Steve Lime wrote:
>> My Appologies, I haven't been watching mapserver-dev closely for the last couple
>> of days. I gotta kill the auto filing for mapserver-dev and mapserver-users...
>>
>> After reading Daniel's most recent comments I guess I kinda like the theme idea
>> too. That said, it's a good more disruptive than the group idea, at least for mapfile
>> parsing and mapscript access. I think the theme idea would be easier to implement
>> for the drawing and query code, just reference the right theme and proceed like
>> now. Which to pick...
>>
>> For mapfile parsing we could handle themes the way we handled moving things
>> like COLORs from a classObj to a styleObj. The parser still recognizes COLOR at
>> the class level but actually stuffs that value into style[0]. So, if a CLASS were
>> encountered at the layerObj level you'd in essence be populating theme[0] in
>> the layerObj. So, you could maintain mapfile backwards compatibility. There would
>> always be at least one theme.
>>
>> The bigger problem would be MapScript I think. I wonder if all the layer methods
>> for accessing classes would fall apart. Perhaps not if the theme index were optional
>> and defaulted to 0 so code like $layer->getClass(0); could possibly still work.
>>
>> All the copying code etc... would need to be fixed to deal with one more level of
>> hierarchy.
>>
>> So, the theme idea touches a lot more code but feels like less of a kludge. Is there
>> enough funding to pursue that extra work?
>>
>> Also, depending on how backwards compatibility with mapfiles (I'm sure that can be
>> made to work) and mapscript is an issue I'm not sure this feels like a 5.2 modification,
>> more like a 6.0. If compatible, 5.2, if compatibility is broken, then 6.0.
>>
>> Steve
>>
>
>>>>> Yewondwossen Assefa <yassefa@...> 11/26/07 4:40 PM >>>
>> Steve,
>>
>>   If you have a chance, can you comment on this. I would like to have
>> your inputs before either going forward with a vote or retract the RFC.
>>
>> Thanks
>>
>> Steve Lime wrote:
>>> I need to take a look at this and compare notes with the discussion we had a bit ago. I'll
>>> try to do that in the next few days.
>>>
>>> Steve
>>>
>>>>>> On 11/20/2007 at 2:53 PM, in message <4743495D.6000903@...>,
>>> Yewondwossen Assefa <yassefa@...> wrote:
>>>> Frank, all
>>>>
>>>>> I believe I had misunderstood.  So the classgroup declaration just defines
>>>>> which style group will be used by default if it is not overridden using
>>>>> STYLE= or another override mechanism?  This makes sense, but perhaps need
>>>>> to be made as clear as possible in eventual documentation.
>>>>>
>>>>   I have added a note in the RFC to clarify a bit more the use of
>>>> CLASSGROUP.
>>>>
>>>>
>>>> I would like to push for more comments or a vote on this.
>>>>
>>>> Thanks
>>
>
>

--
Daniel Morissette
http://www.mapgears.com/

[Yewondwossen Assefa]

Daniel Morissette wrote:

> I'm usually for keeping things simple... I just not convinced that the
> CLASSGROUP proposal will necessarily result in a simpler codebase at the
> end of the day. I'm also worried about potential performance hits and
> code complexity.
>
> All that extra mechanic to deal with caching of the string comparisons
> on the class group names, the addition of an extra (hidden) member
> inside the class object to cache the result, and the modifications to
> all places that deal with classes to skip/ignore classes that don't
> match the current classgroup will definitely add code complexity.
>

  What I was planning to do is the following:
   - draw and query function that loops though all valid shapes and call
  msShapeGetClass/msGetClass would have the ability to pass an array of
"valid"  classes if the classgroup is set. This array is computed once
for each layer and freed at the end of the draw/query loop. The
performance impact in this case is minimal and I think It addresses the
performance issues you raised initially.  I am not planing to keep this
cache inside the layer object for further use.

  - other parts of the code that would be affected by this changes would
not use any caching but would do a test using the layer->classgroup and
skip classes when needed. I think there would not be a performance issue
here like for example when drawing the legend, the cost of the test on
classgroup would be minimal compared to the actual drawing of the legend.

  Not sure, but hopefully this address part of your concerns.

> OTOH, with a higher level object such as THEME, of course we need to
> update all places that access classes to make them aware of the theme
> object, but once that's done, the resulting code should be cleaner (or I
> would hope so anyway).
>
> I don't even think my THEME suggestion could be called a "perfect"
> solution either... the perfect solution would be as you suggested, to
> rethink the way we approach styling, the use of style files, etc... and
> that would take quite a bit of time and thinking.
>
> And in that context we could conclude that implementing THEMEs without
> thinking about the long term direction of styling and style tables may
> not be a good idea either since we're not sure if THEME is what we'll be
> using at that time... which takes us back to the "better than nothing"
> CLASSGROUP solution.
>

That is my point. The reality for me is that there is no time/budget to
rethink the styling approach and there is a functionality that could be
addressed using this solution.

> I guess I'm not sure any more...
>

  Me neither :) Another reality is that I need  go ahead or retract this
RFC (which was out 2 week ago already) so I am able to plan my own work
schedule. I will wait for few days/more comments and I would then
resubmit it officially  for a vote.

Best Regards,

> Daniel
>
> Steve Lime wrote:
>> Then I guess we're facing a "better than nothing" decision. Which is
>> ok by me
>> (I'm often function over form) with the option later of changing if
>> warranted.
>> Steve
>>
>>>>> Yewondwossen Assefa <yassefa@...> 11/29/07 1:23 PM >>>
>>
>>   Thanks for the comments.
>>
>>   You have mentioned several aspects of changes that need to occur to
>> be able to introduce a level above classes and also keep full backward
>> compatibly. I have not assessed all the changes needed and beside
>> those you mentioned, quickly going trough mapserver.h and doing a grep
>> to see where layer->classs/numclasses gives another aspect of the
>> changes needed.
>>
>>   I have no doubt that the theme concept is a better architecture. But
>> I find myself thinking that at the end of the day, the user would get
>> the same functionality either ways, (of course one being more
>> intuitive), there would be no risk of backward compatibility issues or
>> major disruptiveness in the MapServer architecture and I think this
>> has also merits and should be weighted against the "perfect"
>> architecture.
>>   I also mentioned in earlier e-mail that there is nothing preventing
>> us from deprecating one way of doing this if/when the theme concept is
>> introduced. I put "if" because the idea of a higher level object on
>> top of the class object is absolutely not new and was briefly
>> discussed when I initially worked on the SLD support and realized the
>> need of it, and that was in 2003.  For some reason (possibly
>> funding/time/demand ), It was never pursued. This is not an indication
>> that it will not be implemented soon, but just to note that it could
>> also take several years before something is done.
>>
>> I am not sure at this time if I will have time/funding to do changes
>> needed for the theme. I also think that this feels more like something
>> to be done for a major release with all other considerations such as
>> reviewing the way we approach styling, the use of a styling file, etc ...
>>
>>   Best Regards,
>>
>> Steve Lime wrote:
>>> My Appologies, I haven't been watching mapserver-dev closely for the
>>> last couple
>>> of days. I gotta kill the auto filing for mapserver-dev and
>>> mapserver-users...
>>>
>>> After reading Daniel's most recent comments I guess I kinda like the
>>> theme idea
>>> too. That said, it's a good more disruptive than the group idea, at
>>> least for mapfile
>>> parsing and mapscript access. I think the theme idea would be easier
>>> to implement
>>> for the drawing and query code, just reference the right theme and
>>> proceed like
>>> now. Which to pick...
>>>
>>> For mapfile parsing we could handle themes the way we handled moving
>>> things
>>> like COLORs from a classObj to a styleObj. The parser still
>>> recognizes COLOR at
>>> the class level but actually stuffs that value into style[0]. So, if
>>> a CLASS were
>>> encountered at the layerObj level you'd in essence be populating
>>> theme[0] in
>>> the layerObj. So, you could maintain mapfile backwards compatibility.
>>> There would
>>> always be at least one theme.
>>>
>>> The bigger problem would be MapScript I think. I wonder if all the
>>> layer methods
>>> for accessing classes would fall apart. Perhaps not if the theme
>>> index were optional
>>> and defaulted to 0 so code like $layer->getClass(0); could possibly
>>> still work.
>>>
>>> All the copying code etc... would need to be fixed to deal with one
>>> more level of
>>> hierarchy.
>>> So, the theme idea touches a lot more code but feels like less of a
>>> kludge. Is there
>>> enough funding to pursue that extra work?
>>> Also, depending on how backwards compatibility with mapfiles (I'm
>>> sure that can be made to work) and mapscript is an issue I'm not sure
>>> this feels like a 5.2 modification, more like a 6.0. If compatible,
>>> 5.2, if compatibility is broken, then 6.0.
>>>
>>> Steve
>>>
>>
>>>>>> Yewondwossen Assefa <yassefa@...> 11/26/07 4:40 PM >>>
>>> Steve,
>>>
>>>   If you have a chance, can you comment on this. I would like to have
>>> your inputs before either going forward with a vote or retract the RFC.
>>>
>>> Thanks
>>>
>>> Steve Lime wrote:
>>>> I need to take a look at this and compare notes with the discussion
>>>> we had a bit ago. I'll
>>>> try to do that in the next few days.
>>>>
>>>> Steve
>>>>
>>>>>>> On 11/20/2007 at 2:53 PM, in message
>>>>>>> <4743495D.6000903@...>,
>>>> Yewondwossen Assefa <yassefa@...> wrote:
>>>>> Frank, all
>>>>>
>>>>>> I believe I had misunderstood.  So the classgroup declaration just
>>>>>> defines
>>>>>> which style group will be used by default if it is not overridden
>>>>>> using
>>>>>> STYLE= or another override mechanism?  This makes sense, but
>>>>>> perhaps need
>>>>>> to be made as clear as possible in eventual documentation.
>>>>>>
>>>>>   I have added a note in the RFC to clarify a bit more the use of
>>>>> CLASSGROUP.
>>>>>
>>>>>
>>>>> I would like to push for more comments or a vote on this.
>>>>>
>>>>> Thanks
>>>
>>
>>
>
>

--
----------------------------------------------------------------
Assefa Yewondwossen
Software Analyst

Email: assefa@...
http://www.dmsolutions.ca/

Phone: [phone] (ext 14)
Fax:   [phone]
----------------------------------------------------------------

[Kralidis,Tom [Ontario]]

>   I have put together an RFC outlining changes that could be
> done to be able to support Named styles in WMS/SLD. I would
> appreciate your comments on it:
>
>    http://mapserver.gis.umn.edu/development/rfc/ms-rfc-39
>

Assefa:

- FYI note that we support STYLES=default in the same manner as STYLES=
- is there an implementation of this?  Do you have this working in
MapServer?

Sounds like a neat addition!

..Tom

[Yewondwossen Assefa]

Kralidis,Tom [Burlington] wrote:

>>   I have put together an RFC outlining changes that could be
>> done to be able to support Named styles in WMS/SLD. I would
>> appreciate your comments on it:
>>
>>    http://mapserver.gis.umn.edu/development/rfc/ms-rfc-39
>>
>
> Assefa:
>
> - FYI note that we support STYLES=default in the same manner as STYLES=

  Yes that is correct. This is also mentioned in the rfc although it is
not very  "visible".

> - is there an implementation of this?  Do you have this working in
> MapServer?
>
  I have done few tests locally and It seems to work for the tests I
have done.

> Sounds like a neat addition!
>
> ..Tom
>


--
----------------------------------------------------------------
Assefa Yewondwossen
Software Analyst

Email: assefa@...
http://www.dmsolutions.ca/

Phone: [phone] (ext 14)
Fax:   [phone]
----------------------------------------------------------------