Refactor Fields tool ignoring user selection for field types on macOS

[dericke]

Describe the bug

The Refactor Fields processing tool ignore’s the user’s selection of a field’s type, instead using the existing type for fields loaded from an existing layer, or always using String for new fields.

How to Reproduce

Sample geojson:

{"type":"FeatureCollection","features":[{"type":"Feature","geometry":{"type":"LineString","coordinates":[[102,0],[103,1],[104,0],[105,1]]},"properties":{"prop0":"value0","prop1":0}}]}

Loading

Can’t change the type of an existing field:

1. Load a vector layer, such as the one above. If prompted to reset the field mapping, accept
2. In the Processing toolbox, open the Refactor Fields tool
3. Select the vector layer as the input
4. Change the type of one of the fields
5. Click Run
6. Open the Properties of the new layer
7. Select the Fields tab
8. Note that the field type has not changed

The following can be found in the output log. On line 3, the type should be ’10’, as string was selected, but instead the type is ‘6’, showing that the user’s selection is not being used

{ 'FIELDS_MAPPING' : [
    {'expression': '"prop0"', 'length': 0, 'name': 'prop0', 'precision': 0, 'type': 10}, 
    {'expression': '"prop1"', 'length': 0, 'name': 'prop1', 'precision': 0, 'type': 6}
    ], 'INPUT' : 'sample.geojson', 'OUTPUT' : 'TEMPORARY_OUTPUT' }

Type of new field always defaults to String:

1. Load a vector layer, such as the one above. If prompted to reset the field mapping, accept
2. In the Processing toolbox, open the Refactor Fields tool
3. Select the vector layer as the input
4. Click the add field button.
5. Add a source expression such as prop1 + 4 , and a field name such as prop2
6. Select a type other than String, such as double, and a length and precision, such as 4 and 1
7. Click Run
8. Open the Properties of the new layer
9. Select the Fields tab
10. Note that the new field's type is String

The output log shows that the user’s selection for the new field’s type is not being used. Line 4 should have a type of 6, but instead has a type of 0:

{ 'FIELDS_MAPPING' : [
    {'expression': '"prop0"', 'length': 0, 'name': 'prop0', 'precision': 0, 'type': 10}, 
    {'expression': '"prop1"', 'length': 0, 'name': 'prop1', 'precision': 0, 'type': 6}, 
    {'expression': 'prop1 + 4', 'length': 10, 'name': 'prop2', 'precision': 1, 'type': 0}
    ], 'INPUT' : '/Users/primaryuser/Downloads/sample.geojson', 'OUTPUT' : 'TEMPORARY_OUTPUT' }

These problems persist even when casting the source to the desired type within the source expression, with a function such as to_real(), and when saving the output to file formats such as geojson or geopackage.

QGIS and OS versions

QGIS Version 3.10 (also present in 3.8 and 3.4)
Only the default .dmg installers from qgis.org have been tested. (Have not tested the KyngChaos or osgeo4mac distributions)

macOS version 10.14 Mojave

[gioman]

also present in 3.8

what about 3.4?

[dericke]

@gioman , yep, also present in 3.4

[dericke]

Added the clarification that for all 3 versions that I tested in, these were the recommended .dmg installers from qgis.org, not the KyngChaos, osgeo4mac, or any other distribution of QGIS.

[spatialthoughts]

This still exists on QGIS 3.10.2 and QGIS 3.4 on mac. Type selection is being ignored by the refactor algorithm.

[SirChasm]

Present in QGIS 3.12 on macOS as well. I have tried several field types and casting approaches.

[spatialthoughts]

This is still present in LTR 3.10.5 and causing a bug headache for mac users.

[dericke]

Appears to be fixed in 3.14. Maybe the new build system was the solution?

[spatialthoughts]

Confirming it's fixed in 3.14