[Qgis-developer] Symbology api

[Leyan]

On 10/03/2014 07:10 PM, Vincent Mora wrote:
> Hi all,
>
> While thinking about the interface of categorized and graduated 
> symbology with varying size (instead of color) I had an idea to reduce 
> the code complexity in src/core/symbology-ng (~15% less code).
>
> Since it changes the symbology API, I'd like your input on that:
>
> At the moment we deal with categorized, graduated, rule-based and 
> single symbol with different classes.
>
> At the same time the single symbol allows to use expressions for all 
> symbol properties.
>
> 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 ?
>
> V.
>
>
>
> PS: (implementation detail)
>
> Data defined properties are treated as a special case in the symbology 
> classes.
>
> Since a constant is a valid expression, why not avoid this special 
> treatment and have properties being always expressions in the 
> symbology classes ?

Rule based renderer allows to have several symbols for the same element, 
which seems difficult to implement with expressions in a single symbol 
renderer (except if you combine them into layers on a single symbol? 
Sounds messy). It can be very useful to quickly see which elements have 
different properties: just create rules with colored dots and a 
different offset each time, all the relevant dots will appear near the 
element.

You also need to deal with symbol levels (advanced->symbol levels...). 
This is very useful for example for dense point layers, to ensure the 
points you want to focus on appear on top, or for road rendering when 
you do not want the road borders to mess up intersections.

If you want to combine all these renderers, why not use the rule-based 
renderer? It is the most powerful and can easily cover the others. I 
already coded a small converter between renderers, which can be used to 
convert single symbol, categorized and graduated renderers to rule-based 
renderer. Something similar could be used directly on user input in 
order to always save a rule-based renderer in the symbology.

This converter could be made much simpler if we get rid of the code 
dealing with "advanced->rotation field" and "advanced->size field" as 
they can be directly replaced by expressions. I think it would be a good 
first step before making more radical changes.

Leyan