[Qgis-developer] Symbology api

[Vincent Mora]

Hi Martin,

On 03/10/2014 21:10, Martin Dobias wrote:
> Hi Vincent
>
> On Fri, Oct 3, 2014 at 1:10 PM, Vincent Mora<vincent.mora at oslandia.com>  wrote:
>> We can use expressions to make the single symbol layer behave:
>> - graduated : properties are continuous functions of attributes,
>> - categorized or rule based : properties are discrete function of attributes
>>
>> The user interfaces for categorized, graduated, rule-based could remain the
>> same, it's just that it would generate the expressions for the single symbol
>> instead of configuring as specific class. Several categories could be
>> defined to affect various parameters (color and size are the first use
>> case).
>>
>> Can you tell me if the idea is sound ?
> If I understand correctly, you propose to use single symbol renderer
> with expressions (for color and for size) in places where we currently
> use graduated/categorized renderers. Is that correct?
Yes, it is correct. Although the marker, which can be composed of 
several simple symbols, seems to be a better base.

> If it is, how
> would it handle the case where symbols of individual classes are
> completely different? (not just varying in size/color)
A discrete function can handle the shape (it is already a parameter that 
can be defined by an expression). A little complexity comes with 
composed symbols (markers): in a given layer, different markers (from 
different classes) may be composed of a different number of symbols, but 
if we handle the 'null' case for the shape, then the number of symbols 
for a marker is only a max, and markers with less symbols will be 
handled just fine.
> It would be also good to check the impact on the rendering performance
> - maybe if more than just few classes are used, the evaluation with
> expressions could slow things down significantly. (the expression
> engine could enjoy some performance improvements).
The performance issue is definitely a concern.

I can think of some strategies to avoid a systematic evaluation of 
expressions for all features, but they imply some sort of 
classification, so I'm not sure it's a net gain on the code complexity 
front. So I would prefer keeping the approach simple (i.e. evaluate 
expressions for all features) and profile the code to see if expression 
evaluation can be improved.

I've made a preliminary test with graduated color (5 classes) one the 
one hand and continuous color defined by expression on the other hand. 
For 250k points, this gives roughly a factor 2 loss for rendering time 
(5sec for graduated, 10sec for expressions). I think this is rather 
encouraging.

Do you think this 2x loss is a killer for this approach (considering the 
improvements that can be made to expression evaluation) ?

> Regards
> Martin