Feature request #2832

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

Added by Mathieu Pellerin - nIRV about 9 years ago. Updated over 7 years ago.

Status:Closed
Priority:Low
Assignee:Martin Dobias
Category:Symbology
Pull Request or Patch supplied:No Resolution:fixed
Easy fix?:No Copied to github as #:12892

Description

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.

rule_based_renderer.diff Magnifier (2.86 KB) Marco Hugentobler, 2010-08-11 12:22 AM

History

#1 Updated by Marco Hugentobler about 9 years ago

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?

#2 Updated by John Tull about 9 years ago

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.

#3 Updated by Mathieu Pellerin - nIRV almost 9 years ago

Any chance the devs can get this landed soon? Thanks

#4 Updated by Martin Dobias almost 9 years ago

I have partially applied the patch in - 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

#5 Updated by Mayeul Kauffmann almost 9 years ago

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 (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?

#6 Updated by Martin Dobias almost 9 years ago

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

#7 Updated by Mayeul Kauffmann almost 9 years ago

Replying to [comment:9 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: #3222

#8 Updated by John Tull over 8 years ago

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

#9 Updated by John Tull over 8 years ago

Replying to [comment:11 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

#10 Updated by Mayeul Kauffmann over 8 years ago

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

#11 Updated by Giovanni Manghi almost 8 years ago

  • Target version changed from Version 1.7.0 to Version 1.7.4

#12 Updated by Martin Dobias over 7 years ago

  • Pull Request or Patch supplied set to No
  • Status changed from Open to Closed
  • Target version changed from Version 1.7.4 to Version 2.0.0
  • Resolution set to fixed

This has been addressed already (maybe also in 1.7 ?). Closing the ticket.

Also available in: Atom PDF