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

Thu Aug 18 02:45:53 EDT 2011

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

-- 
Dr. Marco Hugentobler
Sourcepole -  Linux & Open Source Solutions
Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland
marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee