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

Sun Mar 6 16:53:05 EST 2011

Hi again Martin,
Thanks for your notes. Below is a proposal for a compromise.
I see the long term advantages of converging to something compatible
with SLD and you gave good arguments in favor of this approach. Yet,
since I find a few advantages in the other approach, I cannot say that I
prefer one solution over the other in the long term (I will only be able
to tell which I prefer after testing intensively the SLD approach with a
GUI). So I've nothing against it as a long term direction, except for
one comment (with a proposed fix) and one question:
-----------------
Comment about:
"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."

Your suggestion is to create SLD rules in two steps (instead of one),
the second step being non-reversible. After the second step, there is no
preview anymore of the multiple layers of a given symbol.
Imagine you create a rule for a road (with outline), then split the
rule, then you are not satisfied with the result and you want to
fine-tune the symbol.
You would need to do the following:
1. open the style of the inner line
2. Click "change..."
3. Make the changes
4. Close the style of the inner line
5. Search for the style of the outline (corresponding filter for the
same road) and open it
6. Click "change..."
7. Make the changes
8. Close the style of the outline
9. Click apply.
10. Wait before the map is refreshed. Search for the result directly on
the map.
11. Start again from step one since the result is not what you want.
It would be very tedious to design multi layer symbols without the
symbol preview.
In the current symbol layer implementation: the following steps are
unnecessary: 4,5,6,8,9,10; and the steps 1 and 4 need to be done only
once even if you need ten trials.
So, if you have 2 layers for a line and you need 5 trials (that's quite
conservative), your proposal requires you to you make 33 mouse clicks
more than with the current implementation (5*5 + (5-1)*2). (Only if you
can do step 5 in one single click).

You could keep your proposal the way it is ("SLD view"), but have a
radio button to switch from the SLD view to another view which would be
similar to the current "No grouping" view (which in fact would be "group
by filter and scale"): for a given scale range, it would group all rules
that have a common filter; double-clicking on one row would allow to
open a window identical to the "Rule properties": you would then modify
all the layers in single window, and define the legend as well. The
changes will be saved in the different underlying rules (the ones
displayed in the "SLD view").
This way, the different views will reflect the different tasks, while
being consistent with the underlying SLD model. What do you think?

----------------
Question: I'm not sure about how SLD behaves.
There are two tasks that the user want to performs:
1. assign the desired symbology (all levels) to a given feature
2. assign the drawing order to all symbol parts
Both tasks are separated with the approach I suggested (symbol levels
with rules saying if rules later in the list should be tested). So a
rule near the bottom (a rarely matched rule then) can end up drawing
something *below* all the other layers. My understanding is that SLD
cannot do this (or might only if you put many AND NOT conditions in the
previous filters?).
Question is: Is it possible (and easy) to separate those two tasks with
the SLD approach?

I think this question is related to what you wrote:
"However if we were going to apply only
first matching rule, the order would be important, but still
irrelevant from the rendering order!"
That's an advantage if it means it separates tasks 1 and 2 mentioned
above.
---------------

This discussion is for long term plans as you said. In the short term,
if possible, Tim's proposal of committing the patch in the release
branch only would be great ;-) This would allow me to share my OSM
rendering and let users modify it.

You wrote:"I have seen some samples from you, they all look great!"
Thank you! I'm glad you like them.

All the best,
Mayeul

Le dimanche 06 mars 2011 à 11:55 +0100, Martin Dobias a écrit :
> 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