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 [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
