Call for comments -RFC 39

[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 at dmsolutions.ca
http://www.dmsolutions.ca/

Phone: (613) 565-5056 (ext 14)
Fax:   (613) 565-0925
----------------------------------------------------------------