[Qgis-community-team] Processing help

[Richard Duivenvoorde]

Hi Alexander,

thanks for taking the lead into this!

On 21-11-14 08:51, Alexander Bruy wrote:
> While I'm fully agree with moving algorithm help into main QGIS documentation
> repository, I still unsure about putting it into User Guide. My main
> concern is a
> large number of algorithms in Processing (and it will be even larger in future)
> which will lead to increasing size and page count of User Guide. Some time ago
> we have in User Guide list of GRASS modules, but later after discussion we drop
> it to make User Guide simpler and smaller. Maybe we should continue with
> keeping it clean.

In my memory only reason to pull out the GRASS modules from the
QGIS-Documentation was the fact that the pdf printed manual became too
big. And removing that part was at that moment(!) the easiest, to shrink
it back to normal proportions...

> So I'm thinking about slightly different solution:
>  * create new subfolder in documentation repo, e.g. processing_help
>  * move all existing algorithm help in this folder and organize them
> in sctuctured
>    way: provider (SAGA, TauDEM, QGIS, etc) → algorithm group (raster anlysis,
>    vector overlay, table tools, etc) → algorithms itself
>  * use same template for each algorithm description: general info (some
>    information about algorithm, how it works), inputs and outpus description
>    including limitations, command line usage (?)

Your solution looks ok, but I would not add a separate subfolder into
the repo, but make those 'help-pages' an integral part of the
QGIS-Documentation/source/docs/user_manual.

And if it is too big for print, we could add some Makefile rules to
shrink it down for certain use-cases. It is just adding them to the
'exclude_patterns'-list in the conf file.

> In this way we can keep User Guide relatively small and in same time have
> documentation on Processing algorithms. Moreover, if necessary we can easily
> embedd Processing docs into User Guide by adding several srings into main
> RST document. So we can produce small User Guide and "full self-contained"
> User Guide with all documentation.

Not sure if I understand the sentence about 'adding strings', but I
think we more or less mean the same, only you want to split up and merge
to create a 'Full doc', while in my opinion it is better to have a full
doc and remove parts which you do not want.

My main reason to do it in this way is to keep the Makefile easier
(there are already a lot of if's in it now)

Another reason is that we had the idea to have some service available
which could even create 'on the fly documentation or course material',
like: I want a small course with only vector docs/material, eg: "plz
create a 'training_manual' with only the vector stuff".

See what others like best.

Regards,

Richard Duivenvoorde