Bug report #13033
Data defined settings at root Marker are copied to child Symbol Layer items
|Affected QGIS version:||master||Regression?:||No|
|Operating System:||Easy fix?:||No|
|Pull Request or Patch supplied:||Yes||Resolution:|
|Crashes QGIS or corrupts data:||No||Copied to github as #:||21108|
While looking at #12769 I found that there's a problem in Symbol's data-defined properties such as size and rotation for point layers, and width for line layers.
Indeed, these properties are simply copied to children SymbolLayers (more or less cleverly to maintain the proportion) but are not truely defined at the symbol's root level. This leads to unexpected results:
1. When you create a new symbol level on an existing marker with data-defined scale, that new symbol level won't scale
2. When you data-define the width of a marker symbol, it sets all of the child's layers width to be data-defined, making the "width" field useless
3. When you change a child symbol layer's width expression, the root data-defined width doesn't work anymore, so that you must start over if you want to make changes.
4. and so on...
There seem to be something a bit wrong in the current implementation. I think we miss actual properties at root level.
One shouldn't define a size or thickness at root level, but a scale, which would then apply to the children's value at rendering time, not changing the children's properties values in the UI. That would make edition of complex symbols much easier, and usage of data-defined properties much more reliable.
#1 Updated by Regis Haubourg over 6 years ago
- Assignee set to Nyall Dawson
Hi, putting Nyall in the list, he reviewed the code from Vincent Mora (I funded that feature).
In fact, old implementation was also confusing, using root level size as a multiplicator of size advanced field/expression. Each symbol did that too, and we had some bad interactions between expression and scaling method (area was still used when defining an expression).
The idea here was to define a more user friendly expression, on root level so that common users use that. There is an assistant now for size varying, that allows to generate a legend too. Much more consistent, and using same expression widgets as in labeling GUI.
Adding a new symbol should indeed keep scaling applied, you are right. Having only a scaling factor on root level does not seem quite clear to me. Other opinions ?
#2 Updated by Nyall Dawson over 6 years ago
I originally thought the same (in fact, I got part way through coding it this way) but hit an issue.
Imagine the following situation. I want a marker symbol with three circle layers, one must always be 1mm diameter and the other two should have data defined size. If the data defined size was set and stored at the root level then there's no way to avoid the 1mm fixed size marker layer also changing size.
Perhaps my ideal implementation would be:
- data defined size stored at the root level. Data defined size is still set to a physical size (eg mm), but like the current implementation the individual layers are scaled depending on their relative sizes to the size set at the root level.
- a "lock value" option could be added to the data defined button to prevent the root data defined size from applying
That said, I think the only thing missing from the current implementation is that adding new layers should automatically have the dd size applied
#3 Updated by Vincent Mora over 6 years ago
- Affected QGIS version changed from 2.8.2 to master
IMO if you are at the higher level, you want to control all thinks below, so I'm not fond of a lock below.
If you want to control the symbols sizes independently, you can still do that, we could add the assistant at the symbol level.
If I understand correctly, what you want is to be able to define the scale of several symbols, while defining the size differently for other symbols... sound like a list of makers to me.
For the ability to add new marker and change size, I think the solution is to reapply the marker DD expression (if its active) when something changes in the symbol list. Maybe also deactivating the corresponding DD buttons when a marker size, rotation or width is DD. I'm looking into that, but I can't find were to do it yet.