Bug report #17266

Lines To Polygons, Polygonize and Refactor Fields change all attributes to string 255

Added by John Browne about 7 years ago. Updated about 7 years ago.

Status:Closed
Priority:High
Assignee:-
Category:Attribute table
Affected QGIS version:2.18.13 Regression?:Yes
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:fixed/implemented
Crashes QGIS or corrupts data:No Copied to github as #:25164

Description

On my two Windows 10 systems running QGIS Desktop 2.18 for Windows 64-bit, output attribute tables produced by the Lines To Polygons tool and Polygonize tool differ from the input table of the source layer. All fields in the output table are type string, length 255. Same problem occurs with Refactor Fields tool.

The problem appears to be new in QGIS Desktop 2.18. I found it in 2.18.12. Then upgraded to 2.18.13 with same problem results. I next downloaded and installed QGIS 2.14.19 and ran same test. Results are as desired and expected: output layer attribute table is same as input layer.

I reported this problem in two Stack Exchange posts but received no answers:

service_districts_shape.zip - data source (40.8 KB) John Browne, 2017-11-03 08:00 PM

screen Capture.JPG - test results: screen capture of layer properties/fields (142 KB) John Browne, 2017-11-03 08:03 PM

History

#1 Updated by Giovanni Manghi about 7 years ago

  • Operating System deleted (Windows)
  • Subject changed from Lines To Polygons and Polygonize attribute table problem to Lines To Polygons, Polygonize and Refactor Fields change all attributes to string 255
  • Priority changed from Normal to High
  • Regression? changed from No to Yes

#2 Updated by Giovanni Manghi about 7 years ago

  • Resolution set to fixed/implemented
  • Status changed from Open to Closed

Fixed in 3dfe1b35ef5a082591aa9d99e15b25d0164ca312
and 135aea5ef8929991b36e455bd87e6df153e7d17d

please give the patches a try to confirm is now ok.

#3 Updated by John Browne about 7 years ago

  • Status changed from Closed to Reopened

My test finds that the problem persists in QGIS Desktop 2.18.14 for Windows 64-bit, which includes two patches. Hoping others have tested.

#4 Updated by Giovanni Manghi about 7 years ago

  • Resolution deleted (fixed/implemented)
  • Status changed from Reopened to Feedback

John Browne wrote:

My test finds that the problem persists in QGIS Desktop 2.18.14 for Windows 64-bit, which includes two patches. Hoping others have tested.

I just tested again and it seems ok to me. Do you have a "processing" folder in ~/.qgis2/python/plugins?
Also if you still see this add data and exact steps to replicate.

#5 Updated by John Browne about 7 years ago

Thank you for pursuing this. My installation's "processing" folder location is C:\Program Files\QGIS 2.18\apps\qgis\python\plugins\processing. Two files are attached from testing again today with the QGIS 2.18.14 Polygons-to-Lines tool:
  • data source: a fresh download of local Fauquier County, VA service_districts_shape.zip polygon file
  • screen capture.jpg of the layer properties/fields tables in the test results. Top is the source layer input table, middle is the resulting output table, bottom is output table from second test with QGIS 2.14.20
Results:
  • The middle table (output) differs from the top (input) table in both field Length and Precision, and changes Type "qlonglong" to "int".
  • The bottom table (output using QGIS 2.14.20) exactly matches the top (input) table.

I understand QGIS 2.14 uses the fTools plugin, whereas QGIS 2.18 performs this work with the Processing plugin and fTools is no longer available.

I tested with Polygons-to-Lines tool rather than Lines-to-Polygons tool in order to use a known, tested, publicly available file. My earlier tests used locally developed shape line files. The results of today's test produce the same problems in the output attribute table as in earlier tests.

#6 Updated by Giovanni Manghi about 7 years ago

  • The middle table (output) differs from the top (input) table in both field Length and Precision, and changes Type "qlonglong" to "int".

isn't qlonglong an integer?

#7 Updated by John Browne about 7 years ago

I lack expertise to judge, but Internet search indicates qlonglong is integer (apparently integer 64 in Windows). My concern is ability to join and otherwise use output tables with other layers. If feature type names and lengths differ, problems may occur. Again, thank you for working on this.

#8 Updated by Giovanni Manghi about 7 years ago

John Browne wrote:

My concern is ability to join and otherwise use output tables with other layers. If feature type names and lengths differ, problems may occur. Again, thank you for working on this.

do you have any evidence that a such field cannot be used for a join or does not show as input/parameter in some qgis tool?

#9 Updated by John Browne about 7 years ago

Several tests today in QGIS show no problem joining Polygons-to_Lines output tables to other layers or joining an imported Excel table to the output table. I no longer have concern in this regard.

#10 Updated by Giovanni Manghi about 7 years ago

  • Resolution set to fixed/implemented
  • Status changed from Feedback to Closed

Also available in: Atom PDF