Bug report #16341

Geopackage table behaves strange and ultimately kills QGIS.

Added by Mats Elfstrom over 2 years ago. Updated over 2 years ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Data Provider
Affected QGIS version:2.18.3 Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:up/downstream
Crashes QGIS or corrupts data:Yes Copied to github as #:24251

Description

I have a geopackage file, with several OSM tables. The gpkg file is converted from osm with FME, and FME can inspect and present both its vector and table data with no problem.
I open the file in QGIS 2.18.3 (Windows 10) select the table highway.
The vector data displays correctly but the Attribute table shows only NULL values (Error 1)
Then I assign a categorized style, on the field 'highway'. The style editor displays some 15 unique values (that show as NULL in the table browser).
Then I create a feature provider filter like this
"highway" IN ('primary','secondary','tertiary')
Again, the query builder is able to fetch values from the geopackage table.
However, the subset of the table can no longer be styled on the highway column, no values are found (Error 2)
Error 3, last and fatal: Attempts to edit or clear the feature provider filter above invariably crashes QGIS, and a mindump is written. I enclose the zipped gpkg file as well as the zipped minidump.

qgis-20170311-184803-11348-11676-77b8c3d.zip - This is the zipped minidump from the scenario above. (4.13 MB) Mats Elfstrom, 2017-03-11 10:15 AM

kivik.zip - This is the zipped geopackage file. (3.23 MB) Mats Elfstrom, 2017-03-11 10:15 AM

Skärmbild_2017-05-15_19-01-26.png (45.1 KB) Klas Karlsson, 2017-05-15 07:01 PM

History

#1 Updated by Saber Razmjooei over 2 years ago

  • Status changed from Open to Feedback
  • Priority changed from High to Normal
  • Operating System deleted (Windows)
  • OS version deleted (10)

when I run
ogrinfo -ro kivik/kivik.gpkg highway

It reports all the values to be NULL. So, I think it could be a combination of how FME translator works and how gdal/qgis handle corrupted layer.

Could you try and translate your layer to geopackage using ogr2ogr and see it produces the same issue?

#2 Updated by Mats Elfstrom over 2 years ago

I could, but that would not help. It is clear to me that parts of QGIS handles the values (that are there) perfectly well, while other parts do not. So it would be more useful to use the present table and track down what causes the difference. I believe I have supplied sufficient information.

#3 Updated by Saber Razmjooei over 2 years ago

GDAL/OGR does not read the translated file from FME correctly. It is likely to be a bug with the FME translator. The bug in QGIS is related to handling invalid geometries (e.g. by not allowing user to open them).

I suggest to contact FME and if they are confident the file has been translated correctly, then it will be a GDAL/OGR issue.

#4 Updated by Giovanni Manghi over 2 years ago

  • Regression? set to No
  • Easy fix? set to No

#5 Updated by Klas Karlsson over 2 years ago

I've been testing the gpkg some in QGIS (etc).

1. Adding "highway" from GeoPackage is divided into a point- and a linestring layer (attached image). Ogrinfo does not do this distiction (3D Measured Unknown (any)).
2. Geometry is drawn in QGIS.
3. Geometry can be styled from attribute classes.
4. Attribute table is empty.
5. Creating a Virtual layer from the geopackage layer (highway) creates a table with attributes, but no geometry.
6. Forcing the content of the geopackage to LINESTRING (2D) with ogr2ogr will result in a valid layer with correct attribute table.

ogr2ogr -f GPKG -nlt LINESTRING kivik_highway.gpkg kivik.gpkg highway

It may be a FME problem writing 3D data to GeoPackage, and a possible recommendation until it is resolved is to avoid writing 3D data to GeoPackage?

#6 Updated by Giovanni Manghi over 2 years ago

  • Resolution set to up/downstream
  • Description updated (diff)
  • Status changed from Feedback to Closed

It may be a FME problem writing 3D data to GeoPackage

all seems to point to that

Also available in: Atom PDF