Bug report #21273

Polygon layer snapping and vertex tool fail with rule-based style

Added by Steve Lowman about 5 years ago. Updated about 5 years ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Unknown
Affected QGIS version:3.4.4 Regression?:Yes
Operating System:Windows 10 Easy fix?:No
Pull Request or Patch supplied:No Resolution:
Crashes QGIS or corrupts data:No Copied to github as #:29091

Description

I attach a geopackage containing one multipolygon layer, which has three features. The layer has two quite similar rule-based styles, where the symbology is determined by a field called "Land_Type" includes minimum and maximum scales for different widths of border. A third style has just a plain single fill symbology.

In QGIS 3.4, with the rule-based styles, when you make the layer editable and try to amend the features, the digitizing tools fail to snap to the vertices, and the vertex tool fails to pick up the vertices. The vertex tool will select vertices with a marquee drag, but it will not move them. If you load the simple-fill style, then the tools all work with no problem. Load either of the rule-based styles again, and the problem returns.

I tried converting the layer into a shapefile, pasting the rule-based style into it, and there was exactly the same problem, so it is not a Geopackage issue. It seems to be that something in the rule-based style is preventing the editing tools from working properly.

I saved one of the rule-based styles into a .qml with the shapefile, then I added it with this as the default style the map canvas in QGIS 2.18, and the snapping and node tool all worked with no problems, so it is definitely a QGIS 3 issue, and therefore, I have selected "Yes" to Regression in the options below.

(I have set the bug Category to "Unknown", because I do not know whether it should be under "Digitizing" or "Symbology")

Gilkeekit_fields.gpkg - Geopackage with one polygon layer, three features, and three styles, as in the bug Description. (204 KB) Steve Lowman, 2019-02-14 04:04 PM

only one set of values - min max scale range.qml (26.5 KB) Steve Lowman, 2019-02-14 04:47 PM

two sets of values - no min max at all.qml (31.7 KB) Steve Lowman, 2019-02-14 04:47 PM

History

#1 Updated by Steve Lowman about 5 years ago

The problem does not occur with a rule-based style that has only one instance of each of the values. So, it seems to be something to do with the fact that there are two mentions of each field value in the rule. I tried removing all the scale dependencies from all of the rules, but the issue was still occurring then.

I attach now two .qml files:

  1. only one set of values - min max scale range.qml
  2. two sets of values - no min max at all.qml

With style 1, there is only one set of values. They include a scale range. There is no editing problem.
With style 2, there are two sets of values (values are duplicated), and no scale-range. The problem is occurring with this style applied.

Therefore, it seems that the problem occurs only when the field values are duplicated in the set of rules.

#2 Updated by Steve Lowman about 5 years ago

  • Status changed from Open to Closed

I am closing this, because I have found that the bug works quite differently to how I thought yesterday.

I will submit another report to describe my new findings.

Also available in: Atom PDF