[Qgis-developer] symbol levels in rule-based rendering

[Marco Hugentobler]

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.kauffmann at 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 at 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.hugentobler at sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee