Bug report #7960
diagrams - pie chart _ color mapping
Status: | Closed | ||
---|---|---|---|
Priority: | Normal | ||
Assignee: | Matthias Kuhn | ||
Category: | - | ||
Affected QGIS version: | master | Regression?: | No |
Operating System: | win and osx | Easy fix?: | No |
Pull Request or Patch supplied: | No | Resolution: | |
Crashes QGIS or corrupts data: | No | Copied to github as #: | 16819 |
Description
v 1.8.x and 1.9.x returns different results when doing simple pie charts out of 4 fields - sized by an explicite sum-field.
1.9. color assignment seems to be somehow arbitrary, while 1.8. returns correct values.
attached files demonstrate:
demo_LProp_v*.jpg ... layer properties settings of both versions
demo_v*.jpg ... results
in v1.9 with an "identfy_result"
this result demostrates that the val for tramway = 4 (all others = 0)
and color for tramway should be yellow - according to layer properties settings.
... after removing the last class "SBAHN" each symbol with just one of the remainig 3 field-values <> 0 changes its color to red -
which is the last entry in the "Assigned attributes" list (see demo_v1_9___3_classes.jpg)
it seems that there is a problem with features where
- just one value <> 0
- all values = 0
best regards robert
Associated revisions
[diagrams] Diagram fixes and UI improvements (Fix #7960) * Use correct color for pie chart if only one value is >0 * Show default text in scaling text box
History
#1 Updated by Angus Carr over 11 years ago
I have also experienced this bug. In my case, the size of the pie chart can be fixed or data driven. If the class is 100% of the total (e.g. 55,0,0,0,0), then the complete circle is colored with no radial lines, and the circle is colored the last color, not the class color.
I don't have access to a compiler to build QGIS right now, so I can only post a suggestion.
I looked through the source, and suspect the problem to be in this function:
http://qgis.org/api/qgspiediagram_8cpp_source.html#l00085
void QgsPieDiagram::renderDiagram(...)
00134 // if only 1 value is > 0, draw a circle 00135 if ( valCount == 1 ) 00136 { 00137 p->drawEllipse( baseX, baseY, w, h ); 00138 }
It seems like the circle is drawn multiple times (My guess) and the last one is the one that is visible.
In these lines, the list of values and the colors are put in a pair of lists:
00100 for ( ; catIt != s.categoryIndices.constEnd(); ++catIt ) 00101 { 00102 currentVal = att[*catIt].toDouble(); 00103 values.push_back( currentVal ); 00104 valSum += currentVal; 00105 if ( currentVal ) valCount++; 00106 }
There is an attempt to only keep the relevant figures, but a double 0 is not going to be equal to boolean False. I would add a check inside the inner loop where the ellipse is drawn - like the following - if there is only one value and the current value is less that 1/16th of a degree, then we can assume it is 0.
Starting on Line 00134:
// if only 1 value is > 0, draw a circle if ( valCount == 1 ) { if (currentAngle < 1) p->drawEllipse( baseX, baseY, w, h ); }
#2 Updated by Matthias Kuhn over 11 years ago
- Assignee set to Matthias Kuhn
#3 Updated by Matthias Kuhn over 11 years ago
- Status changed from Open to Closed
Fixed in changeset 8c840e99574ec3ce2cce45a0bc51bc87d88e3b8a.
#4 Updated by Matthias Kuhn over 11 years ago
Thank you for reporting this bug
@Angus Carr:
FYI
but a double 0 is not going to be equal to boolean False
It does actually equal
#5 Updated by Angus Carr over 11 years ago
Thanks for fixing it. I tested the nightly build (-302 in osgeo4w) and it works correctly.
Cheers,
Angus.