Call for comments -RFC 39

[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 at dmsolutions.ca> 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 at dmsolutions.ca> 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 at dmsolutions.ca>,
>>>> Yewondwossen Assefa <yassefa at DMSOLUTIONS.CA> 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 at dmsolutions.ca
http://www.dmsolutions.ca/

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