Class status use should be used/defined

[assefa]

As part of the RFC-39, there is a need to define properly the intention of the class status (ON/OFF) use.

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.

[assefa]

Steve, any feedbacks on this? Can I make the changes as suggested?

[sdlime]

In looking at the code is looks like class status must be explicitly ON/OFF (via the mapfile or mapscript). This may present problems since you could have classes set to OFF which means you'd have to maintain that state as you muck with the status based on groups.

Your first bullet makes sense in the context of class groups, but not in the case of only 1 set of classes. I mean, if I turn a class OFF I don't want to see shapes in that class so I don't want them falling through to other classes. That's why things behave as they do now.

There are probably a couple of scenarios:

1 - CLASS membership doesn't cascade within a group (current) 2 - CLASS membership DOES cascade within a group (new functionality) 3 - CLASS membership DOES cascade between groups, but not within a group (new functionality)

I don't think you can cascade between and within groups. So, I think it would be the easiest to implement 1 & 3, with this rule:

"A shape will belong to the first class it matches within a class group regardless of class status."

You'd probably end up mucking around with msShapeGetClass().

The problem is that you don't need class->status to do this. I think you'll run into problems because users could explicitly set class->status.

Steve

[assefa]

Replying to sdlime:

In looking at the code is looks like class status must be explicitly ON/OFF (via the mapfile or mapscript). This may present problems since you could have classes set to OFF which means you'd have to maintain that state as you muck with the status based on groups. This I think would not be a problem in the sense that all the setting of class status to ON/OFF would be done when responding to a wms request (GetMap? or GetLegendGraphic?); so basically it is a one shot deal before draing the map/legend so we do not need to keep previous status

Your first bullet makes sense in the context of class groups, but not in the case of only 1 set of classes. I mean, if I turn a class OFF I don't want to see shapes in that class so I don't want them falling through to other classes. That's why things behave as they do now.

Basically having 2 styles for wms means that the same shape can be rendered using one class or another depending on the style that is requested. I understand why it works the way it does now.

If I can not change this behavior, I simply don't see how I can use the class status to accomplish what I want.

There are probably a couple of scenarios: 1 - CLASS membership doesn't cascade within a group (current) 2 - CLASS membership DOES cascade within a group (new functionality) 3 - CLASS membership DOES cascade between groups, but not within a group (new functionality) I don't think you can cascade between and within groups. So, I think it would be the easiest to implement 1 & 3, with this rule: "A shape will belong to the first class it matches within a class group regardless of class status." You'd probably end up mucking around with msShapeGetClass().

I did not get all the mechanism you described but I certainly don't want to introduce at the msShapeGetClass other logic than simply either testing a status or testing for a simply if a class should be considered based on the classgroup

The problem is that you don't need class->status to do this. I think you'll run into problems because users could explicitly set class->status.

When Howard proposed the idea, I though It was very appropriate and less controversial but I feel now that I can not really go that route if I can not change the current behavior.

[sdlime]

By changing the current behaviour you mean the cascade based on status (if A is off then try B), right? The problem is that expressions need not be mutually exclusive. For example:

CLASSITEM 'value' CLASS

NAME 'A' EXPRESSION '50'

END CLASS

NAME 'B' EXPRESSION ([value] < 100)

END CLASS # default

NAME 'C'

END

It seems silly but there are times when this makes sense (or is really convenient). With the current rule by setting class A off you'd not display value=50. Plus you wouldn't cascade out of this group, you'd get caught by the others. That's why I was thinking that you'd have to make it work that you'd have to go to the next classgroup not the next class (and hence wouldn't need status).

Because a user can set status (e.g. a group could have 3 ON and 1 OFF) you can't just set only those that are in the right group to ON and the rest to OFF. You could but at an expense.

Sorry if I've confused things.

Steve

[assefa]

That is right : if A if off, it is skipped inside the msShapeGetClass function.

I understand how convenient It could be based on your examples. I will not attempt to change the behavior as part of the RFC-39 and will pursue the introduction of the classgroup as initially proposed.

Other notes just related to class status, I am wondering if the class status is consistent all over Mapserver like:

• should a class set to OFF be rendered in the legend
• should it be tested inside msLayerIsVisible

I have no real answer to this, and frankly since nobody complained, I am assuming people are happy the way it is; just pointing some stuff that seem inconsistent to me.

I guess we should could close this bug.

[sdlime]

Assefa: I'm closing as invalid, we can open other specific tickets as necessary.

Steve