[Qgis-developer] Rule-based renderer updates

[kimaidou]

Hi Martin,

Just a quick answer to thank you warmly for these improvements. I am
working on OpenStreetMap data to print maps, and I think these changes will
help me a lot.
I have to compile master branch to test it, but will try to do it quickly,
and then I would be able to report.

About your last questions, here are my first answers :
- cloning of rules

Very good idea,  It will help a lot

- filtering of rules in GUI - by label / filter expression / scale

not a priority for me, since the tree should improve user experience. And
you would have to dynamically change the tree, which could lead to weird
behaviours ? Such as showing only some child nodes

- "else" rule - will be used only if no other sibling rule matches

no comment here, since I do not use it often

- checkable rules?

This would be very helpfull to dynamically test the rules

- better item delegates for inline editing - e.g. filter editor with
"..." button to open query builder

no comment either

Another thing I find hard to play with in the current 1.7 versions is the
need to click again and again to change rule priority : click the rule,
then click the array (increase or decrease), then reclick the rule (which
location has changed), then reclick "increase", etc. I think.
This is why I think the drag and drop (and multi-selection) you implemented
would be very handy !

Thanks again

Michael


2012/1/24 Martin Dobias <wonder.sk at gmail.com>

> Hi all
>
> I have just merged improved rule-based renderer to master branch.
> There are various changes in both backend and GUI:
>
> * 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.
>
> * 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.
>
> * GUI: rules are shown as a tree. They can be organized easily with
> drag and drop (multiple selection is supported, too). Let me emphasize
> again that the tree of rules does not say anything about the rendering
> order (because in SLD and Mapnik the order of rules matters). The
> rendering order can be set by the button in bottom-right corner of the
> renderer widget - it triggers the same dialog as used for setting
> symbol levels.
>
> * GUI: inline editing of labels, filters and scale range is now
> possible - use F2 -or- click again a selected item to enter inline
> editing.
>
> * Rules may not contain a symbol: usually parent rules are not
> assigned a symbol because their child rules take care of rendering.
>
> * symbol levels dialog for other renderers is now accessible from a
> menu from their "advanced" button - to avoid some clutter,
> additionally renderers indicate whether they support symbol levels or
> not.
>
> Originally I wanted to design the rule-based renderer to follow SLD /
> Mapnik logic - the order of rules (and group of rules) determines the
> rendering order. However this is not very user friendly: the user has
> to prepare the rules in a way that is convenient to a software, not
> the user. For example, when drawing a map of roads with nicely
> rendered road outlines and varying Z-levels (bridges / tunnels), the
> user has to split the road symbols into multiple rules and move them
> away from each other - further editing of rules and symbols becomes
> complex. In our approach the user can keep the rules in a hierarchy
> that is most convenient and then define the rendering order
> independently. So there is not a 1:1 relation between QGIS rule-based
> rendering and SLD (or Mapnik) rules, however the import/export
> capabilities can be implemented without problems.
>
> Please test, I would like to hear your comments, suggestions and bug
> reports. I am especially interested to hear any notes related to
> usability - I have some doubts regarding GUI, e.g.:
> - expand all rules when GUI is opened?
> - delete parent rule's symbol when refining it? or completely forbid
> rules to contain a symbol if they have children?
>
> There are still some smaller things that might be added in future:
> - cloning of rules
> - filtering of rules in GUI - by label / filter expression / scale
> - "else" rule - will be used only if no other sibling rule matches
> - checkable rules?
> - better item delegates for inline editing - e.g. filter editor with
> "..." button to open query builder
>
> Finally, I would like to thank Ville de Morges, Switzerland for
> sponsoring this work.
>
> Regards
> Martin
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/qgis-developer/attachments/20120124/f4c5a6fd/attachment-0001.html