[Qgis-developer] Rule-based renderer updates

[mayeul.kauffmann at free.fr]

Hi Martin,

I've made some tests playing with a few hundred styles, comparing QGIS 1.7.1 and 1.9.0.
Overall, I find your commit very good, thanks a lot!
Still there are a few regressions IMHO. Discussion below.

> Rules now form a hierarchical structure: any rule can contain
> further "child" rules. When rendering, child rules are applied only
> when their parent rule matches. This allows users to build a logical
> trees of rules instead of keeping all rules in a flat list with
> complex filters.
Well, they already did, by using the "refine" button. Still, the new implementation is MUCH better as you can define a parent rule, many children, then change only one parent (before, you had to modify each single rule).


> The options "use only first rule" and "use symbol levels" have been
> removed: now all the matching rules and applied and at the same time
> the rendering order is given by the symbol levels.

In my opinion this is the major regression. With 1.7 it was possible to have some if/else logic, and the priority made it somehow work like SLD & Mapnik:
> because in SLD and Mapnik the order of rules matters
The beauty of the new hierarchical grouping is to help having simpler rules creation and modification. But removing "use only first rule" requires to put back "AND NOT (previous_rule)" criteria to achieve this. This make some use cases more complex and is more computer intensive (the user could put frequent rules on the top to speed up things: subsequent rules are ignored).

>GUI: rules are shown as a tree. They can be organized easily
> with drag and drop 
That's GREAT! Still, apparently the first child rule of a rule need to be created with the "refine current rules" button before being able to drag and drip children. If you have 5 exiting rules that you want to group under a new parent, you create the parent, create a first child, drag and drop the 5 children, then delete the first child.
(Edit: Still sometimes it works... when parent filter is empty?)

> symbol levels dialog for other renderers is now accessible from a
> menu from their "advanced" button
That's one click more for some renderers. It's not consistent across renderers: "Rendering order..." is directly accessible in Rule Based Renderer;
"Symbol levels" is no longer directly accessible. I would suggest to use always "Symbol levels". "Rendering order..." is technically correct but users may confuse it with the rule order, while "symbol levels" does not have this problem. 

=========================================
Summary and other notes:

(+)
1- Truly Hierarchical rules
2- Symbol levels even with several matching rules
3- The ability to change the colour, transparency, output unit and size of several symbols at one time (not
4- Inline editing
5- Drag and drop

(=)
-The "Refine a rule to categories/ranges" windows has an Advanced>Symbol levels widget. Why not...
-Legend does not reflect hierarchy

(-)
1) The priority system and "use only first rule" option disappeared.
2) The ability to display rules in 3 different ways (a flat way, by grouping them by filter or by scale) has disappeared. Now the GUI is similar to previous grouping by filter.
3) The ability to order the display of the rules by clicking on the column title ( label, rule, scale...) disappeared. This was handy!
4) Impossible to drag a rule A to a rule B to have A be a child of B if B has no child yet. 
5) Confusing "Rendering order..."/"Symbol levels"
6) Slightly confusing: direct editing of transparency in list allow e.g. "0,5" which corresponds to "50%" in the slider version of the symbol properties (by the way the latter would benefit from an edit box).


=========================================
Suggested priority future improvements IMHO:
- Reimplement the (-) above as they are regressions IMO:
 1) some optional "use only first rule" and "else" behaviour is needed
 2) is needed specially for scale. Scale ordering (with 3. ) will make 2) less needed.
 3) is more needed than filtering of rules and that 2)
 4) minor (but might confuse users)
 5) minor but easy to fix

 
- Clone rules

- Implement Z-index based on one attribute. Suggested implementation: User says which field has the z index. Lowest z index get rendered below for all rules (using their symbol levels), then next z index, etc. up to highest z-index. Cf. below:
> For example, when drawing a map of roads with nicely
> rendered road outlines and varying Z-levels (bridges / tunnels)
Z-levels is often stored in one single attribute and is not always related to the other attributes.
If you take the main 50 linear feature types, any of them may have values between -5 and +5 in OpenStreetMap, values with -2 and +2 are very common (around 80000 features) and +/- 3 are still frequent (14000). http://taginfo.openstreetmap.org/keys/?key=layer#values
Hence currently you need around 350 rules for 50 linear feature types and 7 layers. And this without being able to do this: http://osm.org/go/Tt5bBYZU5-
(Note that rivers may go below a canal, etc., see: http://wiki.openstreetmap.org/wiki/Key:layer ).

My own experience with complex OSM data would say that the Z-index is the most needed now, and the item 1) is close afterwards along with item 3).
It's more cumbersome to search workarounds without the proper support for Z-index than without the other needed features.
(With my new osm2postgresql script and the Z-index features, it would be possible to out-best Osmarender/mapnik for on the fly OSM map rendering with planet.osm!)

=========================================
About your questions:
> I have some doubts regarding GUI, e.g.:
> expand all rules when GUI is opened?
I would prefer not when I have many rules, and yes when I just have a few. Best would probably be to save the state, as well as the ordering (by clicking column header) if this is implemented.

> delete parent rule's symbol when refining it?
Please don't!
> or completely forbid rules to contain a symbol if they have children?
Please don't! It's good the way it is.

 > checkable rules?
Why not, could be handy sometimes, especially for testing. Still I would consider it low priority because, when needing this often, users would prefer to create a real layer. I sometimes add "0=1 AND ( original_filter )" to de-activate a rule, and maybe the need to use this hack is a smaller nuisance than having many check boxes that you almost never use.
This would be however most needed with feature 1) ("use only first rule" and "else" behaviour).


> better item delegates for inline editing - e.g.
> filter editor with "..." button to open query builder
Would just save 1 click, so not needed I think (and may even be a nuisance).

Hope this helps.
Thanks again for these improvements!

Mayeul