[Qgis-developer] Re: feature freeze: symbol levels in rule-based
rendering
Tim Sutton
lists at linfiniti.com
Sat Mar 19 03:40:13 EDT 2011
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
>
>
>
--
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
==============================================
More information about the Qgis-developer
mailing list