'Control feature rendering order' should have precedence over symbol levels #42428
Comments
JohnProv
added
the
Bug
|
This is still valid on QGIS 3.22.3. |
joto
added a commit
to joto/QGIS
that referenced
this issue
Mar 4, 2023
There are two ways of taking "order" into account when rendering: 1. You can control the feature rendering order which essentially does an "order by" of your layer data. 2. You can enable symbol levels which defines which styles are rendered in which order. This commit addresses a problem when trying to bring (1) and (2) together. When both are enabled, the rendering order (2) trumps the order given by (1), essentially ignoring the order from (1). With this commit rendering instead starts "from scratch" every time the "order by" attributes have a new value. This allows, for instance, to render complex roads networks correctly. Ordering via (1) is used to draw roads going over bridges etc. in the correct order while ordering via (2) is used to render road styles correctly (thicker dark line, then thinner light line to get a roads with casing). The patch works by putting all features that need to be rendered not in a single QHash (Symbol->Feature) but a QList of those hashes. Every time at least one of the attributes used for the "order by" changes, a new element is added to that list. The patch is rather simple, it just looks a bit larger due to the extra indentation needed. I thought about making this configurable, but I don't see any use case where it makes sense to have (1) and (2) enabled where you don't want this behaviour. Fixes qgis#42428 See qgis#17276
joto
added a commit
to joto/QGIS
that referenced
this issue
Mar 9, 2023
There are two ways of taking "order" into account when rendering: 1. You can control the feature rendering order which essentially does an "order by" of your layer data. 2. You can enable symbol levels which defines which styles are rendered in which order. This commit addresses a problem when trying to bring (1) and (2) together. When both are enabled, the rendering order (2) trumps the order given by (1), essentially ignoring the order from (1). With this commit rendering instead starts "from scratch" every time the "order by" attributes have a new value. This allows, for instance, to render complex roads networks correctly. Ordering via (1) is used to draw roads going over bridges etc. in the correct order while ordering via (2) is used to render road styles correctly (thicker dark line, then thinner light line to get a roads with casing). The patch works by putting all features that need to be rendered not in a single QHash (Symbol->Feature) but a QList of those hashes. Every time at least one of the attributes used for the "order by" changes, a new element is added to that list. The patch is rather simple, it just looks a bit larger due to the extra indentation needed. I thought about making this configurable, but I don't see any use case where it makes sense to have (1) and (2) enabled where you don't want this behaviour. Fixes qgis#42428 See qgis#17276
joto
added a commit
to joto/QGIS
that referenced
this issue
Mar 13, 2023
There are two ways of taking "order" into account when rendering: 1. You can control the feature rendering order which essentially does an "order by" of your layer data. 2. You can enable symbol levels which defines which styles are rendered in which order. This commit addresses a problem when trying to bring (1) and (2) together. When both are enabled, the rendering order (2) trumps the order given by (1), essentially ignoring the order from (1). With this commit rendering instead starts "from scratch" every time the "order by" attributes have a new value. This allows, for instance, to render complex roads networks correctly. Ordering via (1) is used to draw roads going over bridges etc. in the correct order while ordering via (2) is used to render road styles correctly (thicker dark line, then thinner light line to get a roads with casing). The patch works by putting all features that need to be rendered not in a single QHash (Symbol->Feature) but a QList of those hashes. Every time at least one of the attributes used for the "order by" changes, a new element is added to that list. The patch is rather simple, it just looks a bit larger due to the extra indentation needed. I thought about making this configurable, but I don't see any use case where it makes sense to have (1) and (2) enabled where you don't want this behaviour. Fixes qgis#42428 See qgis#17276
joto
added a commit
to joto/QGIS
that referenced
this issue
Mar 20, 2023
There are two ways of taking "order" into account when rendering: 1. You can control the feature rendering order which essentially does an "order by" of your layer data. 2. You can enable symbol levels which defines which styles are rendered in which order. This commit addresses a problem when trying to bring (1) and (2) together. When both are enabled, the rendering order (2) trumps the order given by (1), essentially ignoring the order from (1). With this commit rendering instead starts "from scratch" every time the "order by" attributes have a new value. This allows, for instance, to render complex roads networks correctly. Ordering via (1) is used to draw roads going over bridges etc. in the correct order while ordering via (2) is used to render road styles correctly (thicker dark line, then thinner light line to get a roads with casing). The patch works by putting all features that need to be rendered not in a single QHash (Symbol->Feature) but a QList of those hashes. Every time at least one of the attributes used for the "order by" changes, a new element is added to that list. The patch is rather simple, it just looks a bit larger due to the extra indentation needed. I thought about making this configurable, but I don't see any use case where it makes sense to have (1) and (2) enabled where you don't want this behaviour. Fixes qgis#42428 See qgis#17276
joto
added a commit
to joto/QGIS
that referenced
this issue
Apr 3, 2023
There are two ways of taking "order" into account when rendering: 1. You can control the feature rendering order which essentially does an "order by" of your layer data. 2. You can enable symbol levels which defines which styles are rendered in which order. This commit addresses a problem when trying to bring (1) and (2) together. When both are enabled, the rendering order (2) trumps the order given by (1), essentially ignoring the order from (1). With this commit rendering instead starts "from scratch" every time the "order by" attributes have a new value. This allows, for instance, to render complex roads networks correctly. Ordering via (1) is used to draw roads going over bridges etc. in the correct order while ordering via (2) is used to render road styles correctly (thicker dark line, then thinner light line to get a roads with casing). The patch works by putting all features that need to be rendered not in a single QHash (Symbol->Feature) but a QList of those hashes. Every time at least one of the attributes used for the "order by" changes, a new element is added to that list. The patch is rather simple, it just looks a bit larger due to the extra indentation needed. I thought about making this configurable, but I don't see any use case where it makes sense to have (1) and (2) enabled where you don't want this behaviour. Fixes qgis#42428 See qgis#17276
joto
added a commit
to joto/QGIS
that referenced
this issue
Apr 23, 2023
There are two ways of taking "order" into account when rendering: 1. You can control the feature rendering order which essentially does an "order by" of your layer data. 2. You can enable symbol levels which defines which styles are rendered in which order. This commit addresses a problem when trying to bring (1) and (2) together. When both are enabled, the rendering order (2) trumps the order given by (1), essentially ignoring the order from (1). With this commit rendering instead starts "from scratch" every time the "order by" attributes have a new value. This allows, for instance, to render complex roads networks correctly. Ordering via (1) is used to draw roads going over bridges etc. in the correct order while ordering via (2) is used to render road styles correctly (thicker dark line, then thinner light line to get a roads with casing). The patch works by putting all features that need to be rendered not in a single QHash (Symbol->Feature) but a QList of those hashes. Every time at least one of the attributes used for the "order by" changes, a new element is added to that list. The patch is rather simple, it just looks a bit larger due to the extra indentation needed. I thought about making this configurable, but I don't see any use case where it makes sense to have (1) and (2) enabled where you don't want this behaviour. Fixes qgis#42428 See qgis#17276
|
The problem described in this bug isn't fixed completely with #52096. For the categorized renderer it works well, but not for the rule-based renderer. Please fix that also. |
|
See the differences between categorised rendering and rule rendering below. Categorised rendering, this looks good: Rule rendering, this doesn't look good: (Example: knooppunt Deil, © map data: OpenStreetMap-contributors) |
|
I had a look at the code to see why this is not working in the rule rendering. The rule based renderer reports that it doesn't support the Maybe somebody with more experience with this code has an idea why these two code paths are there and what to do about it? @m-kuhn |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
'Control feature rendering order' should have precedence over symbol levels.
Now it isn't possible to create a map with for example correct road outlines and have roads in the correct order (bridge over road etc.).
For a detailed description and examples, see: https://gis.stackexchange.com/questions/204034/can-i-change-the-precedence-when-combining-control-feature-rendering-order-wit
How to Reproduce
QGIS and OS versions
Additional context
Please let me know if there are other possibilities to achieve the desired effect that I don't know.
The text was updated successfully, but these errors were encountered: