zoom levels for the tile's data
It seems that every VTPK behaves a bit like an indexed VTPK
where higher zoom level tiles may be replaced with lower
zoom level tiles. This new special handling is required
for non-indexed VTPKs where the high zoom level tile data
is empty, but there's not explicit tilemap present to
advise of us this situation in advance.
Fixes#52872
matching scales
When activated, this option ensures that the horizontal and vertical
scales are always kept equal (so that eg a 45 degree slope will appear
as a 45 degree slope in the profile)
and auto-set the "represents elevation" flag for these
We do this when:
- the layer contains only one band
- the data type is int or float (not complex, rgb or byte)
- the layer doesn't have an attribute table
- there's something "dem-like" in the layer's name (ie 'elevation',
'dem', 'height', 'srtm')
This should help make the elevation profile tool more user-friendly,
as these layers will be included in the profiles by default
elevation related properties to their layers
And use this to ensure that wms tiles with maptiler terrain
or terrarium terrain interpretation are always included by
default in elevation profile plots.
Most specifically, this ensures that projects containing the
out-of-the-box "Mapzen Global Terrain" layer will be automatically
included in elevation plots.
* load layers in parallel threads when opening project
* parallel loading by default and settingsin advanced settings
* fix freezing when no layer supports parallel loading
* clean leftover
* fix unwanted remove and typo
* typo
* fix flake8
* load OGR metadata under global mutex
* Revert "load OGR metadata under global mutex"
This reverts commit adcaf9e66ca432ee35143c45af2b383108770a63.
* remove parallel loading capability for OGR
* start application in server test
* import start_app
* fix flake8
due to presence of tilemap, ensure that we always use the actual
render zoom level to match styles for the tile instead of the
zoom level corresponding to the tile
Otherwise we'll be rendering different rules depending on the
actual tile source, when we should always use the actual
rules for the current map scale
always be used for the layer (as opposed to any previously
stored matrix sets)
For some vector tile data providers this is more appropriate --
specifically for those with tilemap information where we MUST
ensure that the tilemap matches the data source or missing
tiles may be present. (If we store the matrix set information
in projects then loading older projects may mean that a stored
tilemap is out-of-sync with the actual data source's current
tilemap).
This allows us to correctly handle "indexed" vector tile sets,
where higher zoom level tiles may be missing where a lower
zoom level tile is deemed to have sufficient detail for higher
zoom levels.
form widgets
This exposes two new "size" options for edit form widgets, allowing
control over the horizontal and vertical stretch factors for the
widget. By setting a horizontal or vertical stretch, users can
control how edit widgets will relatively resize when resizing
an attribute form.
Eg a user can set a higher horizontal stretch value for widgets which should
"grab" more of the available horizontal space, eg for those widgets
which are expected to have longer values and accordingly will
benefit from the extra space.
Similarly, the vertical stretch setting controls how widgets
will relatively grow vertically when resizing forms vertically. (Note
that only some widgets can vertically grow -- eg. spin boxes
can't be stretched vertically!)
Together these options give more control to users over the exact
layout and sizing of their attribute forms.
By default, the stretch values are set to "Default" which is the
same as previous behavior.
It's possible that an algorithm's postProcessor may contain logic
relating to the layer tree, so make sure that all layers have
already been added to the tree before calling postProcessors
This adds a new "Reorder Model Outputs" action to the model designer
menu (to accompany the existing "Reorder Model Inputs" action).
Selecting this option allows model creators to set a specific order
which the outputs from their model must use when loading the results
into a project. This gives the model creator a means of ensuring
that layers are logically ordered, eg placing a vector layer over
a raster layer and a point layer over a polygon layer.
Optionally, the model creator can also set a "Group name" for the
outputs. If this is specified then all outputs from the model will
be placed into a (newly created if necessary) layer tree group
with that name.
Sponsored by the QGIS Germany User Group
This gives more flexibility in future to handle known missing tiles or
other special circumstances (eg falling back to lower
zoom level tiles from the matrix set in certain circumstances)
- add 0.1, 0.5, 1.0 common angles
- add an option to show current common angle in the floater
- add 'N' 'SHIFT+N' keyboard shortcuts to cycle through the
common angle options
