Closed jakimowb closed 1 week ago
Do we want to use actual algorithms to build the test model? Or shall we rather have some test algorithms that we combine to a test model? I would prefere the second option, because it is saver. Using actual algorithms would break the model, every time we change the algorithms.
Probably the first option is better, as it shows a "real" use-case. As long as neither the algorithm id's change, nor the required inputs, I don't see a problem here. Shouldn't our processing algorithms be that stable meanwhile?
Alright, let's start with a simple L2 import: https://raw.githubusercontent.com/EnMAP-Box/enmap-box/948-qgis-processing-test-model-with-enmap-box-algorithms/tests/testdata/processing/importEnmapL2.model3
Here is a tests for the model: _enmap-box\tests\enmap-box\enmapboxprocessing\testcustomModel.py
As discussed in personal meeting, we like to show that EnMAP-Box algorithms and processing models created in QGIS can also be used in HPC / server processing environments (no GUI, but many CPUs, e.g. https://portal.azimuth.cms.hu-berlin.de/). Therefore we need an exemplary QgsProcessingModel that can be used in, for example, unit tests and by other scripts that demonstrate the use of QGIS / EnMAP-Box processing models.
Create an exemplary QgsProcessingModel that uses multiple QgsProcessingAlgorithms from the EnMAP-Box provider. For example a workflow that imports EnMAP images and applies a classification model on it. (multiple raster inputs and outputs would be nice.
Save the model in *.model3 XML (https://docs.qgis.org/3.34/en/docs/user_manual/processing/modeler.html#saving-and-loading-models). I think it's good if it could become part of the standard EnMAP-Box testdata suite.