QGIS » QGIS Application

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

which feature's color should the legend show?

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.

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.

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.

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.

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?

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.

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.

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.

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.

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).

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.

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.

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.

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...

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.

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.

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.

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.

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.