[Qgis-developer] QGIS Processing Framework

[Camilo Polymeris]

Thanks, Martin, for your well-thought-out response!

>> https://github.com/polymeris/qgis/wiki/QGIS-Processing-Framework
>>
>> Would that more or less fit what you have in mind? Please comment/criticize.
>
> The discussion was not going into implementation details, we were
> mostly collecting the ideas how the things should work.

Yes. I wrote that API description not so much thinking it would be the
actual interface, but as a way of reflecting on what issues could
arise and how to solve them.

> Framework implementation: as you write in the proposal, ideally it
> should be implemented in C++ with Python bindings. I would suggest you
> to start the implementation in Python and skip C++ coding at least at
> the beginning.

Ok. I think that's a good idea. I'll start with Python and later see
when (and if) migration to C++ makes sense.

> Forms/Parameters: I would start with with generic input fields (line
> edit / spin box) for integers, floats, strings that can be constrained
> with a range (numbers) or regular expressions (strings) - easily
> achieved with QValidator classes. Then some custom widgets can be
> added for better handling of some types: layer selector, enumeration
> etc. The framework may be extensible so that if a library often uses a
> particular custom type, the plugin integrating the library could add a
> custom widget for it.

Agreed. In general I think it may be a good idea to keep the GUI stuff
in QGIS and have the implementations only care about interface to the
various systems.

BTW, in the document linked above I use the term "library" for a
collection of modules, as opposed to "implementation" for a given
interface to a system (GRASS, SAGA, OTB). There may be more than one
library per implementation. Just to clarify-- terminology can be
changed, of course. I don't even know if the title ("Processing
Framework") is accurate. Perhaps "Analysis" is a better name.

> Advanced parameters: some modules may allow users set lots of
> parameters. Although this is handy, many times the default values work
> well and only few basic parameters are changed regularly. It should be
> possible to mark some parameters as advanced and they would be hidden
> by default, they would show up after clicking a checkbox or a button.
> For example, when creating a vector buffer, the distance would be a
> basic parameter while the number of segments per quadrant would be
> advanced parameter.

Good point. SAGA, as far as I know, does not provide information on
which parameters are considered basic and which are advanced. Perhaps
a list of parameters considered advanced can be included with the
plugin. Not very elegant, because it would be out-of-sync with SAGA,
but practical.

> Categorization: currently we are starting to face some trouble with
> organization of plugins and the "modules" they provide. We thought
> about creating fixed categories as in GRASS (e.g. Raster, Vector,
> Database) where the modules would be placed. We also considered custom
> categories and subcategories. The general problem with categories is
> that many modules do not suit them well if they are not coming from a
> well-organized library such as grass, saga or otb.
> The conclusion that I recall from the discussion at hackfest is that
> tagging is probably the only way to go: each module could have several
> tags assigned to it, then the list of modules would be a tree with top
> level items containing tags and modules would be shown inside these
> tags. Bigger libraries requiring deeper hierarchy might come with
> hierarchical tags like "SAGA/Grid - Tools". The names of tags will be
> left for developers' creativity.
> This list of processing modules should later get some advanced
> functionality like searching, favourite modules or even attaching most
> used modules on a toolbar, but that is something for the future, we
> are not expecting you to do that during the summer :-) A simple tree
> listing tags and modules assigned to them will suffice.

Again, SAGA provides no tag information. It would have to be generated
programatically from library/module name & description or provided in
a list.
Any thoughts on the GUI for that tree? More like SAGA's module tree or
more like GIMP's filter menu? I don't think the
search/filter/favorites/frequently used part is very hard.. but still,
I will keep things simple.

> Feedback: many modules are able to return some feedback - either in
> the form of a progress to indicate how long the process will take - or
> to return some messages that will be shown to user. Support for
> cancelling a running module would be helpful too, but not really
> necessary right now.

Related topics:
* Interactive modules. I had this more or less resolved for SAGA (I
think), but designing a more generic solution could prove difficult.
* Pushing pipelining to the implementation: Potentially more
efficient, but less generic.
* Parameter value serialization: load and save "presets" to file
* Undo & redo ability.

I am eager to see what the OTB team has come up with. I am not very
familiar with that system, but from what I have seen their programming
interface is quite elegant.

Regards,
Camilo