Bug report #19709
Exporting a GeoPackage to Shapefile wrongly changes the field types
|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)
#1 Updated by Giovanni Manghi about 3 years ago
- Crashes QGIS or corrupts data changed from Yes to No
- Operating System deleted (
- 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?
#3 Updated by Even Rouault about 3 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