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

[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