Re: Qgis-developer Digest, Vol 138, Issue 36

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: Qgis-developer Digest, Vol 138, Issue 36

Andreas Plesch-2

Date: Tue, 11 Apr 2017 04:41:32 -0700 (MST)
From: Tom Chadwin <[hidden email]>

Yes, I mean that all models are made up of discrete algorithms, and those
algorithms will only really work as intended if chained together as in the
model. Nevertheless, the algorithms will appear in the Processing toolbox,
so users could try to use them in isolation, and have difficulty forming the
required inputs. Or do you prevent the individual algorithms appearing in
the Processing toolbox?

I believe there is always the option to turn a model into an algorithm using the Export as Python script functionality of the model editor.

The underlying algorithms still need to be available but could be in their own group ('advanced', 'atomic', 'dangerzone :)') and the integrated algorithm could be named accordingly as well ('runme :)').

But in the end it comes down to making more universally (perhaps within the problem domain) useful algorithms and providing good documentation ( which is pretty easy using the built-in help system ). For example, I came to the conclusion that is useful to have a very basic algorithm 'write string to file' as a basic building block of models using algorithms which output strings and digest files.

I had similar concerns and started to think that it should be possible to 'compile' a script (recursively) which uses processing.runalg down to a script which only uses 'native' api functionality and 'native' algorithms. Effectively, patching in the called script source (perhaps as a function?). The 'compiler' could perhaps be an algorithm itself. This way it would be easy to provide just a single algorithm which is not depending on other custom algorithms.



Qgis-developer mailing list
[hidden email]
List info: