Bug report #14546

Reads Long Integers/integer64 Fields As Strings In Shapefiles

Added by Colin MacLeod over 7 years ago. Updated over 7 years ago.

Affected QGIS version:master 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 #:22519


When using QGIS 2.8.7 (the current Long-Term Release for QGIS), fields in the attribute table of shapefiles which are long integers/integer64 are treated as strings/text rather than integers (using the Table Manager, you can see these fields are still classified as integer64, but the are justified to the left in the attribute table, indicating they are being treated as text/strings). The result of this is that they cannot be used with any tools which require integers/real numbers. This was not a problem with QGIS 2.8.3, and seems to have appeared in the more recent updates to the Long-Term Release.

This is similar to resolved issue #14411 for QGIS 2.14.0, but it applies to all integer64 fields when the shapefile is first added to a GIS project (rather than just when running the 'save as' function - although when you do this they are reclassified as strings/text), and it makes the latest version of the Long-Term Release impractical to use. Can this issue be resolved in the same way for QGIS 2.8.7?

This problem arose during a course I was teaching, and appeared on every Windows machine running QGIS 2.8.7 regardless of the version of Windows on the machines (and disappeared when people reverted to QGIS 2.8.3), and most versions were downloaded and installed in the last week (and some as recently as today, so this represents a current problem) I can provide examples of data layers where this problem was apparent.

Polygon_Grid_North_Sea_WGS84.zip (132 KB) Colin MacLeod, 2016-06-28 07:13 AM

Related issues

Related to QGIS Application - Bug report #14411: When copying a shapefile with right-click "save as" it tu... Closed 2016-03-03
Related to QGIS Application - Bug report #14742: QGIS 32 bits doesn't save default attribute id field (int... Closed 2016-04-29


#1 Updated by Jürgen Fischer over 7 years ago

  • Subject changed from QGIS 2.8.7 (Long-Term Release) Reads Long Integers/integer64 Fields As Strings In Shapefiles to Reads Long Integers/integer64 Fields As Strings In Shapefiles

#2 Updated by Giovanni Manghi over 7 years ago

  • Affected QGIS version changed from 2.8.7 to master
  • Category set to Vectors
  • Priority changed from High to Severe/Regression
  • Target version set to Version 2.16

I have also hit this issue. Definitely a regression.

#3 Updated by magerlin - over 7 years ago

Yes - a very annoying problem!

#4 Updated by Martin Dobias over 7 years ago

  • Status changed from Open to Feedback

Please could you attach a shapefile that exhibits the problem? Thanks...

#5 Updated by Colin MacLeod over 7 years ago

Attached is the shapefile which caused me problems when teaching. Any existing integer64 fields are changed to string/text when the data layer is first added, and any processing on this (including adding new integer fields), results in integer fields being changed to string/text when they are saved. Any problems with this, or if you don't find this same problem, let me know and I'll give more precise instructions on exactly what was being done when the problem arose.

All the best,


#6 Updated by Even Rouault over 7 years ago

The CELL_ID_NO fied is detected by GDAL >= 2.0 as Integer64. I guess the reason for the issue is that QGIS 2.8 on Windows is now built against GDAL 2.1 whereas the codebase is not ready at all to deal with Integer64. So I guess that GDAL 1.11 is the only reasonable choice for QGIS 2.8.

Anyway QGIS 2.14 (and 2.16 even more) should be much better regarding this. Colin, could you try the qgis-rel / qgis 2.14 ?

#7 Updated by Giovanni Manghi over 7 years ago

  • Resolution set to wontfix
  • Status changed from Feedback to Closed

The issue does not show in qgis master and the develoment branch of 2.14, the next lts due in a few days, so as suggested in the PSC list closing this as wontfix.

Also available in: Atom PDF