Hi, On top of the patch mentioned below, I made a patch implementing most of wonder's suggestion made at http://trac.osgeo.org/qgis/ticket/2832#comment:9 , namely "switching first rule/all rules, enabling symbol levels". I tested it during one week on r15538 and release it against r15676. This gives new rendering possibilities with the rule-based renderer, including easy and beautiful on the fly rule-based rendering of OSM maps, with results similar to mapnik and osmarender. Mayeul
Le lundi 21 mars 2011 à 23:06 +0100, Mayeul Kauffmann a écrit : > Hi, > Tim wrote: > > Mayeul we will apply this after we branch for release (probably around > > 1 april). > Great! > In the meantime, to test the compatibility of the symbol levels patch > with commits made since r15217, I just proposed a patch against r15538 > adding symbol levels in rule-based renderer (on top of r15217). It is a > minimalist patch which adds a quick fix for symbol levels and a > "Priority column" (instead of "ID" in previous patch) which is necessary > to know what is the, er... priority of rules when symbol levels are used > (since only first matched rule will be used). > It's there: http://trac.osgeo.org/qgis/ticket/3222 > patch_on_r15538-rbr_with_symbol_levels.diff > > I'm testing it and I'll put on trac any issue I might find. > Regards, > Mayeul > > Le samedi 19 mars 2011 à 09:40 +0200, Tim Sutton a écrit : > > Hi > > > > On Mon, Mar 14, 2011 at 10:22 PM, Mayeul Kauffmann > > <mayeul.kauffm...@free.fr> wrote: > > > Hi all > > > As Tim suggested to bring a patch to a developer's attention, I recall > > > here what he suggested (and Marco's positive comment): "to apply [my] > > > patch to the release branch and keep trunk untouched." > > > (In fact: it's Marco's patch proposed 7 months ago, see > > > http://trac.osgeo.org/qgis/ticket/2832#comment:3 ) > > > > > > > Mayeul we will apply this after we branch for release (probably around > > 1 april). Please remind me if you see the branch notice go out and you > > havent seen your patch applied. > > > > Regards > > > > Tim > > > > > > > This does not prevent us to work towards SLD in the long term. Still, > > > for now, all NG renderers (Single symbol, categorized, graduated) have a > > > working "Symbol level" button, except the rule-based renderer; the patch > > > will give similar behaviour on all renderers. > > > It "kills" me to write this, but if those few lines of the patch are not > > > applied, IMHO it is better to remove the "Symbol levels" button from the > > > rule-based renderer (because users will try to use it otherwise). > > > > > > Mayeul > > > > > > On Friday 04 March 2011 at 16:33 +0100, Marco Hugentobler wrote: > > >> > we could > > >> > apply your patch to the release branch and keep trunk untouched for > > >> > Martin to implement it in his preferred way. Martin, Marco that sound > > >> > ok for you? > > >> > > >> +1 > > >> > > >> Marco > > >> > > >> Am Freitag, 4. März 2011, um 05.42:09 schrieb Tim Sutton: > > >> > Hi Mayeul > > >> > > > >> > On Wed, Mar 2, 2011 at 7: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. > > >> > > > >> > Acknowledged thanks. > > >> > > > >> > > 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. > > >> > > > >> > Ok I had a read through the ticket. Martin is the maintainer of this > > >> > code so while I share your desire for symbol levels in rule based > > >> > renderer, I think we should give Martin the space to implement the > > >> > solution in his way if he has a better approach. I know Martin has a > > >> > lot of other things on his plate so lets give him some time. If coming > > >> > up to the release we need to apply a band aid fix (that doesnt break > > >> > any compatibility) to get 1.7 out with symbol level support, we could > > >> > apply your patch to the release branch and keep trunk untouched for > > >> > Martin to implement it in his preferred way. Martin, Marco that sound > > >> > ok for you? > > >> > > > >> > > (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 ) > > >> > > > >> > Very nice - I also have someone working on building rendering rules > > >> > for OSM here at Linfiniti and have been reading your notes and the > > >> > discussions on OSM symbology here on this list with interest. > > >> > > > >> > > 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) > > >> > > > > >> > > With a few lines take from any of the two patches proposed by > > >> > > mhugent and > > >> > > myself, we can have either: -symbol levels OFF and apply all rules > > >> > > -symbol levels ON and apply first matching rule > > >> > > > > >> > > With the current version (since r15217) we only have: > > >> > > -symbol levels OFF and apply all rules > > >> > > > >> > Yup those all sound useful - the idea being that you could create a > > >> > sequence of symbol layers based on rules offers powerful > > >> > possibilities. By the way did you figure out the correct syntax for > > >> > the modulus operator? I was trying to make a simple rule to make every > > >> > contour % 100m a bit thicker. Eventually I settled for contour in > > >> > (100,200,300....) which is ugly but worked... > > >> > > > >> > > Adding the extra capability provided in the two proposed patches > > >> > > does not > > >> > > prevent working later on having the missing two combinations: -symbol > > >> > > levels ON and apply all rules > > >> > > -symbol levels OFF and apply first matching rule > > >> > > > > >> > > What do you think? > > >> > > > >> > Yes personally I would like to see these options too. > > >> > > > >> > Best regards > > >> > > > >> > Tim > > >> > > > >> > > Regards, > > >> > > Mayeul > > >> > > > > >> > > ----- Mail Original ----- > > >> > > De: "Tim Sutton" <li...@linfiniti.com> > > >> > > À: "Mayeul Kauffmann" <mayeul.kauffm...@free.fr> > > >> > > Cc: "qgis-developer" <qgis-developer@lists.osgeo.org> > > >> > > Envoyé: Mardi 1 Mars 2011 21h44:05 GMT +01:00 Amsterdam / Berlin / > > >> > > Berne > > >> > > / Rome / Stockholm / Vienne Objet: Re: [Qgis-developer] Branch status > > >> > > for merge and release timeline proposal > > >> > > > > >> > > Hi Mayeul > > >> > > > > >> > > On Tue, Mar 1, 2011 at 3:15 PM, Mayeul Kauffmann > > >> > > > > >> > > <mayeul.kauffm...@free.fr> wrote: > > >> > >> Hi, > > >> > >> What about open tickets (bug fixes) that are not in branches? What > > >> > >> is > > >> > >> the timeline for them? > > >> > > > > >> > > We usually try to make sure there are no show stoppers when we > > >> > > release > > >> > > and remaining tickets get carried over to next release. I dont think > > >> > > we will ever be able to be in a situation where there are no open > > >> > > tickets left at the time of a release. > > >> > > > > >> > >> Now that New Symbology is the default, I guess > > >> > >> the following should be fixed before release, or am I missing > > >> > >> something? > > >> > >> > > >> > >> http://www.qgis.org/wiki/Switching_from_Old_to_New_Symbology_and_Labelin > > >> > >> g > > >> > > > > >> > > This is a great list / wiki page. The wait / when to release > > >> > > discussion is one that comes up periodically. I agree the items in > > >> > > your list should get attention - and no doubt more items will be > > >> > > raised when people are using symobology-ng by default. However these > > >> > > are not things I believe we should put a hold on the release for. If > > >> > > there is a general unhappiness about the situation, we can reinstate > > >> > > old symbology by default, but if not, lets put what we have out there > > >> > > for people to test and use, and march on towards 2.0. > > >> > > > > >> > > Regards > > >> > > > > >> > > Tim > > >> > > > > >> > >> Thanks for clarification! > > >> > >> Mayeul > > >> > >> > > >> > >> Le mardi 01 mars 2011 à 09:19 +0200, Tim Sutton a écrit : > > >> > >>> Hi all especially Martin and Pirmin and those actively working on > > >> > >>> new > > >> > >>> features > > >> > >>> > > >> > >>> I am just wondering how things are looking in terms of merging > > >> > >>> branches. Is a merge of threaded rendering + 3d globe on the cards > > >> > >>> for > > >> > >>> 1.7 assuming we have a code freeze of around March 15? I'd like to > > >> > >>> get > > >> > >>> 1.7 out before the hackfest (oops QGIS Meeting) so was thinking > > >> > >>> along > > >> > >>> the lines of : > > >> > >>> > > >> > >>> - code freeze 15 march > > >> > >>> - string freeze 21 march > > >> > >>> - release branching 1 April (yes I know its a cool date to release > > >> > >>> the > > >> > >>> code on :-) > > >> > >>> - release announcements 7 April (or when packages are available > > >> > >>> > > >> > >>> Are there any other major features people are working on that > > >> > >>> should > > >> > >>> be considered for the release timeline? If the threading + globe > > >> > >>> branches arent ready we can hold them over till 1.8, though it > > >> > >>> would > > >> > >>> be nice to get them out there now to keep all the slathering fans > > >> > >>> happy! > > >> > >>> > > >> > >>> Regards > > >> > >>> > > >> > >>> Tim > > >> > > > > >> > > -- > > >> > > Tim Sutton - QGIS Project Steering Committee Member (Release > > >> > > Manager) > > >> > > ============================================== > > >> > > Please do not email me off-list with technical > > >> > > support questions. Using the lists will gain > > >> > > more exposure for your issues and the knowledge > > >> > > surrounding your issue will be shared with all. > > >> > > > > >> > > Visit http://linfiniti.com to find out about: > > >> > > * QGIS programming and support services > > >> > > * Mapserver and PostGIS based hosting plans > > >> > > * FOSS Consulting Services > > >> > > Skype: timlinux > > >> > > Irc: timlinux on #qgis at freenode.net > > >> > > ============================================== > > >> > > >> > > >> -- > > >> 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 > > > > > > > > > > > > > > > > > > _______________________________________________ > 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