Opened 9 years ago

Last modified 9 years ago

#2832 new patch

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

Reported by: nirvn Owned by: wonder
Priority: major: does not work as expected Milestone: Version 1.7.0
Component: Symbology Version: Trunk
Keywords: Cc:
Must Fix for Release: No Platform: All
Platform Version: Awaiting user input: no

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.

Attachments (1)

rule_based_renderer.diff (2.9 KB) - added by mhugent 9 years ago.

Download all attachments as: .zip

Change History (14)

comment:1 Changed 9 years ago by lutra

Summary: rule-based renderer in symbology-ng fails to create layersrule-based renderer in symbology-ng should show rules in legend

comment:2 Changed 9 years ago by lutra

Owner: changed from nobody to wonder

Changed 9 years ago by mhugent

Attachment: rule_based_renderer.diff added

comment:3 Changed 9 years ago by mhugent

Type: enhancementpatch

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?

comment:4 Changed 9 years ago by 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.

comment:5 Changed 9 years ago by pcav

Milestone: Version 1.5.0Version 1.6.0

comment:6 Changed 9 years ago by nirvn

Any chance the devs can get this landed soon? Thanks

comment:7 Changed 9 years ago by 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

comment:8 Changed 9 years ago by 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?

comment:9 Changed 9 years ago by 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

comment:10 in reply to:  9 Changed 9 years ago by 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

comment:11 Changed 9 years ago by jctull

Milestone: Version 1.6.0Version 1.7.0

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

comment:12 in reply to:  11 Changed 9 years ago by 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

comment:13 Changed 9 years ago by 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

Note: See TracTickets for help on using tickets.