<div><font face="arial, sans-serif"><div>Hi Marco, hi Mayeul and Kimaidou</div><div><br></div><div>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.</div>
<div>Now I found the SLD QGIS API methods [1] (saveSldStyle and loadSldStyle in QgsMapLayer and writeSld and loadSld in QgsVectorLayer) from Adrian Weber [2].</div></font><font face="arial, sans-serif"><div>And I would like to use QGIS as one of the reference GIS in this expertise/study.</div>
<div><br></div><div>Does anybody know about the status of these extensions?</div><div>Does anybody know Adrian Weber in order to intergrate the SIP files (in order to access the SLD methods in a Python plugin too)?</div><div>
<br></div></font><font face="arial, sans-serif"><div>Yours, Stefan</div></font><font face="arial, sans-serif"><div><br></div><div><div>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.</div>
</div><div><br></div><div><div>[1] <a href="http://www.webrian.ch/2012/04/native-sld-support-in-qgis.html">http://www.webrian.ch/2012/04/native-sld-support-in-qgis.html</a> </div></div><div>[2] <a href="http://hub.qgis.org/users/853" target="_blank">http://hub.qgis.org/users/853</a></div>
</font><font face="arial, sans-serif"><div><br></div><div style="color:rgb(136,136,136)"><br></div></font><div class="gmail_quote">2011/8/19 Mayeul Kauffmann <span dir="ltr"><<a href="mailto:mayeul.kauffmann@free.fr" target="_blank">mayeul.kauffmann@free.fr</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
Thanks for raising this! After months of use of symbol levels in<br>
rule-based rendering (SLinRBR), I found the implementation robust. I<br>
have several colleagues using regularly my OSM styles. Yesterday I<br>
deployed it on an intranet with the webclient, see:<br>
<a href="http://www.qgis.org/qgiswiki/images/f/fd/Test_qgis_webclient_osm.png" target="_blank">http://www.qgis.org/qgiswiki/images/f/fd/Test_qgis_webclient_osm.png</a><br>
<a href="http://www.qgis.org/wiki/QGIS_Server_Tutorial#Core_Features" target="_blank">http://www.qgis.org/wiki/QGIS_Server_Tutorial#Core_Features</a><br>
So I support applying the SLinRBR patch into the master branch.<br>
<br>
Still I agree the SLD logic is interesting as well and efforts in this<br>
direction are welcome. I still believe it is possible to somehow merge<br>
the two: my understanding is that few changes in SLinRBR are needed to<br>
make SLinRBR and SLD logic compatible (specifically: improvement of the<br>
ElseFilter in current SLinRBR).<br>
This is how we could simply define compatibility: a one-to-one<br>
relationship between a set of SLinRBR rules and SLD rules.<br>
A looser definition could be: given a set of SLinRBR rules, it is<br>
possible to find a set of SLD rules that will give the same results for<br>
every dataset (and vice versa).<br>
An even looser definition would say "... give almost identical results<br>
for almost all datasets". In fact, OGC recognizes that SLD rendering is<br>
implementation specific (hence same SLD rules may give different<br>
results):<br>
"Whether all features are applied to each rule in sequence or whether<br>
all suitable rules are applied to each feature in sequence is<br>
implementation-specific, although there may be subtle differences in the<br>
appearance of maps resulting from each of the approaches."<br>
(source: OGC 05-077r4, "Symbology Encoding Implementation<br>
Specification").<br>
<br>
Again from the OGC specification: "Note that the above is a description<br>
of the semantics of the ElseFilter and not a requirement that systems<br>
implement exactly the procedural method described; any semantically<br>
equivalent method will suffice." As the Spec. document recall, boolean<br>
algebra and set theory show that there are many different ways to<br>
express a given condition.<br>
<br>
It is possible to have very similar results with the following tools on<br>
complex OSM datasets:<br>
- QGIS (with SLinRBR)<br>
- Osmarender<br>
- Mapnik<br>
- Kosmos<br>
There has been discussion in 2008 about using SLD as a way to share<br>
rules between the last 3:<br>
<a href="http://web.archiveorange.com/archive/v/wQWIbLKKl2Drk3qgOFep" target="_blank">http://web.archiveorange.com/archive/v/wQWIbLKKl2Drk3qgOFep</a><br>
I do not know the output today but this seems to confirm my feeling that<br>
the different logics are somehow compatible.<br>
If this is true, all the rest is related to the user interface and the<br>
implementation.<br>
<br>
Hope this helps!<br>
<br>
All the best,<br>
Mayeul<br>
<br>
<br>
Le jeudi 18 août 2011 à 08:45 +0200, Marco Hugentobler a écrit :<br>
<div><div>> Hi all<br>
><br>
> After several months, I'd like to open the discussion again and suggest to<br>
> merge Mayeuls patch into the master branch as well (currently only in 1.7, see<br>
> also <a href="https://github.com/qgis/Quantum-GIS/pull/26" target="_blank">https://github.com/qgis/Quantum-GIS/pull/26</a>)<br>
><br>
> While a rule based renderer following SLD logic would be great in the future<br>
> , the symbol level patch exists and can be very usefull until a redesigned<br>
> renderer is there.<br>
><br>
> Any objections?<br>
><br>
> Regards,<br>
> Marco<br>
><br>
><br>
><br>
><br>
> Am Dienstag, 8. März 2011, 09.03:50 schrieb kimaidou:<br>
> > Hi devs,<br>
> ><br>
> > I agree with Marco and Martin : following the SLD logic would be great. It<br>
> > would help a lot people used to SLD to understand the logic of Qgis<br>
> > styling. I also think we should keep the logic easy to understand while<br>
> > not loosing too much power.<br>
> ><br>
> > Talking about SLD import/export... Using Qgis as a wysiwyg tool to create<br>
> > and share great styles would be awesome. But we must keep in mind SLD<br>
> > specifications do not cover all the features we could imagine/have in Qgis.<br>
> > If we go toward the SLD way (+1 for me), and be able to export/import<br>
> > from/to SLD we would need to have kind of a "table of features" to compare<br>
> > 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<br>
> > lines. As described in the SLD Cookbook (see [1] and [2]) we would need to<br>
> > 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<br>
> > Weber. He told me he will now focus on supporting new symbology. I am<br>
> > trying to help him and will when I find time. While reading this post, I<br>
> > was thinking it would help a lot if Qgis logic followed the SLD one :)<br>
> ><br>
> > [1]<br>
> > <a href="http://docs.geoserver.org/stable/en/user/styling/sld-cookbook/lines.html#la" target="_blank">http://docs.geoserver.org/stable/en/user/styling/sld-cookbook/lines.html#la</a><br>
> > bel-following-line [2]<br>
> > <a href="http://docs.geoserver.org/stable/en/user/_downloads/line_labelfollowingline" target="_blank">http://docs.geoserver.org/stable/en/user/_downloads/line_labelfollowingline</a><br>
> > .sld<br>
> ><br>
> > Kimaidou<br>
> ><br>
> > 2011/3/7 Marco Hugentobler <<a href="mailto:marco.hugentobler@sourcepole.ch" target="_blank">marco.hugentobler@sourcepole.ch</a>><br>
> ><br>
> > > Hi Martin<br>
> > ><br>
> > > I'm also in favour of a rule based renderer that follows closely the<br>
> > > 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,<br>
> > > etc.<br>
> > ><br>
> > > And yes, with a nice GUI, it will be as user-friendly as the other parts<br>
> > > of the symbology.<br>
> > ><br>
> > ><br>
> > > Regards,<br>
> > > Marco<br>
> > ><br>
> > > Am Samstag, 5. März 2011, 20.12:04 schrieb Martin Dobias:<br>
> > > > Hi Mayeul<br>
> > > ><br>
> > > > On Wed, Mar 2, 2011 at 6:01 PM, <<a href="mailto:mayeul.kauffmann@free.fr" target="_blank">mayeul.kauffmann@free.fr</a>> wrote:<br>
> > > > > Hi,<br>
> > > > ><br>
> > > > > (This follows this thread: Branch status for merge and release<br>
> > > > > timeline 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<br>
> > > > > lines of code).<br>
> > > > ><br>
> > > > > I made improvements to this code and my patch was somehow applied,<br>
> > ><br>
> > > again<br>
> > ><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<br>
> > ><br>
> > > than<br>
> > ><br>
> > > > > an incomplete one for symbol levels. But since the rule-based<br>
> > > > > rendering is currently in an incomplete state, why put it in the<br>
> > > > > renderer stable release anyway? I believe symbol levels make a huge<br>
> > > > > difference in rendering lines. With them, I have a rendering similar<br>
> > > > > to Osmarender or Mapnik in QGIS which gives QGIS a definitive bonus<br>
> > > > > with respect to many other desktop or server GIS. (for a rendering<br>
> > > > > 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>
> > > > ><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<br>
> > ><br>
> > > you<br>
> > ><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<br>
> > ><br>
> > > symbolizers<br>
> > ><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<br>
> > > > filter - 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>
> > > ><br>
> > > > - Line symbolizer1<br>
> > > > - Line symbolizer2<br>
> > > ><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>
> > > ><br>
> > > > - Line symbolizer1<br>
> > > ><br>
> > > > Style2<br>
> > > > - Rule2<br>
> > > ><br>
> > > > - Line symbolizer2<br>
> > > ><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<br>
> > ><br>
> > > right<br>
> > ><br>
> > > > now. - it could solve various small issues with the GUI that pop up<br>
> > > > when one thinks about ordering of the rules (which makes sense if not<br>
> > > > using symbol levels, but unnecessary when symbol levels are turned on)<br>
> > > > and<br>
> > ><br>
> > > other<br>
> > ><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" target="_blank">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>
> > > 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" target="_blank">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>
> > > _______________________________________________<br>
> > > Qgis-developer mailing list<br>
> > > <a href="mailto:Qgis-developer@lists.osgeo.org" target="_blank">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>
<br>
<br>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org" target="_blank">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></div>