Bug report #17266
Lines To Polygons, Polygonize and Refactor Fields change all attributes to string 255
|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|
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:
#1 Updated by Giovanni Manghi almost 3 years ago
- Operating System deleted (
- 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
#4 Updated by Giovanni Manghi almost 3 years ago
- Resolution deleted (
- 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 almost 3 years ago
- 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
- 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.
#7 Updated by John Browne almost 3 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 almost 3 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?