Hi Martin I'm also in favour of a rule based renderer that follows closely the logic of SLD. It would be a big plus for QGIS server too. Currently, it's SLD capabilities are built on top of the old renderer, so no overpainting, etc.
And yes, with a nice GUI, it will be as user-friendly as the other parts of the symbology. Regards, Marco Am Samstag, 5. März 2011, 20.12:04 schrieb Martin Dobias: > 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 -- Dr. Marco Hugentobler Sourcepole - Linux & Open Source Solutions Churerstr. 22, CH-8808 Pfäffikon SZ, Switzerland marco.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer