[Qgis-developer] QGIS Processing Framework

[Camilo Polymeris]

>> https://github.com/polymeris/qgis/wiki/QGIS-Processing-Framework
>>
>> Would that more or less fit what you have in mind? Please comment/criticize.
>
> Nice work. One other thing to consider is having a validator class -
> knowing the type of a parameter is often not enough. The idea with the
> validator class would be to create validation rules that can do things
> like bounds checking, checking if a file path is valid, checking if a
> layer named in a parameter exists in the registry etc. I guess this is
> partly covered by your getConstraints method, but maybe we need
> something more flexible...

Yes, that was the idea behind getConstraints and getChoices. Of course
a validator class is a more elegant and flexible solution.
There is QValidator, which is quite simple, inherited by versions for
integers, floats and strings (using regex). We could provide some
other validators we identify as important, e.g., TableValidator or
AngleValidator.

The type list can be extended, too, and I think many cases can be
handled in that way. SAGA uses about 25 different types.
The advantage of using fixed types is that other parts of QGIS can
handle them smarter: We could e.g. have a FileLayer type and a
MemoryLayer type, let the implementation specify which format it
prefers, and have QGIS do the rest: loading or saving the file (or
not). And in both cases present the same interface to the user (or
next module in the pipeline).

In summary, I lean towards a simple validator class, accompanied by a
set of pre-defined types: a compromise between flexibility and
"smartness".

A related consideration is that some parameters may be optional, or
(worse) some combination of parameters may be optional.

> Also some thought could be given to making the execution of tools
> operate well outside of a gui context. This would open us up to for
> example exposing the tools via the QGIS mapserver as WPS at some point
> in the future. OTB has some nice infrastructure in place that allows
> tools to be purposed in multiple ways e.g. console, library or gui.
> and it would be nice to emulate this.

I will keep that in mind. Anything in the current interface that would
not work well outside the gui context?

> For me the ultimate conclusion of this kind of work and integration
> would be the implementation of some kind of workflow engine  in QGIS
> (ala kepler / vistrails / triana) so it is exciting to see the work
> you are doing and I think it would be really great to harmonise the
> implementation of OTB/SAGA/GRASS tools within QGIS.
>

I think that is what I meant by "pipeline," which is the term OTB
uses. I did not consider that in the mock-up API, because:
a) It's complicated. Possibly the hardest part to do right.
b) I think it could be designed later, on top of this framework.

I will have a look at the projects you mention... see how they do it,
get some inspiration.

Thanks for all your comments,

Regards,
Camilo