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@...>, Daniel
> Morissette <
dmorissette@...> 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@...
http://www.dmsolutions.ca/Phone: (613) 565-5056 (ext 14)
Fax: (613) 565-0925
----------------------------------------------------------------
