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

[Martin Dobias]

Hi Mayeul

On Sun, Mar 6, 2011 at 2:43 AM, Mayeul Kauffmann
<mayeul.kauffmann at free.fr> wrote:
> 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.

My aim is not to create a copy of Mapnik. I just say that the way how
rules are defined and ordered in SLD / Mapnik makes more sense to me
since there is no need to make difference whether symbol levels are
on/off or whether just first rule or all matching rules are applied.


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

But QGIS is armed with a GUI which can simplify the editing greatly
and help with things like making copies of rules, refining the rules
etc. Therefore IMHO it _is_ useful also for non-developers. I hope we
will agree that rule-based renderer is _not_ for average users. It is
for power users. I believe one needs to be a power user when willing
to create sets of rules for rendering - average users should be fine
with simple classification into categories and/or ranges.


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

There are cases where the conversion wouldn't be 1:1, e.g. else
filter. In SLD/Mapnik you can define one or more else filters for each
style. So having a style for roads, you define a rule with else filter
for all roads that are not drawn otherwise. Then the same with a style
for railroads. In current design of rule-based renderer there's no
other way of implementing else than having a filter "not (filter1 or
filter2 or ...)".


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

I am aware of this disadvantage. Still I think it makes sense. For me,
setting symbol levels is much more cryptic task, because one has to
explicitly assign the rendering pass number for each symbol layer,
while this is done automatically in SLD/Mapnik by the order of styles.

And then is the confusion with the order of rules: with symbol levels
on, the order of rules can be arbitrary, since the rendering order is
defined by symbol levels. (However if we were going to apply only
first matching rule, the order would be important, but still
irrelevant from the rendering order!) If symbol levels are disabled,
the order of rules is important. Isn't this confusing? :-)


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

I am not saying that SLD/Mapnik is a solution for everything/everyone.
But for advanced symbology it works well. And if we are doing
something very similar it makes sense to make it compatible. Using
Mapnik for rendering in QGIS is not very interesting - we have all the
required functionality in place. I am not that interested in Mapnik
anyway, the thing that matters to me is SLD support.


> ##################
> "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)

Umm... doesn't this complicate the things even more? Imagine that you
have several dozens of rules and something does not render properly
just because "this is last rule" checkbox would be in wrong state. I
do not like this at all. I want something simple. Simple to implement,
simple to understand and simple to use.

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

OK, but OSM data is an example of very complex data. It's hard to find
any more complex rendering task than to render all OSM data nicely in
any scale. I think GUI for the rule-based renderer could simplify the
symbolization of line features with overpainting: first you would
create the rules you need for roads and assign symbols with multiple
layers. Then you would tell the GUI to take the style containing roads
and split it so that rules would be duplicated in new style(s),
getting the desired effect.


> ####################
> 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

Yes this is welcome. It is however important not to consider only OSM
data as the only use case for rule-based renderer.


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

Ouch. I understand that this would help you a lot, but I am quite
reluctant to add such functionality. That would complicate the symbol
levels concept even more and just very few people would still
understand it.


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

Neither QGIS is able to work with heterogenous data in one layer. I
would suggest splitting the data into several layers.


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

I believe the mapnik rendering of osm works with any scale, though
just few fixed scales are used for better performance.


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

It will be available once the concept is clear (a consensus among the
developers is reached) and someone implements it. There's no timeline.


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

I have seen some samples from you, they all look great!

Regards
Martin