[SoC] Re: [Qgis-developer] SAGA Interface

[Camilo Polymeris]

> I hope your GSoC proposal will be accepted! I'm an earth scientist too
> (geologist), and I'm going thorugh the same way of you: passion for IT and
> OSS, and programming. Now I would like some more "earth" back in my daily
> work, but we can't have eveything! :)
> So good luck Camilo!

Thanks for yout support. I, too, am a geologist (in training). But I
have taken as many courses in geophysics as possible. Solid earth,
mostly.

> Back to the module. Are we sure that offering two options (with or without
> saga_api) is feasible? I mean from the point of view of the effort. Probably
> you have already investigated this...

I belive so, yes. I'll try to encapsulate the functionality in one
class as well as possible. If SAGA ever offers good saga_api packages,
we can drop saga_cmd support.

> I was also wondeing about two points:
>  - should the plugin accept only layers previously loaded in QGis? This is
> the way Sextante works inside Gvsig (I suppose you know it). It enables only
> the plugins that accept the type of layer actually loaded (eg, vector
> inputs, raster inputs, etc.). Another possibility is to let the user choose
> wether to use a layer already loaded or browse for it on the filesytem (or
> db, etc.).

Both are valid possibilities. I'll start with loaded only layers I
think, but don't see why we couldn't offer the user the option to
browse for a layer.
I think I'll designate one exchange format for each of raster and
vector, if possible. Then if SAGA can't handle the original input
format, I'll just have QGIS convert it to that exchange format.
Outputs will always be in that exchange format, to keep things simple.
That is, unless overhead or compatibility problems begin to show up.

>  - would you provide the saga-python module with the plugin? We could offer
> it, specifying wich version of SAGA it was been built for, to help those
> users which can't build the plugin by their own...

You mean the binary saga_api python module? That would mean loosing
portability. (Binary python modules are not portable)
This is the primary reason I want to offer saga_cmd as a (limited)
fall-back option.. so that it works on any platform without need for
recompiling.

What do you think?

Regards,
Camilo