Allows for map renders to be filtered by a z or elevation range,
such that only parts of the layer which are considered within
this range will be rendered.
Implements https://github.com/qgis/QGIS-Enhancement-Proposals/issues/201
*Requires support for respecting the QgsRenderContext zRange to be added
to the relevant map layer renderers
If set, this extent will be used when zooming to full extent (or for the
full extent for a map overview frame) instead of the extent calculated
from all map layers.
The intention is to eventually allow users a way to manually set their
desired "area of interest" for a project, so that zooming to full extent
won't zoom all the way out when the project contains global or national
datasets...
Try to remember/set last timeframe (upon timestep- or timeframe-changes).
Setting the stepsize to a different size, did reset the slider to start
(aka timeframe 0).
Same when you changed the range (data time) extent.
This commit tries to set the slider to the same position as before the
step change, if possible). Else it will take the position of the timeframe
in which the start of the old timeframe fits.
fixes#39994
While it was possible to set the opacity for individual symbol layer
colors via data defined expressions, it's so far been impossible to
set a data defined expression to control the overall symbol opacity.
This commit fixes that omission...
The SIP_FACTORY annotation didn't do the job for a Python implementation
of createChildren(). We must write a custom VirtualCatcherCode to make
sure that if the returned QgsDataItem elements are Python objects they
aren't killed too early.
Fixes the new added test, which uses to crash before the fix,
and corresponds to the use case of a plugin defining its own data items.
Has been checked not to cause memory leaks.
The change of SIP_FACTORY to SIP_TRANSFERBACK is to avoid a memory
leak when Python calls a C++ createChildren() implementation. Was found
by making test_provider_ogr.py::testDataItems() loop on its call to
createChildren()
All the logic for rendering non-opaque layers is handled in a layer
type agnostic way already, so this just allows the existing handling
to be used for mesh/point cloud/vector tile/etc layers also
