[Qgis-developer] SAGA Interface [for QGIS]

[Camilo Polymeris]

I have updated the proposal addressing some of your comments. Any
other ideas are welcome, I can still update it until tomorrow
(Friday).

The code (so far) is at:
https://github.com/polymeris/qgis/tree/master/python/plugins/sagamodules

The proposal follows.
Regards,
Camilo


Short description: Implement a QGIS plugin that makes it possible to
run the versatile "System for Automated Geoscientific Analysis" (SAGA
GIS) modules from Quantum GIS. Generate a GUI on-the-fly and run the
modules using either the SAGA command-line application or the SAGA
Python API, if available. Automate the process of information exchange
between those two systems.

Status: pending

Additional info: http://github.com/polymeris/qgis

Name: Camilo Polymeris
Country: Chile
School and degree: Universidad de Concepción, undergrad student
Email: cpolymeris at gmail.com
Phone: +56978837327
OSGeo project(s): Quantum GIS
Title: SAGA Interface for QGIS

Describe your idea
1. Introduction

Implement a QGIS plugin that makes it possible to run the versatile
cross-platform "System for Automated Geoscientific Analysis" (SAGA
GIS) modules from Quantum GIS.
Generate a GUI on-the-fly and run the modules using either the SAGA
command-line application or the SAGA Python API, if available.
Automate the process of information exchange between those two systems.


2. Background

SAGA, the System for Automated Geoscientific Analyses, is built in a
modular way. Its modules provide an ample range of functionality --
from data format import and export to algorithms for quite specific
tasks.

But it lacks a modern interface.

QGIS with its nice interface, on the other hand, while quite powerful
and usable, could use more field-specific tools for analyis.


3. The Idea

A python plugin for QGIS could bridge that gap, providing a better UI
for SAGA, while expanding the capabilities of QGIS.

SAGA provides at least the following three interfaces:

    * C++ API
    * Python API (equivalent to C++ API)
    * saga_cmd program

I would implement a plugin that interfaces to SAGA transparently
through either of the latter two, depending on which is available.
Current SAGA installations (binary packages) typically only provide
saga_cmd, the Python module has to be built by the user, but is more
powerful. In particular, interactive modules can only be run through
the API, not the command line.

Possible pitfalls I have identified are:

    * Time. The task is concise and well defined, but the schedule is
      tight. I have kept two weeks of buffer to deal with any contingencies.
    * Compatibility. Python often has compatibility problems between
      versions. I have some experience dealing with this, but unexpected
      issues can always arise. To prevent this it is important that testing
      is done with all target versions of python, and if possible, on
      diferent installations (architecures, operating systems).
      There could also be issues with SAGA and QGIS API for different
versions. This will have to be considered during implementation.
    * Data compatibility. Implementations may differ, and in
particular large files can be problematic because of the conversion
overhead involved. I intend to start simple, but taking this in
consideration when choosing exchange formats. Luckily, both QGIS and
SAGA offer a great deal of options in this regard.

The timeline includes two buffer weeks to handle any contingency or delay.

Deliverables

    * Research
    * Software design - including requirements, class hierarchy and
implementation notes
    * Code - python
    * Build environment - cmake based to fit in with rest of QGIS
    * Profiling report
    * Basic installation & usage instructions
    * Weekly progress report - in addition to more frequent informal reports
    * Mid-term & final evaluations

4. Project plan

A written report on progress will be provided every Thursday,
additional to more informal reports through the week.

To get familiar with QGIS I have already started working on part of
the following. I have been posting to qgis-developers, and the code is
available on github.com

0) PRE-GSOC (now, due )

    * April 8: Proposal
    * April 25 - May 5: Development environment
    * May 6 - May 24: Software design
    * May 19 - May 24: Setup project


1) FIRST TERM GOAL, due July 12: Implement basic functionality, have
most non-interactive modules working. (using only saga_cmd)

    * May 25 - May 31: Plugin registration
      "                       Library & module handling
    * June 1 - June 7: Basic module list
      "                       Module dialog, generic widget for options
    * June 8 - June 14: Specific widgets & constraints
    * June 15 - June 23: Input/output handling: Grid & shape
    * June 24 - July 5: Running saga_cmd
    * July 6 - July 12: Buffer week


2) SECOND TERM GOAL, due Aug 16: Polish functionality and interface,
have non-interactive  and at least part of the interactive modules
working. (using saga_cmd and saga_api)

    * July 17 - July 22: Complete library & module handling using
saga_api (loaded if available, else fall back to saga_cmd)
    * July 23 - July 29: Interactive modules: Grid
    * July 30 - Aug 6: Input/output handling: Tables and other
    * Aug 7 - Aug 9: Polish packaging and distribution
    * Aug 10 - Aug 16: Buffer week - if unneeded this time can be
allocated to bug removal and simple documentation (Installation, basic
usage).

5. Future ideas / How can your idea be expanded?

  3) POST-GSOC GOAL: Add support for remaining modules, including
interactive modules. Other interface improvements.

    * Interactive modules: Line, Box, Circle
    * Better help / user feedback


Please provide details of general computing experience:

I work almost exclusively under Linux (Debian). I can and have written
programs in C, C++, Python & Lua, among others.

As a geosciences student I frequently work with science related
software, including SAGA, Octave, NumPy. I prefer open-source
software, when possible.

Please provide details of any previous involvement with GIS
programming and other software programming:

I have never done GIS programming per se, but have experience with
other software programming. Some of the projects I have worked on are:
Naev (a game written in C), libmagt (gravimetric tensor library, C++),
emutrix (a GUI-centric audio tool, C++, Qt) and assorted smaller
programs, mostly related to geosciences and often written in Python
(using NumPy, SciPy, matplotlib).

Please tell us why you are interested in GIS and open source software:

I use SAGA as a tool and often come across other geoscience software
during my studies. I have been using OSS for almost 10 years now, and
love the opportunity it has given me to learn.

For science, in particular, I think the transparency provided by open
source software is vital in promoting reproducibility of results.

Please tell us why you are interested in working for OSGeo, the
software project you have selected and your specific coding project:

I like to see a better user interface for the SAGA modules. As a SAGA
end-user I think that's the single most important feature missing from
an otherwise excellent system.

Also I'd like to contribute back to a tool and a community that has
made my work so much easier. The extra insight I will get in how both
SAGA and QGIS work is a bonus.

Would your application contribute to your ongoing studies/degree? If so, how?

Yes! I study earth sciences, but given my interests in programming and
OSS, I will try to make a career in the field of (geo-)science
computing. This would be an excellent learning opportunity and also a
good addition to my CV.

Please explain how you intend to continue being an active member of
your project and/or OSGeo AFTER the summer is over:

Primarily by maintaining the plugin code.

I may also tackle other projects, for example I'd like to see if I can
implement some of the gravity-related algorithms I studied while
working on libmagt as plugins for QGIS.

Do you understand this is a serious commitment, equivalent to a
full-time paid summer internship or summer job?

Yes, I do.

I will be studying (about 12 hours a week) during a small part of the
first GSoC term, but have planned to recover those hours during
weekends, or alternatively by starting coding earlier, if there is no
objection.


Any comments are most welcome.

Camilo <cpolymeris at gmail.com>

[Updated April 7th]