Bug #5665

rendering order in rule-based style not working with scale ranges

Added by Bernhard Ströbl 12 months ago. Updated 12 months ago.

Status:Closed Start Date:05/30/2012
Priority:Blocker Due date:
Assigned to:- % Done:

0%
Category:Symbology
Target version:Version 1.8.0
Platform: Patch supplied:No
Platform version: Affected version:master
Status info: Causes crash or corruption:No
Resolution:

Description

the rendering order in rule based style does not work any more, instead feature rendering is ordered by chance
behaviour can only be observed if rule-based style is combined with scale ranges, if rules do not have scale ranges rendering order works as it should

estradas.qml (10.8 kB) Giovanni Manghi, 05/30/2012 06:37 am

a_estradas_osm_shp.zip (487.3 kB) Giovanni Manghi, 05/30/2012 06:37 am

roads.zip (11.1 kB) Bernhard Ströbl, 05/30/2012 07:16 am

Associated revisions

Revision 056300f00dd3821f2508dafb9d6193e294098c63
Added by Martin Dobias 12 months ago

fix #5665 (rendering order not working in rule-based renderer)

History

#1
Updated by Giovanni Manghi 12 months ago

I tested a clip of osm data and the attached style, and it seems to work.

#2
Updated by Bernhard Ströbl 12 months ago

Hi Giovanni,
I checked your example and examined mine (attached). It seems that it does not work if there are gaps between any two layer numbers in rendering order. I used steps of 10 in order to be able to squeeze another layer in, in case there is need to do so, without rearranging all layers. This used to work in 1.7.4. If I use sequnetial numbers for the layers it works.

#3
Updated by Giovanni Manghi 12 months ago

Bernhard Ströbl wrote:

Hi Giovanni, I checked your example and examined mine (attached). It seems that it does not work if there are gaps between any two layer numbers in rendering order. I used steps of 10 in order to be able to squeeze another layer in, in case there is need to do so, without rearranging all layers. This used to work in 1.7.4. If I use sequnetial numbers for the layers it works.

if you confirm me that is a regression since 1.7.4 then we have to tag this as "blocker".

#4
Updated by Giovanni Manghi 12 months ago

  • Priority changed from Normal to Blocker

#5
Updated by Martin Dobias 12 months ago

  • Status changed from Feedback to Closed

#6
Updated by Bernhard Ströbl 12 months ago

Martin Dobias wrote:

Fixed in changeset 056300f00dd3821f2508dafb9d6193e294098c63.

Martin, great that you looked into this so fast. I am sorry to inform you that the problem persists here. Did you check with the shape file and qml I provided?

#7
Updated by Nathan Woodrow 12 months ago

Seems to work ok for me. This is what I see at 1:18000, is this correct

#8
Updated by Bernhard Ströbl 12 months ago

Nathan Woodrow wrote:

Seems to work ok for me. This is what I see at 1:18000, is this correct

Nathan this looks good, the grey streets are supposed to be rendered beneath the yellow ones. At me they are not (QGIS 1.8.0 Codeversion c367a35)How does it look when you zoom in at say 1:1000?

#9
Updated by Nathan Woodrow 12 months ago

Like this (1:1000):

#10
Updated by Nathan Woodrow 12 months ago

(QGIS 1.8.0 Codeversion c367a35)

There is your problem. Martin only fixed this last night so you will have to get a new build to test with. You build is from the 22nd of May

#11
Updated by Bernhard Ströbl 12 months ago

Nathan Woodrow wrote:

(QGIS 1.8.0 Codeversion c367a35)

There is your problem. Martin only fixed this last night so you will have to get a new build to test with. You build is from the 22nd of May

Hmm, I made a git pull this morning, compiled and installed into a new directory with no avail, the codeversion stays the same!?

OK got it fixed and can confirm now, ticket is solved.
thanks again

Also available in: Atom PDF