rule-based renderer in symbology-ng should show rules in legend

[nirvn]

The rule-based rendered is a great addition to the new symbology system. It's an effective replacement for the old symbology's unique value renderer and can be extended beyond this.

There is however one important missing piece: rules need to show up as sub-items in the layers window (and therefore the legend), similarly to how the unique value renderer does.

[mhugent]

The following patch adds the legend items and adds symbol level support for the rule based renderer. However, symbol level rendering uses symbolForFeature(), which returns only one symbol and might not be appropriate if several rules apply. Still it is good enough in many situations to just return the first one (e.g. I'm using it for the mapserver benchmark). Or is there a better solution for it?

[jctull]

This patch worked well for me. Is there any hope of committing it to trunk? I tested it on OS X, both in the canvas legend and the in the composer.

[nirvn]

Any chance the devs can get this landed soon? Thanks

[wonder]

I have partially applied the patch in r14404 - show rules in legend. I've kept back the part regarding the symbol levels. The renderer should be able to apply multiple symbols if there are more valid rules. We need to give it some more thoughts on how to deal with the symbol levels.

Martin

[mayeulk]

Thank you wonder for putting it in the trunk! Here are some thoughts about how to deal with the symbol levels. IMHO, here are many examples where symbol levels are needed (and with the only workaround of having tens of layers). I cannot think of many examples where using several symbols (hence many matched rules) is absolutely required; even less examples where multiple matched rules AND symbol levels together are required ; for those examples (for instance: rule A and B), if we use the full patch rule_based_renderer.diff, there is the easy workaround of creating one rule C with (C <=> (A and B)) and putting it before A and B. Anyway, thinking of how to deal with combining symbol levels and multiple-matched rules will be easier if we can test rule based rendering with symbol levels. I am precisely working on this. I have just made my own build (based on 14481) by completely the patch in r14404 (including symbol levels). The first obvious needed feature would be to reorder the rules (change the priority order). Then, next to the "use symbol levels" check box, a warning should say that if symbol levels are activated, only the first matched rule will be applied. Then qgsrulebasedrendererv2.cpp should be modified to return "mCurrentSymbol" if symbol levels are not activated, and only the first matching rule if they are. Finally, symbol levels are saved in memory when closing the dialog box, but they are not saved to the file yet and this would need to be fixed. I'm working on rendering openstreetmap data in a customized way with filters based directly on the full-length OSM tags (but I cannot save my changes because of the above).

Should we have the changes suggested here, users will be able to choose between multiple matched rules and symbol levels. We will then have use cases to think about where to go next. What do you think?

[wonder]

I think we could make it configurable whether to use first matched rule or all matched rules. As you write, usually it's not necessary to apply several symbols for one feature (and you can always combine several symbol layers into one symbol). Having this behavior configurable would probably make the GUI simpler, as the "all rules" option would be disabled when symbol levels are being used.

In case you like this solution, I encourage you to create a patch for this functionality (reordering rules, switching first rule/all rules, enabling symbol levels).

Btw. I'm really interested in the openstreetmap renderer - we could use it for the OSM plugin, which now uses some hacks and custom style files to do the rendering and it's quite suboptimal.

Martin

[mayeulk]

Replying to wonder:

Btw. I'm really interested in the openstreetmap renderer - we could use it for the OSM plugin, which now uses some hacks and custom style files to do the rendering and it's quite suboptimal.

I've put a sample and some discussion here: ticket:3222

[jctull]

So... We still don't get the symbol levels showing in the composer in trunk. This is necessary for 1.7 release, IMO.

[jctull]

Replying to jctull:

So... We still don't get the symbol levels showing in the composer in trunk. This is necessary for 1.7 release, IMO.

Ok, this was a mistake. Instead, the rule-based symbols are not rendered when printing a composer to vector-based pdf format. Printing as raster does render the images. This is similar to this old bug with svg symbols:  http://trac.osgeo.org/qgis/ticket/2136

[mayeulk]

Hi jctull. About your comment:11, if I understand it correctly I believe you should have a look here:  http://trac.osgeo.org/qgis/ticket/3039#comment:4 and here:  http://trac.osgeo.org/qgis/ticket/3222#comment:15 Am I correct?

IMHO too I believe we need symbol levels for rule-based rendering as well.

Regards,

Mayeul