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

Tue Mar 8 03:03:50 EST 2011

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#label-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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/qgis-developer/attachments/20110308/72518701/attachment.html