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

Fri Aug 19 16:49:38 EDT 2011

Hi,
Thanks for raising this! After months of use of symbol levels in
rule-based rendering (SLinRBR), I found the implementation robust. I
have several colleagues using regularly my OSM styles. Yesterday I
deployed it on an intranet with the webclient, see:
http://www.qgis.org/qgiswiki/images/f/fd/Test_qgis_webclient_osm.png
http://www.qgis.org/wiki/QGIS_Server_Tutorial#Core_Features
So I support applying the SLinRBR patch into the master branch.

Still I agree the SLD logic is interesting as well and efforts in this
direction are welcome. I still believe it is  possible to somehow merge
the two: my understanding is that few changes in SLinRBR are needed to
make SLinRBR and SLD logic compatible (specifically: improvement of the
ElseFilter in current SLinRBR).
This is how we could simply define compatibility: a one-to-one
relationship between a set of SLinRBR rules and SLD rules.
A looser definition could be: given a set of SLinRBR rules, it is
possible to find a set of SLD rules that will give the same results for
every dataset (and vice versa).
An even looser definition would say "... give almost identical results
for almost all datasets". In fact, OGC recognizes that SLD rendering is
implementation specific (hence same SLD rules may give different
results):
"Whether all features are applied to each rule in sequence or whether
all suitable rules are applied to each feature in sequence is
implementation-specific, although there may be subtle differences in the
appearance of maps resulting from each of the approaches."
(source: OGC 05-077r4, "Symbology Encoding Implementation
Specification").

Again from the OGC specification: "Note that the above is a description
of the semantics of the ElseFilter and not a requirement that systems
implement exactly the procedural method described; any semantically
equivalent method will suffice." As the Spec. document recall, boolean
algebra and set theory show that there are many different ways to
express a given condition.

It is possible to have very similar results with the following tools on
complex OSM datasets:
- QGIS (with SLinRBR)
- Osmarender
- Mapnik
- Kosmos
There has been discussion in 2008 about using SLD as a way to share
rules between the last 3:
http://web.archiveorange.com/archive/v/wQWIbLKKl2Drk3qgOFep
I do not know the output today but this seems to confirm my feeling that
the different logics are somehow compatible.
If this is true, all the rest is related to the user interface and the
implementation.

Hope this helps!

All the best,
Mayeul

Le jeudi 18 août 2011 à 08:45 +0200, Marco Hugentobler a écrit :
> Hi all
> 
> After several months, I'd like to open the discussion again and suggest to 
> merge Mayeuls patch into the master branch as well (currently only in 1.7, see 
> also https://github.com/qgis/Quantum-GIS/pull/26)
> 
> While a rule based renderer following SLD logic would be great in the future
> , the symbol level patch exists and can be very usefull until a redesigned 
> renderer is there.
> 
> Any objections?
> 
> Regards,
> Marco
> 
> 
> 
> 
> Am Dienstag, 8. März 2011, 09.03:50 schrieb kimaidou:
> > Hi devs,
> > 
> > I agree with Marco and Martin : following the SLD logic would be great. It
> > would help a lot people used to SLD to understand the logic of Qgis
> > styling. I also think we should keep the logic easy to understand while
> > not loosing too much power.
> > 
> > Talking about SLD import/export... Using Qgis as a wysiwyg tool to create
> > and share great styles would be awesome. But we must keep in mind SLD
> > specifications do not cover all the features we could imagine/have in Qgis.
> > If we go toward the SLD way (+1 for me), and be able to export/import
> > from/to SLD we would need to have kind of a "table of features" to compare
> > what can be done in Qgis and not trhough SLD (and the way around).
> > 
> > For example, the new labelling engine allows to write labels following
> > lines. As described in the SLD Cookbook (see [1] and [2]) we would need to
> > mimic geoserver "vendorOptions" tag when exporting from Qgis to SLD.
> > 
> > By the way, you must have seen the new SaveAsSLD plugin made by Adrian
> > Weber. He told me he will now focus on supporting new symbology. I am
> > trying to help him and will when I find time. While reading this post, I
> > was thinking it would help a lot if Qgis logic followed the SLD one :)
> > 
> > [1]
> > http://docs.geoserver.org/stable/en/user/styling/sld-cookbook/lines.html#la
> > bel-following-line [2]
> > http://docs.geoserver.org/stable/en/user/_downloads/line_labelfollowingline
> > .sld
> > 
> > Kimaidou
> > 
> > 2011/3/7 Marco Hugentobler <marco.hugentobler at sourcepole.ch>
> > 
> > > 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
> > > _______________________________________________
> > > Qgis-developer mailing list
> > > Qgis-developer at lists.osgeo.org
> > > http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> 