Bug report #19709

Exporting a GeoPackage to Shapefile wrongly changes the field types

Added by Jérôme Guélat almost 2 years ago. Updated almost 2 years ago.

Category:Data Provider/OGR
Affected QGIS version:3.2.2 Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:wontfix
Crashes QGIS or corrupts data:No Copied to github as #:27534


Some steps to reproduce the bug:

1. Add the layer contained in the attached GeoPackage. It has 2 fields: the fid (type qlonglong) and another one (type: int)
2. Export the layer as a Shapefile (right-click on the layer -> Export -> Save Features As...)
3. The field types were changed: the fid is now a real (instead of qlonglong), and the other field is now a qlonglong (instead of int)

testgeom.gpkg - Sample data (116 KB) Jérôme Guélat, 2018-08-27 03:51 PM


#1 Updated by Giovanni Manghi almost 2 years ago

  • Crashes QGIS or corrupts data changed from Yes to No
  • Operating System deleted (Windows 7)
  • Status changed from Open to Feedback

In straight conversion with ogr2ogr the "att" field of your attachment results in an "int" field as expected.

What about 2.18, worked as expected?

#2 Updated by Jérôme Guélat almost 2 years ago

  • Status changed from Feedback to Open

Indeed, a conversion with ogr2ogr works as expected... This is a QGIS problem.

The bug also occurs with QGIS 2.18.

#3 Updated by Even Rouault almost 2 years ago

  • Resolution set to wontfix

Closing as wontfix.
The fundamental problem is that GeoPackage uses binary encoding (int32, int64, float64) whereas Shapefile/DBF uses text encoding. OGR and QGIS have slightly different ways of mapping to DBF field types. For example OGR will map a Int as a Decimal(9) and QGIS as a Decimal(10), and OGR will map a Int64 as a Decimal(18) and QGIS as a Decimal(20).
On reading if a Decimal field has:
<=9 characters, OGR will interpret it as a Int

=10 and <=18 characters, OGR will interpret it as a Int64
=19 characters, OGR will interpret it as a Double

QGIS choice of using Decimal(10) for Int and Decimal(20) for Int64 is actually more correct than ogr/ogr2ogr choice since number likes -1234567890 fit on a Int32 but requires 10 characters.
Perfect round-tripping is impossible given the mismatching between formats

#4 Updated by Even Rouault almost 2 years ago

  • Status changed from Open to Closed

Also available in: Atom PDF