(fix#20586).
Without this parameter it is not possible to remove collars surrounding
input raster which may overlap with other input rasters. As this is very
frequent case algorithm is useless without such parameter. To keep API
compatibility new parameter is optional and not used by default.
flag in a single call
This is much more efficient then making two calls, since the
QgsRasterBlock::isNoData() check internally calls QgsRasterBlock::value().
So by requiring API users to make the two separate calls individually,
we double the time this process takes...
This allows users to pass additional command-line arguments which are
not exposed in the algorithm definition. The most frequent use case is
enabling transparency and adding nodata values.
actually fetching the raster block data
This allows for efficient iteration over a "reference" layer, where
you require the block extent/origin/pixel size/etc (but not the
reference layer block data itself!), in order to fetch a block from
a DIFFERENT set of rasters (but keeping these pixel-aligned to the
reference raster).
Followup https://github.com/qgis/QGIS/pull/8830 that fixed
a regression with rewritten urls in the server, unfortunately
my original solution introduced a side-effect on the POST
request, with the new approach I'm introducing a new method
to retrieve the URL as seen by the web server: by default
this is the same URL seen by QGIS server, but in case
a rewrite module made some changes, the original URL will
be used as a base URL if not overridden by a config setting.
This PR comes with an extended set of tests that should
cover both (rewritten and unrewritten) cases for GET and
POST and for WFS/WFS/WCS and WMTS.
The SAGA version of this algorithm is of limited use in QGIS, because the
volume calculated is embedded only in the SAGA terminal output. This prevents
it being saved to a file, or reused within a model as an input to a later
model step.
It's also very user-unfriendly, because users must know to manually scan
the algorithm log to find the SAGA output.
Given that the maths here is trivial, this commit ports the algorithm across
to be a native QGIS c++ algorithm. The algorithm duplicates the SAGA alg
1:1, but outputs the volume (and area) to either a HTML report, or a vector
table. Additionally, the outputs are exported as numeric outputs from the
algorithm, allowing them to be re-used within models.
(It's also considerably faster, because it avoids the forced conversion
to SAGA raster format)
Fixes#8607 (properly, even though that report is closed)
This feature allows for expressions to be embedded directly inside
legend item text (e.g. group, subgroup and item text). The expressions
are evaluated at render time, with full knowledge of the legend's
expression context (so can utilise variables from the layout/layout item/
etc)
There's no UI for this yet (that will come in 3.8), but expressions are
entered using the standard [% 1 + 2 %] format.
E.g. a legend item text of
My layer (rendered at 1:[% @map_scale %])
will show in the output as
My layer (renderer at 1:1000)
Adds new variables for use in data defined expressions for layout legend items, including
- @legend_title
- @legend_column_count
- @legend_split_layers
- @legend_wrap_string
- @legend_filter_by_map
- @legend_filter_out_atlas
Additionally, if the legend is linked to a map, then expressions used in that legend will also have access to the linked variables, including @map_scale, @map_extent, etc.
has been linked to a project color
Instead of only showing linked color status in the accompanying
data defined button, we now also show it inside the color button
itself. So now the button color is a live reflection of the
project color it is linked to.
Additionally, when the color is linked, the button only allows
users the choice of "unlinking" the color from the linked
project color. The usual color button options allowing users
to directly change the color are not present. (As linked
colors must be edited in the project colors section from
the project properties dialog)
This allows optional creation of geodesic lines, which represent the
shortest distance between the points based on the ellipsoid.
When geodesic mode is used, it is possible to split the created lines
at the antimeridian (±180 degrees longitude), which can improve
rendering of the lines. Additionally, the distance between vertices
can be specified. A smaller distance results in a denser, more accurate
line.
