... 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()
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.
In OGC WMS standard, the empty string represents the default style.
QGIS Server when it parses the parameters, QGIS Server when it parses parameters it removes empty parts.
When all requested styles are default ones it's equal to an empty parameter STYLE, as defined in the standard.
When only one layer is requested, there is no issue with custom or default style.
When multiple layers are requested and some with custom styles, because QGIS Server does not retain empty strings, it loses the layer / style match.
To fix it, keeps empty parts for not empty styles parameters.
and thus we cannot change it's settings once it is created
Signed-off-by: Marco Bernasocchi <marco@opengis.ch>
Signed-off-by: Marco Bernasocchi <marco@opengis.ch>
Signed-off-by: Marco Bernasocchi <marco@opengis.ch>
add init_server method
Signed-off-by: Marco Bernasocchi <marco@opengis.ch>
Use own qgs application so we can change the env settings
Signed-off-by: Marco Bernasocchi <marco@opengis.ch>
Signed-off-by: Marco Bernasocchi <marco@opengis.ch>
remove unused mServerSettings
Signed-off-by: Marco Bernasocchi <marco@opengis.ch>
Fix typo and code style
Signed-off-by: Marco Bernasocchi <marco@opengis.ch>
Fix test
Fix test
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 logic is too complex and fragile -- we should drop support for proj 6.0
as soon as we can, so that we can the inbuilt handling which
is enabled for proj >= 6.1 only.
