Bug report #13972
Categorize symbols uses wrong field after table join
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: | - | ||
| Category: | Symbology | ||
| 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 |
Description
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:- Join Layer A to Layer B using a common field, keeping only the field to be categorized
- Open the styling in layer properties for Layer A
- Select categorized styling
- Select the column from the joined table
- 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
History
#1
Updated by Sebastian Dietrich over 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.