[Qgis-developer] Rule-based renderer updates

[Martin Dobias]

On Fri, Jan 27, 2012 at 5:59 PM,  <mayeul.kauffmann at free.fr> wrote:
> 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.

Hi Mayeul

thanks for your feedback.


>> 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).

The "use only first rule" was removed intentionally - it is better to
have just one rendering logic. I believe the "else" rule (once added)
will handle these cases just fine.


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

When you add a rule, it is either added at the same level as the
current rule or it is added to the root rule when there is no
selection. This behavior might be changed.


>> 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.

I consider "symbol levels" to be an advanced technique, therefore now
it is hidden under Advanced button to keep the GUI simple - too many
controls make the GUI less intuitive. I agree that the wording "sombol
levels" / "rendering order" may be confusing. Any native speakers who
would recommend using one over the other?


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

Legend widget is not made to handle hierarchies. Then there is also
legend in composer which works with just lists of symbols+labels. I
think it is reasonable to keep it as it is.


> (-)
> 1) The priority system and "use only first rule" option disappeared.

I have no plans to add it.

> 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.

I think it does not make sense anymore since everyone can arrange the
rules as necessary.

> 3) The ability to order the display of the rules by clicking on the column title ( label, rule, scale...) disappeared. This was handy!

That might appear again. The question is how to get back to
"unordered" state - the original ordering of the rules could get lost.

> 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.

Works for me.

> 5) Confusing "Rendering order..."/"Symbol levels"

Addressed above.

> - 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!)

I would suggest you to work this around with some custom scripting:
prepare the rules just for one or few z-levels and create a script
that would clone the rules and adjust the z-levels.

Regards
Martin