Hi devs,<br><br>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.<br>
<br>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).<br>
<br>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. <br>
<br>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 :)<br>
<br>[1] <a href="http://docs.geoserver.org/stable/en/user/styling/sld-cookbook/lines.html#label-following-line">http://docs.geoserver.org/stable/en/user/styling/sld-cookbook/lines.html#label-following-line</a><br>[2] <a href="http://docs.geoserver.org/stable/en/user/_downloads/line_labelfollowingline.sld">http://docs.geoserver.org/stable/en/user/_downloads/line_labelfollowingline.sld</a><br>
<br>Kimaidou<br><br><div class="gmail_quote">2011/3/7 Marco Hugentobler <span dir="ltr"><<a href="mailto:marco.hugentobler@sourcepole.ch">marco.hugentobler@sourcepole.ch</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Martin<br>
<br>
I'm also in favour of a rule based renderer that follows closely the logic of<br>
SLD. It would be a big plus for QGIS server too. Currently, it's SLD<br>
capabilities are built on top of the old renderer, so no overpainting, etc.<br>
<br>
And yes, with a nice GUI, it will be as user-friendly as the other parts of<br>
the symbology.<br>
<br>
<br>
Regards,<br>
Marco<br>
<br>
Am Samstag, 5. März 2011, 20.12:04 schrieb Martin Dobias:<br>
<div><div></div><div class="h5">> Hi Mayeul<br>
><br>
> On Wed, Mar 2, 2011 at 6:01 PM, <<a href="mailto:mayeul.kauffmann@free.fr">mayeul.kauffmann@free.fr</a>> wrote:<br>
> > Hi,<br>
> ><br>
> > (This follows this thread: Branch status for merge and release timeline<br>
> > proposal)<br>
> ><br>
> > Thanks for you answer Tim! I found the clarification useful and I<br>
> > appreciate your sense of diplomacy. Here are a few thoughts.<br>
> ><br>
> > You wrote: "I agree the items in your list should get attention"<br>
> > Just to make sure: most of the list (including links to my patch) was<br>
> > written by users Neumann and Anitagraser.<br>
> ><br>
> > Among those fixes, we are several developers to believe that symbol<br>
> > levels in rule-based rendering should be fixed, even with a temporary<br>
> > fix. A fix was proposed in August 2010 by mhugent, see:<br>
> > <a href="http://trac.osgeo.org/qgis/ticket/2832#comment:8" target="_blank">http://trac.osgeo.org/qgis/ticket/2832#comment:8</a><br>
> > His patch was applied except for the symbol level lines (about 10 lines<br>
> > of code).<br>
> ><br>
> > I made improvements to this code and my patch was somehow applied, again<br>
> > without the few symbol level lines of code.<br>
> > <a href="http://trac.osgeo.org/qgis/ticket/3222#comment:15" target="_blank">http://trac.osgeo.org/qgis/ticket/3222#comment:15</a><br>
> ><br>
> > I agree with Martin that it would be better to have a final solution than<br>
> > an incomplete one for symbol levels. But since the rule-based rendering<br>
> > is currently in an incomplete state, why put it in the renderer stable<br>
> > release anyway? I believe symbol levels make a huge difference in<br>
> > rendering lines. With them, I have a rendering similar to Osmarender or<br>
> > Mapnik in QGIS which gives QGIS a definitive bonus with respect to many<br>
> > other desktop or server GIS. (for a rendering sample, see:<br>
> > <a href="http://www.qgis.org/qgiswiki/images/f/fd/Lago_di_varese.png" target="_blank">http://www.qgis.org/qgiswiki/images/f/fd/Lago_di_varese.png</a><br>
> > which is compared with the OSM python plugin rendering here:<br>
> > <a href="http://www.qgis.org/wiki/Using_OpenStreetMap_data" target="_blank">http://www.qgis.org/wiki/Using_OpenStreetMap_data</a> )<br>
> ><br>
> > Also, QGIS rule-based rendering is definitely more powerful than what you<br>
> > can achieve on ArcGIS with queries and scale-related visibility, but<br>
> > ArcGIS users who need symbol levels will not want QGIS's rule-based<br>
> > rendering.<br>
> ><br>
> > Ideally we should be able to have any combinations of the following:<br>
> > -symbol levels ON or OFF<br>
> > -apply first matching rule or apply all rules<br>
> > (That's 4 combinations)<br>
><br>
> Short version of my brain dump below: I don't see a reason why we<br>
> should support "apply first matching rule" because it would complicate<br>
> the whole renderer with virtually no added value. And I am not yet<br>
> sure what to do with the symbol levels issue. Interested readers<br>
> please continue reading :-)<br>
><br>
> Recently I have been thinking about the rule-based renderer a lot. The<br>
> symbol levels is not the only thing that needs our attention. I think<br>
> we all agree that ultimately we want to have some kind of<br>
> compatibility with SLD and/or Mapnik which (to my knowledge) are quite<br>
> compatible between each other. To summarize how they work:<br>
> - each (vector) layer is assigned one or more styles<br>
> - each style consists of a set of rules<br>
> - each rule consists of a scale range, a filter and one or more symbolizers<br>
> - a filter either matches all features or matches only features<br>
> according a query. There's also "else" filter that matches only if all<br>
> other rules do not match.<br>
> When rendering a vector layer, styles are rendered in the order they<br>
> appear in the input file. When rendering a style, for each feature<br>
> each rule is checked and the symbolizers are applied if the rule<br>
> matches.<br>
><br>
> Now let's face what we have in our rule-based renderer:<br>
> - a symbol layer is basically a symbolizer, a group of symbolizers<br>
> makes a symbol<br>
> - rule has the same meaning as in SLD/Mapnik, but there is no else filter<br>
> - there is nothing like style in the sense of SLD/Mapnik<br>
><br>
> So if you are drawing roads with outlines (our typical use case) in<br>
> SLD/Mapnik you can do this:<br>
> Style1<br>
> - Rule1<br>
> - Line symbolizer1<br>
> - Line symbolizer2<br>
> This will have the same effect as drawing without symbol levels<br>
> enabled: the rule is rendered at once for each feature. To get "symbol<br>
> levels" effect you need to do this:<br>
> Style1<br>
> - Rule1<br>
> - Line symbolizer1<br>
> Style2<br>
> - Rule2<br>
> - Line symbolizer2<br>
> First style1 is rendered, then style2 is rendered, getting the expected<br>
> effect.<br>
><br>
> I wondered if we shouldn't introduce the notion "styles" in the<br>
> meaning of SLD/Mapnik for the rule-based renderer. That would mean<br>
> that the rules would be grouped into "styles", which would have<br>
> several implications:<br>
> - there would be no need to explicitly define symbol levels since the<br>
> effect would be attained in the way described above.<br>
> - this would also make possible to have just one painting algorithm<br>
> that would be the same as in SLD/Mapnik, so probably it would be<br>
> easier for users to understand how it works. Import/export would be<br>
> simple, with no complicated transforms<br>
> - we could also implement the "else" filter which is hard to achieve right<br>
> now. - it could solve various small issues with the GUI that pop up when<br>
> one thinks about ordering of the rules (which makes sense if not using<br>
> symbol levels, but unnecessary when symbol levels are turned on) and other<br>
> things like grouping.<br>
> - the upside of the "styles" would be also that they would allow<br>
> natural grouping of the rules, e.g. one style for roads at scale 1:10K<br>
> - 1:50K, one style for POI, one style for rivers.<br>
> The only downside I see here is that the symbols which are going to be<br>
> use the effect of overpainting - like the roads with outlines - have<br>
> to be split to bottom and top layer and applied in two different<br>
> styles. But I think that is a relatively low price given the<br>
> advantages. Finally, there are not that many symbols that would need<br>
> this effect.<br>
><br>
> Looking forward for your comments.<br>
><br>
> Regards<br>
> Martin<br>
> _______________________________________________<br>
> Qgis-developer mailing list<br>
> <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
<br>
<br>
</div></div><font color="#888888">--<br>
Dr. Marco Hugentobler<br>
Sourcepole - Linux & Open Source Solutions<br>
Churerstr. 22, CH-8808 Pfäffikon SZ, Switzerland<br>
<a href="mailto:marco.hugentobler@sourcepole.ch">marco.hugentobler@sourcepole.ch</a> <a href="http://www.sourcepole.ch" target="_blank">http://www.sourcepole.ch</a><br>
Technical Advisor QGIS Project Steering Committee<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</div></div></blockquote></div><br>