Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[fix] Make scale dependent visibility more robust when handling non-round scales (denominators) #58968

Conversation

gacarrillor
Copy link
Member

@gacarrillor gacarrillor commented Oct 4, 2024

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:

  • Harmonizes scaled dependent visibility for map layer rendering, rule-based rendering, rule-based labeling, single and stacked diagrams and app's 'Zoom to Visible Scale' action.
  • Makes sure the inclusive range limit (maximum scale) is taken into account.
  • Suggests to use qgsDoubleNear() for equal checks, thus taking non-round scales into account.
  • Deprecates the Qgis::SCALE_PRECISION workaround.
  • Adds more tests for QgsMapLayer->isInRange().
  • Adds 2 handy methods equalToOrGreaterThanMinimumScale() and lessThanMaximumScale() 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).

Screenshot from 2024-09-26 18-19-20_maplayer_min_non_exclusive_non_round

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).

Screenshot from 2024-09-30 20-59-00_rule_based_labeling_max_non_inclusive_non_round

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

…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)
@github-actions github-actions bot added this to the 3.40.0 milestone Oct 4, 2024
@gacarrillor gacarrillor added Map and Legend Related to map or legend rendering Labeling Related to QGIS map labeling GUI/UX Related to QGIS application GUI or User Experience Symbology Related to vector layer symbology or renderers Diagrams Bug Either a bug report, or a bug fix. Let's hope for the latter! labels Oct 4, 2024
Copy link

github-actions bot commented Oct 4, 2024

🪟 Windows builds ready!

Windows builds of this PR are available for testing here. Debug symbols for this build are available here.

(Built from commit 2b4deba)

src/core/qgis.h Outdated Show resolved Hide resolved
@gacarrillor
Copy link
Member Author

gacarrillor commented Oct 4, 2024

@nyalldawson, should I also implement this for the label's scale dependent visibility widget?

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.

image

Copy link
Collaborator

@nyalldawson nyalldawson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice cleanups, thank you!

@nyalldawson
Copy link
Collaborator

@gacarrillor

should I also implement this for the label's scale dependent visibility widget?

Yes, let's make it consistent throughout! Feel free to open that in a new PR.

@nyalldawson nyalldawson merged commit 0c7ea8f into qgis:master Oct 7, 2024
30 checks passed
@gacarrillor gacarrillor deleted the scale_dependent_robustness_non_round_scales branch October 8, 2024 21:26
@chau-intl
Copy link
Contributor

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
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Diagrams GUI/UX Related to QGIS application GUI or User Experience Labeling Related to QGIS map labeling Map and Legend Related to map or legend rendering Symbology Related to vector layer symbology or renderers
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Scale Dependent Visibility on layer wrong on scale interval edges in EPSG:25832
3 participants