[fix] Make scale dependent visibility more robust when handling non-round scales (denominators) #58968
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…dent visibility: support inclusive behavior and handle exclusive/inclusive behavior on edge cases (non-round numbers)
…ndent visibility: support inclusive behavior and handle exclusive/inclusive behavior on edge cases (non-round numbers)
…dependent visibility: handle exclusive/inclusive behavior on edge cases (non-round numbers)
…id of the 'scale * SCALE_PRECISION' expression to set (visible) layer scale. We now move to layer->minimumScale - 1, which is assured to be in the scale range, since we'll only show the 'Zoom to Visible Scale' option if scale is not in range and there IS a range difference equal to or greater than 1.
…t visibility became more robust on range limits (namely, on non-round numbers).
…eaterThanMinimumScale to make robust checks between map scale and maximum/minimum rendering scales in a scale dependent visibility context, taking non-round scales (denominators)
…rThanMinimumScale
gacarrillor
added
Map and Legend
nyalldawson
reviewed
Oct 4, 2024
…hanMinimumScale functions to QgsScaleUtils
|
@nyalldawson, should I also implement this for the label's I didn't yet because there was no visual hint (e.g., in the tool tip) on whether the maximum scale value should be inclusive, and wanted to confirm first.
|
nyalldawson
approved these changes
Oct 7, 2024
Yes, let's make it consistent throughout! Feel free to open that in a new PR. |
|
This is great! To me it feels like a bug-fix, so would it be unreasonable/unfeasible to backport it to LTR? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Follow-up b8f9760
Since the map scale (denominator) is a double, it could be a non-round number, which needs to be considered when comparing scales for scale dependent visibility of features, labels, diagrams, and the like. This should be done for both range limits: minimum (exclusive) and maximum (inclusive) scales.
This PR:
qgsDoubleNear()for equal checks, thus taking non-round scales into account.Qgis::SCALE_PRECISIONworkaround.QgsMapLayer->isInRange().equalToOrGreaterThanMinimumScale()andlessThanMaximumScale()to make scale conditions more readable, with corresponding tests.Sample of inconsistent behavior fixed by this PR:
Map layer
Expected: Layer shouldn't be rendered if map scale is a non-round number equals to layer's
minimumScale(exclusive).Current (screenshot): Range: 25000-50000, map scale: 49999,999999999716. The layer is rendered.
Note the map scale combobox shows 50000 as the current map scale (denominator).
Rule-based labeling
Expected: Labels within a rule should be rendered if map scale is a non-round number equals to rule's
maximumScale(inclusive).Current (screenshot): Rule's scale range: 50000-100000, map scale: 49999.99999999976. The labels are not rendered.
Note the map scale combobox shows 50000 as the current map scale (denominator).
Similar issues can be reproduced for rule-based rendering.
Note: Those non-round map scales can be consistently obtained by resizing the QGIS main window (Ubuntu Linux) and resetting the scale to a round number via main Scale combobox. Users think the scale is still round (according to the combobox), but internally, it's a non-round number (in practice, equal to the round one).
Making scale depentent visibility more robust when handling non-round numbers would also cover use cases where, e.g., plugin devs set non-round scales via PyQGIS, as a result of a calculation.
Additional fixes:
Fix #58150
Other users have reported this longstanding issue, for instance:
#2863 (comment)
#42443