Bug report #14407
categorized style in 2.14 returns faulty values with gdb-data
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: | - | ||
| Category: | Unknown | ||
| Affected QGIS version: | 2.14.0 | Regression?: | No |
| Operating System: | win | Easy fix?: | No |
| Pull Request or Patch supplied: | No | Resolution: | up/downstream |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 22388 |
Description
i have just tested qgis 2.14 with a simple dataset.
it is polygon data - with several categorial and numeric columns.
the one i've tested characterises land-use types in 15 categories.
colum-type is integer - value range is from 1 to 15.
layer properties / style / categorized / classify returns a faulty classification.
(for documentation with screenshots see: http://gis.stackexchange.com/questions/183061/categorized-style-in-2-14-returns-faulty-values/183234#183234)
the resulting classification seems to be based on the first numeric fild within the attribute table !
a similar problem exists with type "graduated"
finially i've identified a workaround: editing an expression like "column_name" * 1 (instead of selecting the column form the drop-down) returns the proper classification.
Associated revisions
Don't force use of SQL dialect when running ogr queries (fix #14407)
Using "SQL" dialect is not recommended as it forces use of the sometimes
buggy SDK query engines. This was breaking the uniqueValues method for
ESRI gdb files.
See https://trac.osgeo.org/gdal/ticket/6415 for GDAL dev recommendation
to use default OGR dialect in place of "SQL" dialect.
Don't force use of SQL dialect when running ogr queries (fix #14407)
Using "SQL" dialect is not recommended as it forces use of the sometimes
buggy SDK query engines. This was breaking the uniqueValues method for
ESRI gdb files.
See https://trac.osgeo.org/gdal/ticket/6415 for GDAL dev recommendation
to use default OGR dialect in place of "SQL" dialect.
(cherry picked from commit 8d9443bdca7bee131f75c27192aa021c95a93417)
History
#1
Updated by Nyall Dawson about 8 years ago
Can you please attach your gdb file?
#2
Updated by robert kalasek about 8 years ago
- File qgis_bugreport_14407.gdb.rar added
sorry for delay
here is a small copy of the database - just tested, error is still occurring
#3
Updated by Nyall Dawson about 8 years ago
- Resolution set to up/downstream
Thanks!
Upstream GDAL report here: https://trac.osgeo.org/gdal/ticket/6415
#4
Updated by Jürgen Fischer about 8 years ago
- Status changed from Open to Closed
Fixed in changeset b24d5eaeb36460b048da3144e63768ebf72a18b9.
#5
Updated by robert kalasek almost 8 years ago
- File qgis_bug_categorial.docx added
- Status changed from Closed to Reopened
... unfortunately still a problem which is potentially related to that one:
i've joined a table with 3 categorial variables to a geodataset and the join works as long as i do use a "Custom field name prefix" that is not empty.
i decide to use empty prefix due to export-as-shape problems with fieldnames (dBASE nbr of characters limitation) ... that works pretty well for numerical fields.
with my text/category fields any of these fields are poulated with numbers that do not make any sense on first view.
prette surprinsing was the fact that style/categorized/classify returned the correct list of kategories in the value field ...
so i've tried a little experiment
1. built an expression in the style/column section: BEV_KLASS || '_xxx'
where BEV_KLASS is my categorial variable ... that one retuned 350_xxx in the output preview
2. built a virtual field in the origin table (properties / fields / field calc) based on the same expression BEV_KLASS || '_test'
the updated attribute table of the geodataset still shows the strange numbers for my categorial variable and the new virtual field with (almost) correct categories ... see uploaded word-documentation
#6
Updated by Nyall Dawson almost 8 years ago
- Status changed from Reopened to Closed
Robert - this sounds like a different issue. Can you please open a new report + attach sample data and a project which demonstrates this issue.
#7
Updated by Jürgen Fischer over 6 years ago
- Category set to Unknown