Les modules GRASS peuvent être lancés depuis les Outils GRASS de QGIS si QGIS a été ouvert depuis une console GRASS ou si un jeu de données GRASS a été ouvert dans QGIS. Ces modules ne fonctionnent qu’avec des données GRASS.
Il est facile de modifier le menu et d’y ajouter de nouveaux modules car le menu et les modules sont configurés via des fichiers XML. Ci-dessous, voici comment écrire de nouveaux modules et comment modifier l’arborescence du menu.
Les options de chaque module affichées dans l’onglet _*Options_* du module sont créées en se basant sur la définition présente dans le fichier QGM (QGIS GRASS module) ainsi que la définition présente dans le module GRASS ou le script GRASS GMO (GRASS module options). Etant donné que chaque option dans le QGM est liée à une (ou plusieurs) option(s) dans le GMO, il est souvent nécessaire de consulter le fichier GMO. Les GMO sont extraits par le module GRASS lorsqu’il est lancé avec l’option _*–interface-description_*, la sortie étant au format XML, par exemple:
r.to.vect --interface-description
Certains modules GRASS ont trop d’options qui peuvent être confuses pour des débutants. Dans le fichier QGM, il est possible de n’en définir que certaines et de leur attribuer une valeur par défaut ou de cacher certaines options. Cela signifie que plusieurs modules QGIS-GRASS peuvent être définis pour un module GRASS. Par exemple le module r.to.vect a été séparé en trois modules QGIS-GRASS avec des options prédéfinies. La définition QGM est écrite en XML avec une extension en .qgm, un fichier par module QGIS-GRASS. Les fichiers de configuration sont stockés dans le répertoire _*qgis/src/plugins/grass/modules*_ et installés dans le répertoire _*share/qgis/grass/modules*_. Le nom du fichier doit commencer par le nom du module GRASS + un mot décrivant la tâche. Par exemple, le module qui extrait des lignes vecteur depuis un raster est appelé r.to.vect.line.qgm.
Voici un exemple de fichier de configuration :
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE qgisgrassmodule SYSTEM "http://mrcc.com/qgisgrassmodule.dtd">
<qgisgrassmodule label="Generate aspect map from DEM" module="r.slope.aspect">
<option key="elevation" />
<option key="aspect" />
</qgisgrassmodule>
Chaque étiquette qgisgrassmodule peut contenir une ou plusieurs options:
<option key="elevation" />
<flag key="o" answer="on" hidden="yes" />
<field key="column" layer="map" type="integer,double" label="Attribute field" />
<selection key="list" layerid="input" label="Cats" />
typeoption — cette option est utilisée avec les couches vecteur pour définir le nom de l’option du type de vecteur d’entrée. Lorsque le module est lancé, le type de la couche vecteur sélectionnée est utilisé pour cette option. Par exemple (v.overlay.or.qgm):
<option key="ainput" typeoption="atype" layeroption="alayer" typemask="area,line" />
Cela signifie que si une couche est sélectionnée dans la liste déroulante, l’option _*atype*_ reçoit automatiquement le type de la couche et que cette variable n’a pas à être ajoutée.
layeroption — équivalent à typeoption pour une couche (non vecteur).
typemask — définit les types de couches vecteur d’entrée autorisés. Seules les couches de l’un des types définis seront affichées en entrée. Voir v.overlay.or.qgm comme exemple.
layer — l’attribut essentiel de l’option qui détermine le vecteur qui dépend de ce champ.
type — définit le type des champs d’attribut qui doivent être ajouté à la liste déroulante des champs, par exemple:
<field key="column" layer="map" type="integer,double" label="Attribute field" />
Cela signifie que seuls les champs d’attribut de type entier ou réel double seront présents dans la liste déroulante. Consultez v.what.vect comme exemple (2 vecteurs différents).
L’idée de l’implémentation des modules QGIS-GRASS est d’utiliser le maximum d’informations des fichiers GMO et de simplifier l’interface. Voici quelques règles sur la manière dont sont utilisées les informations GMO et dans quel ordre elles sont utilisées si elles ne sont pas toutes définies dans le GMO.
Chaque module doit être représenté par une icône qui symbolise la fonction du module. Les icône sont stockées dans le répertoire plugins/grass/modules au format SVG (.svg) ou PNG (.png).
Actuellement, il existe 3 schémas pour les images:
Le nom de l’image commence par le nom du module QGIS-GRASS auquel est ajouté un numéro d’image, par exemple: v.overlay.and.1.svg, v.overlay.and.2.svg, v.overlay.and.3.svg. Il est possible de combiner des images SVG et PNG.
Les images PNG et SVG peuvent être générées depuis le Composeur de cartes de QGIS. La taille des images PNG est généralement plus volumineuse que la taille de l’icône car il est attendu qu’elles seront utilisées plus tard dans la documentation générée automatiquement où les images utilisées ont une taille plus grande.
Étant donné qu’il peut se passer beaucoup de temps pour qu’un nouveau script soit ajouté à la version stable de GRASS et parce que certains scripts peuvent être utiles seulement pour l’interface graphique de QGIS, il est possible d’ajouter des scripts “GRASS” à QGIS. Les scripts doivent suivre les règles des scripts GRASS et il sont situés dans le répertoire qgis/src/plugins/grass/scripts.
Les Outils GRASS sont plutôt destinés aux novices et pas pour les utilisateurs avancés. Les règles de base sont les suivantes :
Techniquement n’importe quelle option peut être employée. Certains types d’options ne sont pas gérées correctement, par exemple, celles qui dépendent d’une autre option. Voici une liste (probablement incomplète) d’options qui ne sont pas gérées correctement et qui ne devraient pas être utilisées pour le moment:
La majorité des modules peuvent être ajoutés. Si vous en avez besoin de plus, merci d’écrire sur la liste de diffusion de développement de QGIS et de lister les modules que vous pensez être les plus important à ajouter.
Vous devriez publier le nom d’un nouveau module QGIS-GRASS ainsi que le module GRASS et les options que vous souhaitez utiliser. Par exemple:
r.to.vect.area: r.to.vect input output feature=area
Consultez également la liste des modules GRASS-QGIS pertinents.
Voici une liste de modules qui devraient être supprimés avec une explication sur leur problème (ex: certains modules liés aux projections sont difficiles à comprendre et ne sont pas d’une grande utilité). Merci de note que certains modules n’ont pas été complètement testés. Merci de les tester et de remonter une erreur sous redmine (ou mieux encore de faire la correction vous-même et d’envoyer un patch).