On Fri, Jan 27, 2012 at 5:59 PM, <[email protected]> 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 _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
