QGIS
QGIS copied to clipboard
qgis
Data Defined Override Line Offset Expected Output Text is Wrong
What is the bug or the crash?
On lines the Data Defined Override text for the Offset input says it only accepts a string or array of x,y pairs. However the field is for a double input and a double input works.
I imagine this is just because it was copied over from the polygon offset setting that requires an x and y.
The correct help text should look like this:
Steps to reproduce the issue
Add line layer - look at the Offset Data Defined hint text.
Versions
| QGIS version | 3.24.0-Tisler | QGIS code revision | 6b44a420 |
|---|---|---|---|
| Qt version | 5.15.2 | ||
| Python version | 3.9.5 | ||
| GDAL/OGR version | 3.4.1 | ||
| PROJ version | 8.2.1 | ||
| EPSG Registry database version | v10.041 (2021-12-03) | ||
| GEOS version | 3.10.2-CAPI-1.16.0 | ||
| SQLite version | 3.37.2 | ||
| PDAL version | 2.3.0 | ||
| PostgreSQL client version | unknown | ||
| SpatiaLite version | 5.0.1 | ||
| QWT version | 6.1.3 | ||
| QScintilla2 version | 2.11.5 | ||
| OS version | Windows 10 Version 2009 | ||
| Active Python plugins | |||
| db_manager | 0.1.20 | ||
| grassprovider | 2.12.99 | ||
| MetaSearch | 0.3.6 | ||
| processing | 2.12.99 | ||
| sagaprovider | 2.12.99 |
Active Python plugins db_manager 0.1.20 grassprovider 2.12.99 MetaSearch 0.3.6 processing 2.12.99 sagaprovider 2.12.99
Supported QGIS version
- [X] I'm running a supported QGIS version according to the roadmap.
New profile
- [X] I tried with a new QGIS profile
Additional context
No response
However the field is for a double input and a double input works.
@baswein I don't think there is any issue here. The field asks for a "string of doubles" (double = double precision number) (double comma double) which is string ("input valid types > string").
But, '1,1' does not work as a valid input.
but 1,1 is not a string of doubles, is a string of integers. So maybe the issue here is that the (data defined) offset should also work with integers.
It does not work with '1.1,1.1' either. I think the issue is that the offset for a polygon requires x and y whereas the offset for a line only requires one value (y?).
I think I found a workaround.
- Expression -> Edit
- type @zoom_level*0 to "reset" or "calibrate"
- type the expression you want. If using an existing attribute under "Fields and Values" it has to be a double
same issue for me
| QGIS version | 3.28.2-Firenze | QGIS code revision | b47e00ba60 |
|---|---|---|---|
| Qt version | 5.15.2 | ||
| Python version | 3.9.5 | ||
| GDAL/OGR version | 3.3.2 | ||
| PROJ version | 8.1.1 | ||
| EPSG Registry database version | v10.028 (2021-07-07) | ||
| GEOS version | 3.9.1-CAPI-1.14.2 | ||
| SQLite version | 3.35.2 | ||
| PDAL version | 2.3.0 | ||
| PostgreSQL client version | unknown | ||
| SpatiaLite version | 5.0.1 | ||
| QWT version | 6.1.6 | ||
| QScintilla2 version | 2.11.5 | ||
| OS version | macOS 12.6 | ||
| Active Python plugins | |||
| ORStools | 1.5.2 | ||
| SemiAutomaticClassificationPlugin | 7.10.10 | ||
| dataset_qa_workbench | 0.7.1 | ||
| pg_metadata | 1.2.1 | ||
| changeDataSource | 3.1 | ||
| quick_map_services | 0.19.33 | ||
| stream_feature_extractor | 2.0.0 | ||
| cartography_tools | 1.2.1 | ||
| nominatim | 1.4.5 | ||
| linking_relation_editor | v1.1.4 | ||
| QgisModelBaker | v7.3.2 | ||
| QWater | 3.1.8 | ||
| SentinelHub | 2.0.0 | ||
| SRTM-Downloader | 3.1.17 | ||
| qgis_stac | 1.1.1 | ||
| GeoCoding | 2.18 | ||
| latlontools | 3.6.8 | ||
| qfieldsync | v4.3.1 | ||
| OpenTopography-DEM-Downloader | 2.0 | ||
| qgis_geonode | 1.0.1 | ||
| pgtopoeditor | 0.3.0 | ||
| qgis_resource_sharing | 1.0.0 | ||
| parcel_plugin | 3.8 | ||
| lizmap | 3.10.1 | ||
| LDMP | 2.1.14 | ||
| Projestions | 1.0.1 | ||
| tile_plus | 0.1 | ||
| mmqgis | 2021.9.10 | ||
| copy_coords | 0.2 | ||
| coordinate_capture | 0.2 | ||
| Mergin | 2023.1 | ||
| geocatbridge | 4.3.2 | ||
| sg-diagram-downloader | 3.2 | ||
| processing | 2.12.99 | ||
| sagaprovider | 2.12.99 | ||
| grassprovider | 2.12.99 | ||
| db_manager | 0.1.20 | ||
| MetaSearch | 0.3.6 | ||
| splitmultipart | 1.0.0 |
Active Python plugins ORStools 1.5.2 SemiAutomaticClassificationPlugin 7.10.10 dataset_qa_workbench 0.7.1 pg_metadata 1.2.1 changeDataSource 3.1 quick_map_services 0.19.33 stream_feature_extractor 2.0.0 cartography_tools 1.2.1 nominatim 1.4.5 linking_relation_editor v1.1.4 QgisModelBaker v7.3.2 QWater 3.1.8 SentinelHub 2.0.0 SRTM-Downloader 3.1.17 qgis_stac 1.1.1 GeoCoding 2.18 latlontools 3.6.8 qfieldsync v4.3.1 OpenTopography-DEM-Downloader 2.0 qgis_geonode 1.0.1 pgtopoeditor 0.3.0 qgis_resource_sharing 1.0.0 parcel_plugin 3.8 lizmap 3.10.1 LDMP 2.1.14 Projestions 1.0.1 tile_plus 0.1 mmqgis 2021.9.10 copy_coords 0.2 coordinate_capture 0.2 Mergin 2023.1 geocatbridge 4.3.2 sg-diagram-downloader 3.2 processing 2.12.99 sagaprovider 2.12.99 grassprovider 2.12.99 db_manager 0.1.20 MetaSearch 0.3.6 splitmultipart 1.0.0
same issue for me @gubuntu I assume you mean that 'x,y' input doesn't work . In case it isn't clear the issue here is that the help text is wrong. I Believe the correct input type description should be this:
I tried to dig into this a little more. This is very much beyond my programing knowledge but it seems that all data defined offset help text refers to here. https://github.com/qgis/QGIS/blob/7a37085df77102276e7c1d83dc111afe76beb6ef/src/core/qgsproperty.cpp#L168
This means that to fix this the offset types that require a single number and those that require an x,y pair would need to be separated and refer to different help texts here.
The help text and the control interface are both wrong. One has to create an expression through 'Edit', in this case using my field 'offset', which is a single integer.
Still valid using QGIS 3.28.15 and QGIS 3.34.3: https://github.com/qgis/QGIS/issues/56083.
same issue for me @gubuntu I assume you mean that 'x,y' input doesn't work . In case it isn't clear the issue here is that the help text is wrong. I Believe the correct input type description should be this:
Note that the offset can also be negative
I tried to dig into this a little more. This is very much beyond my programing knowledge but it seems that all data defined offset help text refers to here.
https://github.com/qgis/QGIS/blob/7a37085df77102276e7c1d83dc111afe76beb6ef/src/core/qgsproperty.cpp#L168
This means that to fix this the offset types that require a single number and those that require an x,y pair would need to be separated and refer to different help texts here.
I'm uncertain if we could just add a Double Property or if we need a new LineOffset Property
https://github.com/qgis/QGIS/blob/70486fa261444c8606ad2760e2630d179390510a/src/core/symbology/qgslinesymbol.cpp#L156
Thanks @anitagraser. I hadn't considered that a switch to a double would be a solution but that makes sense.
That seems to be what Pattern Offset has. Although that is probably wrong as well because it does accept negative numbers.
Not sure if this is a separate issue, but it is related to the data defined override for this setting: Data defined values don't seem to work properly for polygons with interior rings, i.e. that have "holes" in them. If I specify a data defined offset value, QGIS no longer respects the inside/outside rule for any interior ring. When I specify the same value using the standard dialog box control it does respect this rule and all the offset lines are rendered correctly.
Example of this behaviour For my polygons I created two lines of type "Outline: Simple Line". Green dash line is the boundary of a nature reserve and I have added a blue offset line just inside to indicate which side of the boundary belongs to the nature reserve. The small rectangle with two buildings is not part of the nature reserve, meaning the blue line should be rendered outside that perimeter.
Correct behaviour: Blue line offset 2 mm using dialog box control
Incorrect behaviour: Blue line offset 2 mm using data defined override
Conclusion
For the interior ring, the blue line jumps outside the nature reserve, i.e. inside the small rectangle in this case, when I switch to data defined override. Specifying the value as a double to_real('2') or adding @zoom_level*0 to the expression as suggested above makes no difference, and specifying it in 'x,y' format (e.g. '2, 0') as indicated in the faulty help text doesn't work at all. This is a pity since I want to use an expression to adapt the offset to the line width, which increases with zoom level.
Using QGIS version 3.30.3-'s-Hertogenbosch on Windows 10.
