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
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
