Roadmap¶
These are the functionalities and elements to be implemented before releasing a stable version (v.1.1)
This all priority features that should be ready before the next version of QGIS is released.
Homogenization of algorithm access, display and help¶
There is already an alternative organization for algorithm, targeted at the non-advanced users, which can be enabled in the SEXTANTE configuration. When this is active, algorithms do not appear as belonging to a provider, but just under a common branch simply called "algorithms". All available algorithms are classified in categories, independently of their origin. This gives a more homogeneous interface and should make it easier for users to select the algorithm they need. To have this ready to be used and have a consistent toolbox, the following tasks are needed:
- Defining a set of categories, based on a criteria that is agreed as the best one (or even define several of them, according to different criteria, such as field of application, type of data it needs, etc).
- Define categories for each algorithm, and also alternative names, since now they do not follow a similar pattern (GRASS ones, for instance, are too verbose). Ideally, this should be stored independently of the algorithms and their names, so it can be used as a decoration, and different naming schemes can be used, or a different classification.
- Write help files for algorithm using a common template. A single help file written in RestructuredText, that can be turned into HTML to display basic ideas about each algorithm, like a description of the process or an explanation about the meaning of each input and output. Algorithms already documented (like GRASS ones), should be easily adapted to this in some automated way.
All this tasks require quite a bit of work, but it is work that can be somehow outsourced to the community by putting into a wiki or easy-to-edit format. A Google spreadsheet might be a good alternative for editing alternative names for algorithms or classifying them in groups.
Quality assurance and testing¶
Unit testing¶
Unit tests for different parts of SEXTANTE
Algorithm tests¶
Manually define meaningful tests with an example data test, for each SAGA and GRASS algorithm.
There is some very simple data sets with raster and polygon layers in the tests/folder. These layers should be used to create examples of use for each algorithm, and then the result should be check to see that the values are correct. The correctness of the process should be left to the external application itself, so main task is at least to check that, with the provided values (which are meaningful and correct), the call to the external process is working and there are no problems.
This can somehow be outsourced as well, as it is easy to write a couple of test (even doing them from the toolbox and then sending the corresponding python code that it's automatically generated)
Extended postprocessing tasks for algorithm that need it¶
Write customized methods for adding non-generical behaviour to those algorithms that have some special design (undeclared output layers, outputs via console, etc)
Additional features.¶
Documentation and examples.¶
Write a larger collection of example scripts and algorithms, and a manual about extending SEXTANTE, targeted at Python developers
Other ideas for future work¶
- PySAL (Python spatial Analysis Library
- HPGL - High Performance Geostatistics Library
Testing Feedback¶
- Please add feedback on any modules you have tested and/or bug submits that request feedback or marked resolved.
Testing Wiki