Bug report #13972

Categorize symbols uses wrong field after table join

Added by Spencer Gardner about 8 years ago. Updated almost 8 years ago.

Affected QGIS version:2.10.1 Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:fixed/implemented
Crashes QGIS or corrupts data:No Copied to github as #:21986


I have two layers: Layer A and Layer B. Layer A is a shapefile. Layer B is from an ESRI File Geodatabase. If I join Layer B to Layer A using a common field and then try to categorize their symbols based on the joined field, it uses the values from the first field in Layer B, rather than the field I have selected for categorization.

I am testing on 2.10.1, Windows 7 installed via OSGEO4W.

Steps to reproduce:
  1. Join Layer A to Layer B using a common field, keeping only the field to be categorized
  2. Open the styling in layer properties for Layer A
  3. Select categorized styling
  4. Select the column from the joined table
  5. Click the "Classify" button

What happens:
The correct number of classes are created, but the value that is used comes from the first column of the joined table, rather than coming from the joined field selected for categorization. The value appears to correspond to the first found instance of each class in the joined field.

What should happen:
The classes are populated according to the values in the joined field.

I know there have been issues with the FGDB driver in the past using the wrong field for a variety of operations. This may be related but I can't find the relevant bug report at the moment.

Related issues

Related to QGIS Application - Bug report #14118: regression: unchecking one sub-layer of a categorized sym... Closed 2016-01-15


#1 Updated by Sebastian Dietrich about 8 years ago

  • Status changed from Open to Feedback
  • Category changed from Attribute table to Symbology

Does this only occur when joining to an ESRI File Geodatabase?

There has been some work done in the joining code (see #14118) recently. Can you test using the nightly build?

Can you attach small sample files to reproduce the error?

#2 Updated by Spencer Gardner about 8 years ago

I don't have a nightly build at the moment. Will test when I have some free time but it might be a few days.

#3 Updated by Sebastian Dietrich about 8 years ago

If you attach some sample data to reproduce the issue others can test on current master. Then you probably save the hassle of installing a nightly :-)

#4 Updated by Giovanni Manghi almost 8 years ago

  • Resolution set to fixed/implemented
  • Status changed from Feedback to Closed

just tested on 2.14.3 and works as expected, please reopen if necessary.

Also available in: Atom PDF