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

[Mayeul Kauffmann]

Hi,
Thanks all for sharing your thought on this. I find this discussion very
stimulating! Obviously each solution has some advantages and some
disadvantages. Here are my comments on Martin's answer.


##################################################################
Martin wrote: "I think we all agree that ultimately we want to have some
kind of
compatibility with SLD and/or Mapnik"

I can understand the benefits of technical convergence. Still I do not
fully agree. From my personal point of view, my aim is not to have a
software compatible with Mapnik (usable only by expert users?), my aim
is to let less advanced users easily define their graphic semiology, to
bridge the gap between map makers and map users (one reason is that OSM
data is so rich that you can do thousands of different custom maps).
That's why I started working on a set of QGIS styles for OSM: I found it
too difficult to rewrite quantumnik styles to fit my needs.

In more general terms, the QGIS philosophy is somewhat different from
Mapnik's. Mapnik is aimed for expert users who do not mind defining
thousands of parameters in XML code. If I understood the aims of QGIS
correctly, QGIS is also for intermediate users who need to understand
how to use the software in a reasonable amount of time, and will use it
predominantly with the mouse.
Current osm.xml mapnik stylesheet has more than 7000 lines and about 640
filters.
There are 35 filters for [highway] = 'secondary' alone; those 35 filters
are in 7 different part of the osm.xml stylesheet. I suspect that only
developers say that Mapnik and osm.xml files are easy to understand, use
and modify. But QGIS should be useful for non-developers as well.

Anyway, I believe that there is some compatibility between the symbol
levels approach and the mapnik approach. The symbol layers are just a
way to organize the superposition of layers (drawing order information
is gathered in one place); the mapnik way is linear (order in file
defines drawing order), but ultimately (during the actual rendering)
both are translated into operations that follow the same logic. Thus it
is possible to convert a stylesheet from one system to the other and
vice versa.

In terms of usability, I think symbol levels win:
-----------------------------------
With symbol levels, rules are defined this way:

rule 5: [highway] = 'secondary' or [highway] = 'secondary_link'
- draw black road outline as layer 1
- draw orange road line as layer 12

-----------------------------------
Mapnik works this way:
rule 17: [highway] = 'secondary' or [highway] = 'secondary_link'
- draw black road outline

rule 18: [...]
....

...
rule 313: [...]
...

...
rule 314: [highway] = 'secondary' or [highway] = 'secondary_link'
- draw orange road line 
...
-----------------------------------
There is a 1-to-n relationship between a feature and its symbol layers;
this idea is simple and translates directly into the symbol levels
system. Mapnik model is redundant: it has to repeat the rule for each
symbol layer. (To make a comparison: in a relational database, this
would be considered bad practice).

My final comment on "we want to have some kind of compatibility with SLD
and/or Mapnik": If Mapnik were the best ever possible renderer and if it
would be possible (and easy!) to achieve every imaginable graphical
effect with it, then maybe it would be more efficient to build a
quantumnik GUI to modify those stylesheets, and use the Mapnik renderer
as the default QGIS renderer, instead of building a new renderer (or
trying to modify the existing rule-based renderer to make it resemble
mapnik).

##################
"implement the "else" filter which is hard to achieve right now."

My understanding is that a different type (but still useful) of "else"
logic is achieved with "apply first matching rule".
I described a useful extension to the "apply first matching rule" logic
here:
http://trac.osgeo.org/qgis/ticket/3222#comment:16
(see bullet 1. in comment:16: For each rule, let the user say whether
(if this rule is matched) it should be the last rule tested)
####################

"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."

My experience with OSM data is quite different. I currently have about
70 rules for OSM linear features. More than half of them use 2 to 3
symbol levels with overpainting across features. So for me using
overpainting is the rule, not the exception, if you want to have a
beautiful rendering. (And it is not limited to road outlines).

####################
Here are some additional comments and questions.

1. While designing the architecture, we should work with real cases:
pick up a mapping problem (for instance a region with some OSM data) and
see what kind of graphical effect we need there. Then, see which
solutions allow to do this easily, and which do not. I followed this
approach for the proposal I made here:
http://trac.osgeo.org/qgis/ticket/3222#comment:16

2.There are two more things (related to this discussion) that I cannot
do currently with QGIS; ideally future improvements should solve those:

2a- simply use the OSM "Layer" tag (roads above other roads, etc.):
http://wiki.openstreetmap.org/wiki/Layer
To do this, currently 11 layers for each feature type are needed. One
solution could be to use symbol levels with a level modifier defined
based on a field.
The final symbol level could be defined as:
(Layer+5)*1000+[original symbol level]
(or simply Layer*1000+[original symbol level]   if we accept negative
levels or if the user modifies the Layer attribute first)
For instance, all roads with 'Layer'='-5' would be rendered with symbol
levels from 0 to 999.
All roads with 'Layer'='0' would be rendered with symbol levels from
5000 to 5999.

2b- define symbol levels across feature layers (for instance: most
linestrings should be ABOVE polygons, but some river linestrings should
be BELOW lake and riverbanks polygons, while still being above forest
polygons where relevant). Shapefiles cannot store heterogenous
geometries but postgis and spatialite can. Still if I'm correct QGIS
cannot take advantage of this yet.

3. An additional comment about the comparison with Mapnik:
The slippy-map mapnik rendering of OSM shows results at a limited number
of fixed scales. We want continuous zooming, so some of the problems we
are facing are not major problems for OSM Mapnik.

4. Probably it is possible to learn a lot from Mapnik to improve current
QGIS rendering. My question is: when shall this be available to the
users? Could that be for QGIS 1.7? Maybe not if there are no clear
answers on those questions so far. Still, today, with symbol levels, we
can have quite nice results.
I have uploaded a bigger example of rendering with symbol levels here:
http://wiki.openstreetmap.org/wiki/QGIS
(QGIS wiki is not responsive right now).
Although not perfect, I believe it shows that QGIS could give fair
enough rendering with symbol levels. Without symbol levels, we will
probably not give QGIS users the opportunity to create "professional
maps" using rule-based rendering, to use Martin words:

On 23 February 2011 at 13:54 +0100, Martin Dobias wrote:
> using 'symbol levels'  [...]
> produces a desirable effect if you are drawing roads with outlines as
> seen in professional maps. When you start thinking about rendering
> road maps with various types of crossings, the order becomes
> more complex.

Thanks for reading. Hope it helps!
Best regards,
Mayeul