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

Fri Apr 12 11:53:54 PDT 2013

Hi Marco, hi Mayeul and Kimaidou

I'm preparing an expertise for a recommendation with national outreach
together with colleague Prof. Olivier Ertz, the main convener of OGC SLD/SE
1.2.
Now I found the SLD QGIS API methods [1] (saveSldStyle and loadSldStyle in
QgsMapLayer and writeSld and loadSld in QgsVectorLayer) from Adrian Weber
[2].
And I would like to use QGIS as one of the reference GIS in this
expertise/study.

Does anybody know about the status of these extensions?
Does anybody know Adrian Weber in order to intergrate the SIP files (in
order to access the SLD methods in a Python plugin too)?

Yours, Stefan

P.S. I hope this is the right place to discuss plugins. Last time when I
asked here about "Status of Plugins to load PostGIS Raster and MBTiles
directly?" I did'nt get any reaction from neither the community nor from
the PostGIS Raster plugin author Maurício.

[1] http://www.webrian.ch/2012/04/native-sld-support-in-qgis.html
[2] http://hub.qgis.org/users/853

2011/8/19 Mayeul Kauffmann <mayeul.kauffmann at free.fr>

> 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
> >
> >
>
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20130412/ec0114d8/attachment-0001.html>