[Qgis-developer] Re: feature freeze: symbol levels in rule-based
rendering
Mayeul Kauffmann
mayeul.kauffmann at free.fr
Mon Mar 21 18:06:44 EDT 2011
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.kauffmann at 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.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
> >> _______________________________________________
> >> Qgis-developer mailing list
> >> Qgis-developer at lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
> >
> >
>
>
>
More information about the Qgis-developer
mailing list