Bug report #16341
Geopackage table behaves strange and ultimately kills QGIS.
| 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.
History
#1
Updated by Saber Razmjooei about 7 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 about 7 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 about 7 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 almost 7 years ago
- Regression? set to No
- Easy fix? set to No
#5
Updated by Klas Karlsson almost 7 years ago
- File Skärmbild_2017-05-15_19-01-26.png added
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 almost 7 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