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

[mayeul.kauffmann at free.fr]

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)

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

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?
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_Labeling


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
==============================================