- for algorithms that produce directory output, it is possible to test
that directory contents are exactly the same (recursively)
- added possibility to have a project file loaded before an algorithm is run
- documented the new additions (+ few existing ones)
This is useful with geometry algorithms when the order of the coordinates of produced
geometries does not need to be exactly the same every time, but the output is still
topologically equivalent.
...by moving extra arguments to new LayerOptions structs. This allows
us to more easily add new layer constructor options without making
the API cumbersome to use.
processing tests
Some algorithms will return results in different orders, e.g.
due to the use of dicts or other methods which do not guarantee
a fixed return order.
Using a primary key to do the feature match allows us to flexibly
handle these situations and provide tests for these algorithms.
tests
Some algorithms are non-deterministic and the results may vary from
run to run. In this case we allow specifying multiple possible valid
results, and the test will pass if the result layer matches any of these.
Differences in gdal libraries mean the hash value may differ between
platforms. Allow multiple acceptable hashes to be listed for
expected test results
initAlgorithm() method
This allows 2 benefits:
- algorithms can be subclassed and have subclasses add additional
parameters/outputs to the algorithm. With the previous approach
of declaring parameters/outputs in the constructor, it's not
possible to call virtual methods to add additional parameters/
outputs (since you can't call virtual methods from a constructor).
- initAlgorithm takes a variant map argument, allowing the algorithm
to dynamically adjust its declared parameters and outputs according
to this configuration map. This potentially allows model algorithms which
can be configured to have variable numbers of parameters and
outputs at run time. E.g. a "router" algorithm which directs
features to one of any number of output sinks depending on some
user configured criteria.
Since it's safe to evaluate parameters in background threads
now, it's usually going to be ok to evaluate everything in
the processAlgorithm step.
This keeps the algorithm code as simple as possible, and will
make porting faster.
Note that the prepare/postProcess virtual methods still exist
and can be used when an algorithm MUST do setup/cleanup work
in the main thread.
While the processing API is in such a state of flux it's
become unmaintainable to port these algorithms change-by-change.
Instead, disable them all until the API is fixed, and then we
can port them algorithm by algorithm and reactivate each
test in turn.
