Bug report #15463: Layer "Scale dependent visibility" doesn't work anymore since 2.16 - QGIS Application - QGIS Issue Tracking

Bug report #15463

Layer "Scale dependent visibility" doesn't work anymore since 2.16

Added by EDOUARD GOUYON over 8 years ago. Updated over 7 years ago.

Status:	Closed
Priority:	High
Assignee:	Sandro Santilli
Category:	Vectors
Affected QGIS version:	2.18.4	Regression?:	Yes
Operating System:	Windows, Linux	Easy fix?:	No
Pull Request or Patch supplied:	Yes	Resolution:
Crashes QGIS or corrupts data:	No	Copied to github as #:	23389

Description

Hi,
This is my first bug report here :) ! I Hope this will be efficient for all !

In my main GIS workspace all the layers initially set with a specific "Scale dependent visibility" on QGIS 2.12 are not working properly since QGIS 2.16:
For all those layers, on QGIS 2.16.1, the "Minimum (exclusive)" value is remaining OK (that is as initially set), but the "Maximum (inclusive)" value is now automatically and wrongly set to the value '1:100 000' instead of the value initially set. After trying to reset the good initial value and then applying with "apply" and "OK" buttons, the value always stays to '1:100 000' value.

When I try to open this main GIS workspace in QGIS 2.12 or 2.14, no problem, this max value of "Scale dependent visibility" is still OK.

Please see attachement file for a display comparison.

Thank you for your support.

Edouard Gouyon

Untitled-1.jpg - display comparison of the bug between 2.14 and 2.16 (233 KB) EDOUARD GOUYON, 2016-08-19 07:52 AM

dummylayer.zip - empty layer used in the project (1.41 KB) Jean-Gabriel JGH, 2017-03-04 06:13 PM

minScaleReset.qgs - the project, with two instances of dummyLayer (36.3 KB) Jean-Gabriel JGH, 2017-03-04 06:13 PM

Related issues

Associated revisions

Revision 55ffbf5e
Added by Sandro Santilli over 7 years ago

When setting scale range, make sure to set min before max scale

This ensures the limit on max scale imposed by previously set min
scale does not trim the new value.

Fixes #15463

Revision 8ccb4c43
Added by Sandro Santilli over 7 years ago

When setting scale range, make sure to set min before max scale

This ensures the limit on max scale imposed by previously set min
scale does not trim the new value.

Fixes #15463

(cherry picked from commit 55ffbf5e932ede65144474c4854000708757b700)

Revision c0531bcd
Added by Sandro Santilli over 7 years ago

Add test for QgsScaleRangeWidget::setScaleRange

Closes #15463 as this test guards after the fix for that bug
(minScale visibility corrupted upon project load)

History

#1 Updated by Matthias Kuhn about 8 years ago

Can you attach a .qgs project file with an affected layer?

#2 Updated by EDOUARD GOUYON about 8 years ago

Matthias Kuhn wrote:

Can you attach a .qgs project file with an affected layer?

Sorry I can't. Since The post of this bug, I've definitely downgraded to 2.14 version and the bug doesn't exists anymore. I didn't save any project with 2.16 in order not affect the good styling of my layers with the reported bug.

#3 Updated by Sandro Santilli about 8 years ago

Edouard if I read your original submission correctly we dont' need a project saved by 2.16 but by 2.12 ?

#4 Updated by Matthias Kuhn about 8 years ago

Status changed from Open to Closed

I assume that 1f1898df1616ce5d3239bf2257470dd2c6b96566 fixes this issue.

Basically, in 2.12, the scale "0" could be used for an infinitely max scale. In 2.16 1:1 was the max possible, anything else (like 0) would be set equal to the min scale (which could be 1:100'000), resulting in the layer never being visible.

Above commit fixes this for 2.18.

If someone is able to reproduce this with a recent nightly/2.18, please reopen.

#5 Updated by Jean-Gabriel JGH over 7 years ago

Target version deleted (~~Version 2.16~~)
File dummylayer.zip added
File minScaleReset.qgs added
Status changed from Closed to Reopened

Hello,

I am having the same issue with 2.18.3 and 2.18.4 (Windows 10, 64 bits), with both Shapefiles and Postgres layers.
I nailed it down a bit more than the OP. The issue with the "Maximum (inclusive)" occurs only for scales smaller than 1:100,000 (that is, 1:99,999 is fine but 1:100,001 will reset to 1:100,000). When one edits the scale, it is properly saved to the QGS file, under <maplayer minimumScale="100001" [...]>. However if you re-open the layer property, it is displayed as 1:100000 and this value (100000) will then be saved to the QGS file as if you purposely modified the scale.
Let's note that the same behavior occurs with rule based styling. Double clicking on a rule resets the Max Scale to 100,000.

As Matthias Kuhn has asked, please find a simple QGS file exhibiting the issue. It refers to a dummy layer (i.e. empty shapefile). This layer (dummylayer_ok) is set to have a max scale of 1:12,345 which works fine. A copy of the layer (dummylayer_reset), with a scale of 1:123,456 is there. You can see the scale in the QGS file but opening its property should show 1:100,000.

PS: I put an emphasis that the issue is, in the GUI, with the MAX scale, but the QGS file records this value as the MIN scale...

Let me know should you need any other information!
Jean-Gabriel

#6 Updated by Giovanni Manghi over 7 years ago

Category set to Vectors
Target version set to Version 2.18
Affected QGIS version changed from 2.16.1 to 2.18.4

Confirmed here too.

#7 Updated by Giovanni Manghi over 7 years ago

Regression? set to Yes

#8 Updated by Giovanni Manghi over 7 years ago

Priority changed from Severe/Regression to High

#9 Updated by Giovanni Manghi over 7 years ago

Easy fix? set to No

#10 Updated by Sandro Santilli over 7 years ago

Description updated (diff)
Assignee set to Sandro Santilli

#11 Updated by Sandro Santilli over 7 years ago

I confirm the issue.

Opening the project you attached (minScaleReset) with QGIS 2.14.10 and opening layer properties gives me:
- dummylayer_reset: min 1:100,000,000 max 1:123,456
- dummylayer_ok: min 1:100,000,000 max 1:12,345

Opening it with QGIS master (2.0.0-dev 4ed096b) gives:
- dummylayer_reset: min 1:100,000,000 max 1:100,000
- dummylayer_ok: min 1:100,000,000 max 1:12,345

I can still set (via GUI) that "max" value to 1:1,000,000, so there's no reason why 1:123,456 should not be accepted.

#12 Updated by Sandro Santilli over 7 years ago

Matthias 7 months ago you referenced 1f1898df1616ce5d3239bf2257470dd2c6b96566 but there's no such commit in the repository, can you remember which commit you were referring to ?

#13 Updated by Sandro Santilli over 7 years ago

Maybe it was 2475ee578c17ef3368d9b4d487599c31340a9a09 ?

#14 Updated by Sandro Santilli over 7 years ago

I confirm 2.18 branch as of 126cf5f100abb077fd0ba611cb1653583dd898cd also behaves the same as I reported above as happening in master (qgis-3).

#15 Updated by Sandro Santilli over 7 years ago

I take it back, the commit exists, just isn't recognized by this RedMine instance, looks like:
1f1898df1616ce5d3239bf2257470dd2c6b96566

Same happens with the later:
2475ee578c17ef3368d9b4d487599c31340a9a09
qgis|2475ee578c17ef3368d9b4d487599c31340a9a09

@jef maybe you know what's going on here with commit references ?

#16 Updated by Jürgen Fischer over 7 years ago

Related to Bug report #16601: commit references do not expand added

#17 Updated by Sandro Santilli over 7 years ago

2.16 is also affected (at least as of final-2_16_3-106-g7ff0883)
Is it possible to turn the "Affected versions" into a multi-choice input ?
Or I think it makes sense to set it to the oldest affected branch, to make bisecting easier...

#18 Updated by Sandro Santilli over 7 years ago

I've run a git-bisect, finding that bd3fd748f1e170c8aeb20fbc4f40966f70d33c5b is the first bad one. I still have to dig further (it's a merge commit for 4f18701d319afaf03cfd5c49ceb0395a2677da80)

#19 Updated by Sandro Santilli over 7 years ago

Affected QGIS version changed from 2.18.4 to 2.16.3
Operating System changed from Windows to Windows, Linux

#20 Updated by Giovanni Manghi over 7 years ago

Affected QGIS version changed from 2.16.3 to 2.18.4

no one will wver worok on 2.16, on the other hand 2.18 is the next release, knowing that LTR is THE affected version is MUCH more important.

#21 Updated by Sandro Santilli over 7 years ago

Pull Request or Patch supplied changed from No to Yes

I filed a pull request for 2.18 branch: https://github.com/qgis/QGIS/pull/4612
It's a oneliner, removing a line which looked suspicious in 4f18701d319afaf03cfd5c49ceb0395a2677da80
but I don't really understand why it fixes the issue yet, so it's important to test analyze further

I'll not start an "Affected QGIS version" semantic war here, please use the mailing list for that.

#22 Updated by Sandro Santilli over 7 years ago

The PR which introduced the regression, once merged: https://github.com/qgis/QGIS/pull/2863

#23 Updated by Sandro Santilli over 7 years ago

Ok so full analysis is as follows:
- When constructing a ScaleRangeWidget:
- A signal handler is installed for scaleChanged signals emitted by minScaleWidget that places a limit on the maxScaleWidget
- The max scale widget is given an arbitrary value of 1:100000, triggering the handler and thus setting a limit on maxScale
- When opening layer properties panel, QgsScaleRangeWidget::setScaleRange is invoked, which tries to set maxScale before minScale, thus being limited by the previously set minScale.

So the proper fix here is to change setScalRange to set min before max.

It is arguable whether the arbitrary values to the range are worth keeping, but if we want to keep them it could be a better idea to use DBL_MIN/DBL_MAX for the limit...