Re: [Qgis-developer] Symbology api
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
Re: [Qgis-developer] Symbology api
Hi Martin, On 03/10/2014 21:10, Martin Dobias wrote: Hi Vincent On Fri, Oct 3, 2014 at 1:10 PM, Vincent Moravincent.m...@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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Symbology api
Interesting idea. At the moment the graduated renderer colour is also a discrete function of attributes. Changing to a continuous function (or having a continuous function alternative) would mean changing the legend interface somewhat. I've been thinking about how to better implement the Vector Field Renderer plugin (written before expression based renderering, uses a python renderer) and I'm thinking that it only needs a few more expression based properties in the symbology to be able to replace the python rendering (independent x,y scaling and offset of symbols, and an x,y offset or more simply just an affine transformation maybe). Also (if it is not already present) some functions for determining map scale in expressions. Cheers Chris From: Vincent Mora [vincent.m...@oslandia.com] Sent: 04 October 2014 00:10 To: qgis-dev Subject: [Qgis-developer] Symbology api 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 ? This message contains information, which may be in confidence and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or i...@linz.govt.nz) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Symbology api
Hi Vincent On Fri, Oct 3, 2014 at 1:10 PM, Vincent Mora vincent.m...@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? If it is, how would it handle the case where symbols of individual classes are completely different? (not just varying in size/color) 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). Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
