In the OGR provider, we can read:
```
Some ogr drivers (e.g. GML) are not able to determine the geometry type of a layer like this.
In such cases, we use virtual sublayers for each geometry if the layer contains
multiple geometries (see subLayers) otherwise we guess geometry type from first feature
```
It means that in DescribeFeatureType Geometry element can be describe as simple and the GML contains
simple and multi. It's not XML valid.
To fix it, for OGR provider Geometry element type is set to `gml:GeometryPropertyType`
For the next release, it will be interesting to allow users to specify whether the geometries are multi.
- make QgsVectorFileWriter respect QTime field values and only
convert to string if required by output format
- list time types as native types for memory, postgres and OGR
providers (OGR support depends on file format)
The raster blend mode test, which uses QgsMultiBandColorRenderer
fails occasionally for no obvious reason. This additional test
is an attempt to narrow down whether the issue lies in
rendering multi band images or elsewhere.
* Move height and angle expressions for 2.5D renderer to layer
* Apply color based on main symbol color
This makes the transition to other renderers easy.
Fixes#14132
During rendering, two new variables will be available:
* `geometry_part_count`
* `geometry_part_num` (1-based index)
Useful to apply different styles to different parts of multipart
features
(only works with Cartographic point label placement). When this
setting is active, the label distance applies from the bounds
of the rendered symbol for a point, instead of the point itself.
It's especially useful when the symbol size isn't fixed, eg if
it's set by a data defined size or when using different symbols
in a categorised renderer.
Sponsored by Andreas Neumann
In the project properties the user can:
* activate INSPIRE capabilities
* select language of the service, 24 EU official languages + 5 regionals
* choose the scenario for service metadata and specify them
The WMS 1.3.0 capabilities reflects the INSPIRE configuration.
The 'layercount' attribute was not used anyway and the calculated number could already be outdated when loading the project file again due to changes to embedded projects.
A new control for setting a label's "z-index" has been added to
the labeling properties dialog. This control (which also accepts
data-defined overrides for individual features) determines the order
in which label are rendered. Label layers with a higher z-index
are rendered on top of labels from a layer with lower z-index.
Additionally, the logic has been tweaks so that if 2 labels have
matching z-indexes, then:
- if they are from the same layer, a smaller label will be drawn
above a larger label
- if they are from different layers, the labels will be drawn in
the same order as the layers themselves (ie respecting the order
set in the legend)
Diagrams can also have their z-index set (but not data defined)
so that the order of labels and diagrams can be controlled.
Note that this does *NOT* allow labels to be drawn below the
features from other layers, it just controls the order in which
labels are drawn on top of all the layer's features.
Fix#13888, #13559
