[Qgis-developer] Re: symbol levels in rule-based rendering (+level curves and operators in rules)

Fri Mar 4 04:46:43 EST 2011

Hi,
Thanks a lot for the answer, for your comments and for your proposal! If needed, I can try and work on XSLT to convert the styles between the different qml versions that might appear in this process.

Here is my answer with respect to your question on level curves:
"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..."
No, I use external modulo: First I wrote an R script which connects to the .dbf and adds a column with 4 different values values like:
|type |
-------
(NULL)
100
500
1000

Later on I did the same under postgresql.

Then in QGIS I defined four rules with different thickness, using scale-based filtering as well.
It would be great to know exactly what are the operators that can be used (what is the underlying language?). I found a few simple regexp that I use for instance for altitude range (to display mountain summit points depending on their altitude, even if the metric unit "m" is included - which is contrary to OSM standard).
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é: Vendredi 4 Mars 2011 05h42:09 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne
Objet: Re: symbol levels in rule-based rendering

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

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