Add configurable extent buffer to symbol layers

[JuhoErvasti]

Fixes #38579.

Allows the user to set an extent buffer per symbol layer. Useful with for example geometry generator symbols:

2024-11-28.13-21-52.mp4

Works with a negative buffer as well:

2024-11-28.13-25-10.mp4

Works with labels which are placed by the geometry generator:

2024-11-28.13-31-49.mp4

When rendering QgsVectorLayerRenderer finds the biggest buffer value that has been set and requests features from the buffered extent. Further filtering per symbol layer is done in QgsSymbol.

Backport to 3.40 requested (if possible).

Funded by the National Land Survey of Finland.

[github-actions]

🪟 Windows builds

Download Windows builds of this PR for testing.
Debug symbols for this build are available here.
(Built from commit 371ee87)

🪟 Windows Qt6 builds

Download Windows Qt6 builds of this PR for testing.
(Built from commit 371ee87)

[github-actions]

Tests failed for Qt 6

One or more tests failed using the build from commit 371ee87

buffer_extent_zero

buffer_extent_zero

Test failed at testRenderWithExtentBuffer at tests/src/python/test_qgsvectorlayerrenderer.py:848

Rendered image did not match tests/testdata/control_images/vectorlayerrenderer/expected_buffer_extent_zero/expected_buffer_extent_zero.png (found 54 pixels different)

The full test report (included comparison of rendered vs expected images) can be found here.

Further documentation on the QGIS test infrastructure can be found in the Developer's Guide.

[nyalldawson]

@JuhoErvasti thanks for tackling this annoying problem!

I have a few thoughts on the approach used here:

• I don't think this needs to be a symbol-layer property, rather it makes more sense to be a setting on a whole symbol itself. What's the pressing use case where one symbol layer would need a different size to the rest of the symbol? In my opinion doing this at the symbol layer considerably complicates both the code + the user experience.
• If we made this a symbol setting, then the setting could be moved to sit inside the symbol "advanced" menu. This would help avoid the UI clutter that results from adding a rarely-changed, advanced setting directly inside ALL symbol layer property windows. (There's also a side issue caused by adding this spin box in the horizontal line with the existing widgets, as it considerably increases the minimum width for the panel, which will cause issues on smaller screen sizes)
• What's the use case for data-definable buffers? I can't see how we'd ever need to set this on a per-feature basis. And right now this could ONLY be used to decrease the buffer size from the fixed amount, which sounds like an incredibly esoteric requirement. If there's a need to set data-definable buffer size eg to handle logic with different map scales/crs/..., then it should be evaluated ONCE for the layer and not on a per-feature basis (and make sure that the widget for it doesn't expose feature related context variables)

[JuhoErvasti]

@nyalldawson

I don't think this needs to be a symbol-layer property

I agree that making it a symbol layer property does complicate things and the use cases for separate buffer levels are probably few and far between. The reason I did it this way was based on your comment from the issue's discussion:

I'm +1 for a configurable buffer parameter, but it needs to be done at the symbol layer level.

I interpreted this to mean that it does need to be a symbol layer property, but reading the thread again you might've meant it as a symbol property (as opposed to layer/project property as suggested by others)? Either way if that isn't the requirement, I'm happy to change it to be on the symbol level.

If we made this a symbol setting, then the setting could be moved to sit inside the symbol "advanced" menu.

Sounds good.

What's the use case for data-definable buffers?

I figured it'd be good to be able to control the buffer with an expression (for example to make it scale-dependant as you mentioned) and since I was adding it as a symbol layer property it made sense to use a data-defined button since almost everything else has one. But if the location of the property is changed, this can of course be changed too.

Could it be even just a normal expression widget, not a data-defined override button?

If there's a need to set data-definable buffer size eg to handle logic with different map scales/crs/..., then it should be evaluated ONCE for the layer

If it's done on the symbol level, how should this work? If you're using f.e. the graduated renderer you could set a different expression/value for each symbol, same with the geometry generator subsymbols. Wouldn't it have to be evaluated at least once per each symbol in the renderer?