Hi Mayeul On Wed, Mar 2, 2011 at 6:01 PM, <mayeul.kauffm...@free.fr> wrote: > Hi, > > (This follows this thread: Branch status for merge and release timeline > proposal) > > Thanks for you answer Tim! I found the clarification useful and I appreciate > your sense of diplomacy. Here are a few thoughts. > > You wrote: "I agree the items in your list should get attention" > Just to make sure: most of the list (including links to my patch) was written > by users Neumann and Anitagraser. > > Among those fixes, we are several developers to believe that symbol levels in > rule-based rendering should be fixed, even with a temporary fix. A fix was > proposed in August 2010 by mhugent, see: > http://trac.osgeo.org/qgis/ticket/2832#comment:8 > His patch was applied except for the symbol level lines (about 10 lines of > code). > > I made improvements to this code and my patch was somehow applied, again > without the few symbol level lines of code. > http://trac.osgeo.org/qgis/ticket/3222#comment:15 > > I agree with Martin that it would be better to have a final solution than an > incomplete one for symbol levels. But since the rule-based rendering is > currently in an incomplete state, why put it in the renderer stable release > anyway? I believe symbol levels make a huge difference in rendering lines. > With them, I have a rendering similar to Osmarender or Mapnik in QGIS which > gives QGIS a definitive bonus with respect to many other desktop or server > GIS. > (for a rendering sample, see: > http://www.qgis.org/qgiswiki/images/f/fd/Lago_di_varese.png > which is compared with the OSM python plugin rendering here: > http://www.qgis.org/wiki/Using_OpenStreetMap_data ) > > Also, QGIS rule-based rendering is definitely more powerful than what you can > achieve on ArcGIS with queries and scale-related visibility, but ArcGIS users > who need symbol levels will not want QGIS's rule-based rendering. > > Ideally we should be able to have any combinations of the following: > -symbol levels ON or OFF > -apply first matching rule or apply all rules > (That's 4 combinations)
Short version of my brain dump below: I don't see a reason why we should support "apply first matching rule" because it would complicate the whole renderer with virtually no added value. And I am not yet sure what to do with the symbol levels issue. Interested readers please continue reading :-) Recently I have been thinking about the rule-based renderer a lot. The symbol levels is not the only thing that needs our attention. I think we all agree that ultimately we want to have some kind of compatibility with SLD and/or Mapnik which (to my knowledge) are quite compatible between each other. To summarize how they work: - each (vector) layer is assigned one or more styles - each style consists of a set of rules - each rule consists of a scale range, a filter and one or more symbolizers - a filter either matches all features or matches only features according a query. There's also "else" filter that matches only if all other rules do not match. When rendering a vector layer, styles are rendered in the order they appear in the input file. When rendering a style, for each feature each rule is checked and the symbolizers are applied if the rule matches. Now let's face what we have in our rule-based renderer: - a symbol layer is basically a symbolizer, a group of symbolizers makes a symbol - rule has the same meaning as in SLD/Mapnik, but there is no else filter - there is nothing like style in the sense of SLD/Mapnik So if you are drawing roads with outlines (our typical use case) in SLD/Mapnik you can do this: Style1 - Rule1 - Line symbolizer1 - Line symbolizer2 This will have the same effect as drawing without symbol levels enabled: the rule is rendered at once for each feature. To get "symbol levels" effect you need to do this: Style1 - Rule1 - Line symbolizer1 Style2 - Rule2 - Line symbolizer2 First style1 is rendered, then style2 is rendered, getting the expected effect. I wondered if we shouldn't introduce the notion "styles" in the meaning of SLD/Mapnik for the rule-based renderer. That would mean that the rules would be grouped into "styles", which would have several implications: - there would be no need to explicitly define symbol levels since the effect would be attained in the way described above. - this would also make possible to have just one painting algorithm that would be the same as in SLD/Mapnik, so probably it would be easier for users to understand how it works. Import/export would be simple, with no complicated transforms - we could also implement the "else" filter which is hard to achieve right now. - it could solve various small issues with the GUI that pop up when one thinks about ordering of the rules (which makes sense if not using symbol levels, but unnecessary when symbol levels are turned on) and other things like grouping. - the upside of the "styles" would be also that they would allow natural grouping of the rules, e.g. one style for roads at scale 1:10K - 1:50K, one style for POI, one style for rivers. The only downside I see here is that the symbols which are going to be use the effect of overpainting - like the roads with outlines - have to be split to bottom and top layer and applied in two different styles. But I think that is a relatively low price given the advantages. Finally, there are not that many symbols that would need this effect. Looking forward for your comments. Regards Martin _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer