This action shows the log of that child step, regardless of whether
or not it failed. This is handy for debugging model errors after
testing, when you've already closed the algorithm window...!
When editing a model through the designer (and after having run
that model), you can now right click any child step in the model
and select "View Output Layers". This will add the output layers
from that step as new layers in the current QGIS project.
This action is available for ALL child algorithms in the model,
even if the model is not configured to use the outputs from those
children as model outputs.
This is designed as a helpful debugging action. If a user's model
fails (or gives unexpected results), they can then trace through
the model and view the outputs for suspected problematic steps.
It avoids the need to add temporary outputs to a model and re-run
to test.
Additionally, this action is always available after running the model,
EVEN if the model itself failed (eg because of a misconfigured
step later in the model).
Sponsored by City of Canning
Even when the model execution fails, store the child inputs and
results for all steps which successfully completed in the context.
This gives more debugging information to a user when a model fails,
because these values will now be reflected in the model designer
view for all steps which completed.
After running a model through the designer dialog, any layers generated
during the execution of the model will now be transferred into a layer
store attached to the dialog, instead of immediately discarded. This
includes layers generated by child algorithms as intermediate steps
and not just model outputs.
By moving the lifetime of the generated layers to the designer dialog,
we are able to do things with these layers after the run algorithm
dialog is closed. (Eg allowing users to load them to a project)
The designer's layer store is cleared on each run of the model.
We now always call QgsProcessingAlgorithm::postProcess, even when
the algorithm fails for some reason (eg it raises an exception).
This ensures that the context cleanup logic in postProcess is
always run. Note that we still ONLY call an algorithm's specific
postProcessAlgorithm implementation for successful executions,
so the public facing API and behavior remains unchanged.
This is intented to provide a consistent handling of the cleanup
logic in postProcess, specifically to make sure that that the
context thread handling logic is triggered in all cases.
When an algorithm has a point parameter and is run from the toolbox,
show a X rubber band marker at the picked point on the map canvas
This makes it easier to see where the point parameter is set to.
The marker is cleared as soon as the algorithm dialog is closed.
Adds an optional end point distance threshold parameter to the
network analysis tools. Previously (and still, by default) endpoints
will ALWAYS be snapped to the nearest point in the network layer,
regardless of how far away from the network they actually are. This
can result in meaningless results, as the tools will happily snap
points to a road hundreds of kilometers away :)
Now, there's an optional end point distance threshold parameter
for these tools. The behaviour of the threshold depends on the
algorithm:
- For the “Service area (from layer)” tool an optional new output
was added for “non routable features”. This output will contain
any features which were deemed too far from the network. All
other features which are within tolerance distance to the
network will be stored in the standard output from the tool.
- For the “Service area (from point)” tool an error will be raised
if the point is too far from the network
- For the “Shortest path (point to point)” tool an error will
be raised if either the source or destination points are too far
from the network.
- For the “Shortest path (layer to point)” and “Shortest path (point
to layer)” tools:
- An error will be raised if the **point** is too far from the network.
- A new optional output was added for “non routable features”. This
output will contain any features which were deemed too far from the
network. All other features which are within tolerance distance to
the network will be stored in the standard output from the tool.
Sponsored by City of Canning
When 'canRead' property for a published WFS layer was set to False
from an access control filter plugin the whole /collections reques
was returning a 404 insted of returning the list of published layers
(minus the filtered ones).
