Feature request #11491

When using data defined colors the map legend shows always a black symbol

Added by Fabien Cerbelaud over 9 years ago. Updated almost 7 years ago.

Status:Open
Priority:Normal
Assignee:-
Category:Map Legend
Pull Request or Patch supplied:No Resolution:
Easy fix?:No Copied to github as #:19761

Description

Hi,
When I used a fields with color attribute to define colors in source of propertie definition for a thematic analysis the color is ok on the map but there is no color in legend. The color provides from a csv file joined with my shapefile. The problem still exist in map composer.

CLC_nomenclature_05.csv Magnifier - color_fields_in_csv (3.64 KB) Fabien Cerbelaud, 2014-10-24 05:04 AM

legend_color.jpg - result_screenshot (1.48 MB) Fabien Cerbelaud, 2014-10-24 05:04 AM

custom_legend.png (252 KB) Vincent Mora, 2015-01-30 07:41 AM


Related issues

Related to QGIS Application - Bug report #8118: No usable legend when data defined symbology is used Closed 2013-06-19
Related to QGIS Application - Feature request #10629: Display data-defined symbology in legend Closed 2014-06-18
Related to QGIS Application - Bug report #13491: All colors in Style tab looks the same Closed 2015-10-02
Duplicated by QGIS Application - Bug report #12267: Data-defined SVG symbol path doesn't work in legend and s... Closed 2015-02-25
Duplicated by QGIS Application - Bug report #14244: legend and styles random Closed 2016-02-08
Duplicated by QGIS Application - Bug report #15835: Colour assigned with variable not shown in legend Closed 2016-11-10

History

#1 Updated by Giovanni Manghi over 9 years ago

  • Subject changed from Legend on color in source of propertie definition to When using data defined colors the map legend shows always a black symbol
  • Operating System deleted (windows)
  • OS version deleted (7)
  • Affected QGIS version changed from 2.4.0 to master

#2 Updated by Giovanni Manghi over 9 years ago

confirmed also on master and other platforms, not sure if this would be an easy fix, but really hurts.

#3 Updated by Jürgen Fischer over 9 years ago

which feature's color should the legend show?

#4 Updated by Jürgen Fischer over 9 years ago

  • Status changed from Open to Feedback

#5 Updated by Giovanni Manghi over 9 years ago

  • Status changed from Feedback to Open

Jürgen Fischer wrote:

which feature's color should the legend show?

the same color that show in the canvas, if using a categorized symbology (the same applies for the border color, that can be controlled by table values too).

A user can even apply data defined color fill/border values using the "single symbol" symbology, in this case I think that there is no need to apply any specific color/symbol (but not solid black, imho).

#6 Updated by Jürgen Fischer over 9 years ago

  • Status changed from Open to Feedback

Giovanni Manghi wrote:

Jürgen Fischer wrote:

which feature's color should the legend show?

the same color that show in the canvas, if using a categorized symbology (the same applies for the border color, that can be controlled by table values too).

Isn't this just a special case where the category is defined by the same attribute that is also used to join the csv? Otherwise there is no direct connection between one category and one color. In the general case the category could have as many different colors as there are features in that category.

#7 Updated by Giovanni Manghi over 9 years ago

Isn't this just a special case where the category is defined by the same attribute that is also used to join the csv? Otherwise there is no direct connection between one category and one color. In the general case the category could have as many different colors as there are features in that category.

there is no direct connection, but we must assume that the user prepared his/her table in a way that there is only one color per category, as it is supposed to be when using this feature.

If not we may show the legend categories all solid black (or just the ones with more than 1 color, to make clear to the user that there is something wrong somewhere), but if the table is right I don't see why the legend should not look the right way.

#8 Updated by Fabien Cerbelaud over 9 years ago

In my example files I used Corine Land Cover data, these data have a code, this code correspond to category and color, so there is only one color for one category that's why I don't understand why all color are black in legend. If I have different color for one category this would be normal but it's not the case here.

#9 Updated by Jürgen Fischer over 9 years ago

Fabien Cerbelaud wrote:

In my example files I used Corine Land Cover data, these data have a code, this code correspond to category and color, so there is only one color for one category that's why I don't understand why all color are black in legend. If I have different color for one category this would be normal but it's not the case here.

If the color is fixed for a category anyway, you could just setup the symbol(s) for that category to that particular color instead of assigning it from an attribute. I think data-defined symbology is mainly meant for for datasets where that isn't possible, because the colors are not related to the category.

The legend is made from the symbology without looking at the features as it's neither required nor expected to find unique data-defined values per category and hence the color or any combination of other data-defined properties is left at the default. Otherwise it would be necessary to evaluate all features for the used data-defined properties or just use an arbitrary one. There's not even a requirement that each category actually has features. And unless all categories have unique data-defined values the legend could be still be considered wrong.

#10 Updated by Giovanni Manghi over 9 years ago

If the color is fixed for a category anyway, you could just setup the symbol(s) for that category to that particular color instead of assigning it from an attribute. I think data-defined symbology is mainly meant for for datasets where that isn't possible, because the colors are not related to the category.

I think that data defined colors are especially useful (and meant) to be used for those maps, with hundreds of categories that are shipped anyway with a column/table with code colors. For this maps styling the categories by hand is possible, but not very handy (considered that there are the colors code available and the right function to use them).

If doing the correct legend for data defined colors is not possible or too hard then a better solution than a legend full of black squares should be used.

#11 Updated by Jürgen Fischer over 9 years ago

Giovanni Manghi wrote:

If doing the correct legend for data defined colors is not possible or too hard then a better solution than a legend full of black squares should be used.

right, that brings us back to my first question: which (feature's) color should the legend show?

#12 Updated by Giovanni Manghi over 9 years ago

Jürgen Fischer wrote:

Giovanni Manghi wrote:

If doing the correct legend for data defined colors is not possible or too hard then a better solution than a legend full of black squares should be used.

right, that brings us back to my first question: which (feature's) color should the legend show?

well,
because for categorized symbology does not make any sense to show a number of classes all with the same color I would that in this case it should show always just one symbol (as the data defined colors where used by leaving the "single symbol" symbology). The I would say that this symbol should clearly show that it being used a data defined color for the fills and borders, maybe an ad hoc symbol?

not sure, better ask in the dev mailing list, there is a lot of people that will probably have a better idea than the above one.

#13 Updated by Fabien Cerbelaud over 9 years ago

Jürgen Fischer wrote:

Giovanni Manghi wrote:

If doing the correct legend for data defined colors is not possible or too hard then a better solution than a legend full of black squares should be used.

right, that brings us back to my first question: which (feature's) color should the legend show?

For answer this question, the color of map should be show in legend instead of black color. The rgba color code should be find in legend as it find in the map is in the last column of csv file.

#14 Updated by Jürgen Fischer over 9 years ago

Fabien Cerbelaud wrote:

For answer this question, the color of map should be show in legend instead of black color. The rgba color code should be find in legend as it find in the map is in the last column of csv file.

As already said above that would mean that we had to look at all features - and it still would not answer the question what to do when the outcome of that isn't a unique color (or one combination of all other data-definable properties that might be in use) or if there isn't even a feature in then category.

IOW we need something that works for all cases and not only for your special case where the category happens to have just one color.

#15 Updated by Anita Graser over 9 years ago

Since there can be so many different combinations of data-defined styles (fill and outline color, (out)line width, transparency, markers, ...) I think the only way to go is let the user decide which examples should be shown in the legend. Unfortunately, this will probably require a new dialog to design the data-defined style legend.

#16 Updated by Giovanni Manghi over 9 years ago

Anita Graser wrote:

Since there can be so many different combinations of data-defined styles (fill and outline color, (out)line width, transparency, markers, ...) I think the only way to go is let the user decide which examples should be shown in the legend. Unfortunately, this will probably require a new dialog to design the data-defined style legend.

the combinations are a lot, but I would suggest to try support at least the most simple and used case: the simple fill. This fill has just 3 data defined properties (fill color, border color and border width) and is all is needed to style that maps that are shipped with a color code (ex: Corinne Land Cover).

#17 Updated by Nyall Dawson over 9 years ago

I'm with Anita/Jürgen on this. There's going to be so many corner cases and exceptions that the only reliable way to handle this is to make the user pick values to display in the legend. There's no reason this new dialog couldn't have a button which automatically populates with unique values from a selected field.

#18 Updated by Mathieu Pellerin - nIRV over 9 years ago

What about simply using the non-data defined values (set via the UI) to draw the legend? That'd remove need to an additional dialog as the UI is all there already.

Alternatively, there could be a variable set indicating the current symbology is a legend item. But that'd inflate expression strings and make those slower overall.

#19 Updated by Anita Graser over 9 years ago

Mathieu Pellerin - nIRV wrote:

What about simply using the non-data defined values (set via the UI) to draw the legend?

Imho that does not help. We need data-defined examples in the legend. Displaying only the non-data defined values is not useful in most cases.

Alternatively, there could be a variable set indicating the current symbology is a legend item.

I'm afraid I don't understand what you are describing here.

#20 Updated by Nyall Dawson over 9 years ago

My ideal solution would be some kind of table which can auto-populate from user-specified range and step, or via unique column values.

So, I could specify:

rows = vary "population" field from 1000 to 10000 in +2000 increments
columns = unique values from "town_class" field

resulting in a 2d legend containing the cross product of these combinations. That would make legends like http://www.personal.psu.edu/cab38/GEOG321/14_multivariate02/census_bivar_choro.jpg or http://www.cartogrammar.com/images/vba/cervical_cancer.jpg possible.

Of course, that would require table-style legends. But there's no reason a 1d version of this would not work at the moment...

#21 Updated by Martin Dobias over 9 years ago

When I was redesigning the legend, I had in my mind the use case for legend for data-driven rendering. It goes along the lines of Anita's and Nyall's thoughts: let's have another tab in map layer properties where the user could setup the legend. Currently there is only one (default) way how legend for a layer is generated. But since 2.6 it is possible to implement a new (data-defined) legend generator that would override default legend items as suggested by renderers.

The GUI for data-defined legend could obviously try to auto-detect which properties use fields/expressions and suggest them for use. The user would then decide for example to show all possible fill styles based on real data. Such legend would be static since then (would not change unless explicitly regenerated with new data). This approach should work with various properties like different marker sizes or line widths. When several data-defined properties are combined - e.g. layer with cities, there could be first a list of different marker sizes (e.g. depending on population of a city), followed by a list of colors (e.g. dominant industry in the city). As Nyall mentions, there could be even support for table-style representation.

#22 Updated by Martin Dobias over 9 years ago

Just to add to my previous comment - Jürgen is right, ad-hoc solutions for one special case would be wrong. To me, this is not a bug, it is a missing feature.

#23 Updated by Vincent Mora about 9 years ago

Anita Graser wrote:

Mathieu Pellerin - nIRV wrote:

What about simply using the non-data defined values (set via the UI) to draw the legend?

Imho that does not help. We need data-defined examples in the legend. Displaying only the non-data defined values is not useful in most cases.

I have a use case: if the size or rotation of the symbol is data-defined, falling back on the non-data-defined values will avoid having no symbol at all in the legend, and the symbol would actually be useful.

So here is a PR to do that for marker and line symbol layers: https://github.com/qgis/QGIS/pull/1856

This use case is related to https://github.com/qgis/QGIS/pull/1853

I'm working on the legend generation for varying symbol size/rotation and combined varying size and color, so I'm well aware of the "missing feature", but in the meantime falling back on non-data-defined values would be nice.

#24 Updated by Vincent Mora about 9 years ago

  • Assignee set to Vincent Mora

#25 Updated by Vincent Mora about 9 years ago

A draft implementation along the lines of what Martin suggested: https://github.com/vmora/QGIS/tree/custom_legend . With a screenshot.

For the moment what this thing does is to list the different markers and allow the user to drag/drop them to create a custom legend.

I plan to work on the "Varying size" tab that will be displayed by default when a size expression is found.

#26 Updated by Giovanni Manghi almost 9 years ago

  • Tracker changed from Bug report to Feature request
  • Status changed from Feedback to Open

#27 Updated by Giovanni Manghi over 8 years ago

Please note that the situation in QGIS 2.10 and master is actually more confusing than it was up to 2.8.x and personally I think that this should go back to "bug":

up to 2.8 defining data defined (fill, for example) colors for features worked ok for map canvas, but legend shown all classes with a unique black symbol that was obviously wrong but somehow indicated to users that QGIS was not able to make a matching legend.

From 2.10 the legend is not all black anymore, but is not the one of the data defined colors, is another one, then one corresponding to the color ramp the user choose when creating classes. This is puzzling for users.

#28 Updated by Vincent Mora over 8 years ago

  • Assignee deleted (Vincent Mora)

#29 Updated by Nyall Dawson over 8 years ago

Please note that the situation in QGIS 2.10 and master is actually more confusing than it was up to 2.8.x and personally I think that this should go back to "bug":

Totally disagree. The 2.8 behavior meant it was impossible to have non black legends. The current behaviour allows you to customise the legend color, albeit in a not very obvious/user friendly way.

The ux could be improved, but the old behaviour is a big step back.

#30 Updated by Giovanni Manghi almost 7 years ago

  • Easy fix? set to No

Also available in: Atom PDF