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.kauffm...@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.hugentob...@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.kauffm...@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@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.hugentob...@sourcepole.ch http://www.sourcepole.ch > > > > Technical Advisor QGIS Project Steering Committee > > > > _______________________________________________ > > > > Qgis-developer mailing list > > > > Qgis-developer@lists.osgeo.org > > > > http://lists.osgeo.org/mailman/listinfo/qgis-developer > > > > > > > _______________________________________________ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer >
_______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer