Bug report #14407

categorized style in 2.14 returns faulty values with gdb-data

Added by robert kalasek over 4 years ago. Updated about 3 years ago.

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.

qgis_bugreport_14407.gdb.rar - land-use data (sample) ... relevant field = "lbtyp" (1.1 MB) robert kalasek, 2016-03-16 10:53 AM

qgis_bug_categorial.docx - documentation - screenshots (718 KB) robert kalasek, 2016-06-09 07:41 AM

Associated revisions

Revision 8d9443bd
Added by Nyall Dawson over 4 years ago

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.

Revision b24d5eae
Added by Jürgen Fischer over 4 years ago

Merge pull request #2923 from nyalldawson/fix_14407

Don't force use of SQL dialect when running ogr queries (fix #14407)

Revision 31c914d0
Added by Nyall Dawson over 4 years ago

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 over 4 years ago

Can you please attach your gdb file?

#2 Updated by robert kalasek over 4 years ago

sorry for delay
here is a small copy of the database - just tested, error is still occurring

#3 Updated by Nyall Dawson over 4 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 over 4 years ago

  • Status changed from Open to Closed

#5 Updated by robert kalasek over 4 years ago

... 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 over 4 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 about 3 years ago

  • Category set to Unknown

Also available in: Atom PDF