for QgsVectorLayer, when constructing a layer with a URI which
may be invalid
These may be used for layers where the geometry type/CRS is
known in advance, and where the layer path may not be
initially resolvable. (E.g. layers with a URI pointing to a
non-existant file). It is only ever used if the layer cannot
be resolved, otherwise the actual layer geometry type will be
detected and used for the layer.
... you are too slow and QJson API is so ugly.
Now using this wonderful json lib:
https://github.com/nlohmann/json
Results in release mode (QJson tests are not shown but
QJson was even slower than string concat).
PASS : TestQgsJsonUtils::testExportAttributesJson(Use json)
RESULT : TestQgsJsonUtils::testExportAttributesJson():"Use json":
0.0022 msecs per iteration (total: 75, iterations: 32768)
PASS : TestQgsJsonUtils::testExportAttributesJson(Use old string concat)
RESULT : TestQgsJsonUtils::testExportAttributesJson():"Use old string concat":
0.0032 msecs per iteration (total: 54, iterations: 16384)
PASS : TestQgsJsonUtils::testExportFeatureJson(Use json)
RESULT : TestQgsJsonUtils::testExportFeatureJson():"Use json":
0.011 msecs per iteration (total: 96, iterations: 8192)
PASS : TestQgsJsonUtils::testExportFeatureJson(Use old string concat)
RESULT : TestQgsJsonUtils::testExportFeatureJson():"Use old string concat":
0.015 msecs per iteration (total: 64, iterations: 4096)
PASS : TestQgsJsonUtils::testExportGeomToJson(Use json)
RESULT : TestQgsJsonUtils::testExportGeomToJson():"Use json":
0.76 msecs per iteration (total: 98, iterations: 128)
PASS : TestQgsJsonUtils::testExportGeomToJson(Use old string concat)
RESULT : TestQgsJsonUtils::testExportGeomToJson():"Use old string concat":
0.85 msecs per iteration (total: 55, iterations: 64)
PASS : TestQgsJsonUtils::cleanupTestCase()
We can use this when restoring the layer, if the uri turns out
to be invalid at that stage (e.g. a file has moved). By storing
and falling back to the last known wkb type, we avoid unnecessarily
discarding the existing layer renderer, and can still show the
expected layer type in the layer tree.
... and add a getter for coordinateTransform to QgsMapLayer
The reason is that I think we should reduce the dataProvider API
usage and rely on the higher level QgsMapLayer API whenever it
is possible, QgsMapLayer checks for data provider validity
and returns a default constructed QgsCoordinateTransform instead
of crashing.
which will be available to a parameter when it is evaluated.
Specifying variables via this method is for metadata purposes only.
It is the algorithm's responsibility to correctly set the value of
these additional variables in all expression context used when evaluating
the parameter, in whichever way is appropriate for that particular variable.
Previously, when marker or hash lines were rendered using interval
or center point place placement, the symbol angles were determined
by taking the exact line orientation at the position of the symbol.
This often leads to undesirable rendering effects, where little
jaggies or corners in lines which occur at the position of the
symbol cause the marker or hash line to be oriented at a very
different angle to what the eye expects to see.
With this new option, the angle is instead calculated by averaging
the line over a specified distance either side of the symbol. E.g.
averaging the line angle over 4mm means we take the points along
the line 2mm from either side of the symbol placement, and use these
instead to calculate the line angle for that symbol. This has the
effect of smoothing (or removing) any tiny local deviations from
the overall line direction, resulting in much nicer visual
orientation of marker or hash lines.
Like all symbol settings, the average angle smoothing distance
can be set using mm/pixels/map units/etc, and supports data-defined
values.
Closed rings also correctly consider wrapping around these average
angles from the start/end vertex.
(Sponsored by an anonymous corporate backer)
This line symbol type is designed to replicate the ArcGIS Hash Line
symbol layer type. It allows for a repeating line segment to be
drawn over the length of a feature, with a line-sub symbol used
to render each individual segment.
To reduce code duplication, this is heavily based off the current
line marker symbol layer, since the functionality is almost
identical (draw some sub symbol at some interval along a line).
Accordingly, I've split off QgsMarkerLineSymbolLayer to move
as much of the common functionality as possible to a new abstract
base class, so that only the actual marker/line segment rendering
occurs in the marker line/hash line subclasses.
This also gives the hash line all the existing placement options
permissible for marker lines -- e.g. first/last vertex, mid points,
regular intervals, etc.
The hash line length and angle can have data defined overrides,
which are evaluated per-line segment, allowing for the hash line
to change size and angle over the length of a single rendered
feature.
nearest neighbor search based on QgsGeometry to QgsGeometries
Previously only point - geometry was possible. But with this
change, you can safely and accurately use QgsSpatialIndex
to determine the nearest neighbours between any types of
geometries.
