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
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.
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)
This container always lays out child widgets in a horizontal
row, where the number of columns is automatically determined
by the number of child widgets.
It's useful for creation of compact forms, where no space will
be wasted by assigning extraneous horizontal width to widgets
where the expected values will always be short.
Eg: creating 3 rows with 3, 2, 1 child widgets respectively
results in the layout:
Attr 1: [...] Attr 2: [...] Attr 3: [...]
Attr 4: [..........] Attr 5: [..........]
Attr 6: [...............................]
Without the option of row containers then the all horizontal
rows will have the same number of columns, eg:
Attr 1: [...] Attr 2: [...] Attr 3: [...]
Attr 4: [...] Attr 5: [...] Attr 6: [...]
(leaving insufficient horizontal length for attributes 4-6), or
Attr 1: [..........] Attr 2: [..........]
Attr 2: [..........] Attr 3: [..........]
Attr 4: [..........] Attr 5: [..........]
Attr 6: [..........]
(resulting in wasted horizontal space next to attribute 6, and
an extra row taking up vertical space)
Sponsored by NIWA
efficiently for many calls
Allows retrieval of some basic algorithm properties (display name,
icon) in an optimised way for many calls. (Avoiding multiple
expensive algorithmById lookups)
QgsAbstractDatabaseProviderConnection
When implemented by providers, will provide a method for
permanently setting field aliases/comments within a
database
Here we have no choice but to create a new Capability2
enum, as the original Capability has now consumed the
entire range of values for data types permitted by QFlag
datasources which support editing comments
This support is currently limited to the postgres provider,
so exposing the comment field for all other vector layer types
is just misleading to users. The comment will be completed discarded
without any warning!
