call for vote on RFC-39

[Yewondwossen Assefa]

Just to follow up on this, I have discussed the use of the class status 
with Steve (see http://trac.osgeo.org/mapserver/ticket/2431) and I would 
not be able to use it to accomplish what I need for RFC-39 purpose. I am 
thus going forward with the initial proposition. I will enter 
appropriate bugs/docs to follow up this addition.

Best Regards,


Yewondwossen Assefa wrote:
> Hi all,
> 
>  Howard proposed on Friday to use a STATUS attribute in the class
> object. I was not aware of the existence of this attribute in the class
> object.  In theory using the status and setting some classes to ON/OFF
> depending on the wms style request would be equivalent in term of
> functionalities of using a classgroup, and for sure would not disrupt or
> introduce any new element in Mapserver.
> 
> But looking into the code, the class status seems to be only in few
> places and I am not sure what the current
> interpretation the classes's status is. For example:
> 
>  - a shape the could be drawn with a class A  and a class B (class A 
> being defined before class B), if Class A has a status OFF and class B 
> with a STATUS ON, the shape will not be drawn at all. I would have 
> assumed that if a class A is OFF, the shape would be draw with class B.
> 
>  - I have not seen any tests for class status in such places as legend, 
> checking if the layer is visible, queryable and such. I would have 
> assumed here again that the class status should be tested when doing 
> these operations.
> 
>  Not sure if the points I mentioned here were just not implemented or 
> explicitly not done. So depending on how the class status was intended 
> to be used, I can certainly  use it to work with for the wms styles 
> (provided I can modify/add the class status use where needed).
> 
> If this is possible, I will adapt the RFC to reflect these changes. The 
> level of effort for me here is similar to the classgroup proposal and I 
> think since there is no new concept for Mapsever in general, it will be 
> better accepted.  As for pulishing/changing styles on the fly, I would 
> certainly introduce a layer level metadata wms_namedstyles (or something 
> similar), that would allow the user to define what styles are available 
> on the layer, and which classes are part of any particular style.
> 
> 
> Best Regards,
> 
> 
> 
> 
> 
> 
> 
> Steve Lime wrote:
>> I'll wait to hear the details then.
>>
>> Steve
>>
>>>>> On 12/7/2007 at 3:28 PM, in message 
>>>>> <4759BB04.7050307 at mapgears.com>, Daniel
>> Morissette <dmorissette at MAPGEARS.COM> wrote:
>>> FYI I saw a discussion on IRC between Howard and Assefa and I think 
>>> they have found a much less disruptive solution, but Assefa needs to 
>>> check a few things before canceling the current proposal. So those 
>>> who are not sure where to stand with respect to this RFC can save 
>>> their energy and wait for an update from Assefa before they vote.
>>>
>>> Daniel
>>>
>>>
>>> Frank Warmerdam wrote:
>>>> Yewondwossen Assefa wrote:
>>>>> Hi all,
>>>>>
>>>>>  I would like to call on a vote on RFC-39 (multi-style support)
>>>>>
>>>>>   http://mapserver.gis.umn.edu/development/rfc/ms-rfc-39
>>>>>  It has been out for already some time and would like to either go 
>>>>> forward with it or find other alternatives.
>>>>>
>>>>>  I start with +1.
>>>> Assefa,
>>>>
>>>> With only some slight hesitation about the approach (as also voiced
>>>> by Steve and Daniel), I'll vote +1.  I think the approach is practical
>>>> and non-disruptive.
>>>>
>>>> Best regards,
>>
> 
> 


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

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

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