You need to log in before you can comment on or make changes to this bug.
Ok, this problem is more of a useability problem. I was trying to apply two classes on the same feature. eg. I had a base style for the entire world, then with a second class using an expression "Africa" style Africa with a different colour. If the Africa class is below the World class Africa's unique style is over written. Once I promoted the Africa class to the top it worked. When I first saw this problem I thought what I was trying to do could not be done in SLD. Then I thought there was a bug with SECT or Mapserver interpreting my request. Once Zak, corrected me I realized that the user problem came from the fact that when you add a new class it is placed below the first class, when in reality it should be placed on top. This will save people the confusion and having to promote the class above the overlapping style class.
this has to do with the way that mapserver renders classes. You might expect it to work the same way as all the other types of drawing, i.e. it draws each object one after the other (like layers and styles). This is not how classes work. Each feature in a layer is drawn according to the class that it fits into. This means that mapserver evaluates each class as it finds it and if the layer fits the class (expression) then it will use the styles of that class to render the feature and then move to the next feature. This is the important part to understand. It will draw the first class it finds and never draw another one. This means that if you have two classes that could draw the same feature, with two complementary styles (one is a fill and one is an outline for instance) only one class will be used and you will see either the outline or the fill depending on which class comes first in the map file. So when you add a catch-all class at the top of the list, every feature will end up being drawn by that class. There is no 'on top' with mapserver classes ... the debate to add rows before or after the selected one is semi-religious. I think that we will always get different opinions on this issue. I believe that this is a documentation issue and nothing should be done to change it. Well, there could be one thing ... we could have two insert buttons ... an insert before and an insert after button, which I have seen in OpenOffice table functionality ...
dropping to P4 enhancement pending feedback from a larger group
I like the twi insert buttons idea. I think that would solve the usability part of this issue.
I think that is a good idea, I have another suggestion. The order of the classes of a single layer is only a problem, when you have one class that has no expression. Meaning it will apply the style to everything vs. a second class that has an expression and only styles a few of the total layer. If the class with the expression is on the bottom of the class list it will be overwritten by the class with no expression value defined. My suggestion is that some how if the user has already built the style for the no expression layer, than the new layer should be placed above this layer. Just a thought.
