[Qgis-developer] Re: symbol levels in rule-based rendering

Fri Mar 4 10:33:33 EST 2011

>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.kauffmann at 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" <lists at linfiniti.com>
> > À: "Mayeul Kauffmann" <mayeul.kauffmann at free.fr>
> > Cc: "qgis-developer" <qgis-developer at 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.kauffmann at 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.hugentobler at sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee