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 -- Dr. Marco Hugentobler Sourcepole - Linux & Open Source Solutions Churerstrasse 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
