Algorithmes de traitement Model Baker : le kit DIY pour tes workflows

Avec la dernière version, QGIS Model Baker 8.4, trois nouveaux algorithmes de traitement ont été réalisés. Ils rendent la boîte à outils encore plus utile pour mettre en place des workflows spécifiques avec Model Baker et ili2db dans QGIS.

Comme on le sait, ce qu’on fait soi-même procure le plus de plaisir. Et même si Model Baker met depuis des années le backend à disposition sous forme de package Python, il faut tout de même être un peu hacker pour construire quelque chose avec ce backend. Et même si les modèles de traitement dans QGIS ne sont peut-être pas non plus ce qu’il y a de plus facile à digérer, l’utilisateur final peut déjà assimiler des workflows existants et les modifier au besoin.

C’est pourquoi nous avons construit ce petit cas d’usage avec les nouveaux algorithmes de traitement et le décrivons ici pour vous sous forme de petit guide pas à pas.

Il s’agit de dupliquer un jeu de données valide afin de continuer à travailler dessus tout en conservant une copie de sécurité. Bien sûr, on pourrait aussi le faire avec ilivalidator et pg-dump, mais pas en un seul clic. Pour couronner le tout, c’est que nous pouvons simplement enchaîner des algorithmes de traitement dans un modèle de traitement.

Nous voulons donc maintenant créer un nouveau schéma correspondant au schéma source, puis exporter les données du schéma source de manière valide et les importer dans le nouveau schéma.

C’est parti! Ouvrir le Model Designer dans le menu Traitement > Concepteur de modèles.

Pour commencer, nous donnons un nom au modèle. Si nous l’enregistrons maintenant, QGIS propose notre dossier de profil et nous le retrouverons par la suite dans la boîte à outils de traitements. Nous pouvons toutefois l’enregistrer n’importe où et le charger individuellement.

Ou bien (et c’est le plus cool), le lier à un projet QGIS avec « Enregistrer le modèle dans le projet »: on peut alors le lancer directement depuis le menu du projet.

Passons au point d’entrée. Les paramètres de base de données du schéma source, dont nous avons besoin pour créer le nouveau schéma, peuvent être extraits d’une couche vectorielle.

La source de données de la couche vectorielle peut être analysée avec l’algorithme utilitaire Model Baker Get Parameter from Layersource.

L’entrée peut être reliée au moyen d’une entrée de modèle (Model Input).

Enfin, nous choisissons l’algorithme Model Baker Create schema with ili2pg…

… et nous relions les paramètres de base de données analysés via la sortie d’algorithme (Algorithm Output) de l’algorithme précédent.

Soit dit en passant, on peut aussi relier les sorties aux entrées par glisser-déposer (dans les versions récentes de QGIS).

Stop, nous ne pouvons pas tout relier tel quel. Le schéma doit bien sûr être un nouveau schéma. Idéalement, nous voulons qu’il porte le même nom, mais avec un timestamp en plus. Pour cela, nous pouvons utiliser une valeur précalculée (Pre-calculated Value), qui nous permet de créer une expression.

Outre les fonctions standard now() et format_date(), nous pouvons maintenant utiliser la sortie des autres algorithmes comme variable. Ici @Get_parameter_from_layersource_SCHEMA, et construire ainsi notre nouveau nom de schéma.

Essayons-le tout de suite. Avec le triangle vert « Play » dans la barre d’outils, le panneau apparaît à droite pour lancer l’algorithme.

Mais sans succès. Aucun modèle INTERLIS n’est fourni. Évidemment. Nous n’avons repris que les paramètres de base de données et n’avons défini aucun autre paramètre ili2db. Nous pourrions les configurer comme entrées de texte ou les remplir avec des valeurs par défaut.

Ce serait évidemment super sympa si nous pouvions aussi lire les paramètres ili2db depuis le schéma source. Et cela serait possible avec la commande ili2db --exportMetaConfig. On pourrait alors transmettre directement à ili2db la configuration avec laquelle le premier schéma a été créé. La bibliothèque Model Baker propose aussi l’API pour cela. Toutefois, ce composant n’est pas encore implémenté comme algorithme. Ce serait chouette que cela arrive un jour…

On va réessayer, et cette fois-ci, ça marche.

Nous avons donc un nouveau schéma, il faut maintenant y transférer les données. Pour cela, nous utilisons l’algorithme Model Baker Export with ili2pg. Comme paramètres d’entrée, nous prenons également les paramètres de base de données de la couche vectorielle. Nous reprenons aussi le schéma de là.

Cet algorithme exporte les données, pour autant qu’elles soient valides, dans un fichier XTF et renvoie le chemin comme paramètre de sortie. Sans autre indication, le fichier XTF se trouve dans le répertoire temporaire.

Nous importons maintenant ces données dans notre nouveau schéma. Pour cela, nous utilisons l’algorithme Model Baker Import with ili2pg.

Les paramètres d’entrée intéressants sont le schéma, que nous reprenons de Create schema with ili2pg, et le Source Transfer File, pour lequel nous prenons le fichier XTF de Export with ili2db.

D’où proviennent les paramètres de base de données importe en réalité peu. Les algorithmes Model Baker transmettent en principe les paramètres de base de données sans les modifier. Par souci de clarté, nous les prenons de là où nous prenons aussi le schéma (Create schema with ili2db). Nous pourrions toutefois aussi les prendre de la couche vectorielle.

Essayons.

Cela fonctionne à merveille. Il prend les paramètres de la couche vectorielle choisie, crée un nouveau schéma basé sur le modèle INTERLIS, exporte les données du schéma source et les importe dans le nouveau schéma. Terminé.

L’ordre d’exécution est correct, même si l’algorithme d’export prenait plus de temps. Cela vient du fait que l’algorithme d’import dépend directement de sa sortie. Si ce n’était pas le cas et que l’on souhaitait tout de même conserver l’ordre, on pourrait encore définir des dépendances. Ainsi :

Et maintenant ? Nous pourrions créer un projet QGIS à partir du nouveau schéma. Malheureusement, l’algorithme Model Baker “Generate Project” n’existe pas encore. Faisons-le donc à la main avec Model Baker. Si nous utilisons les UsabILIty Toppings, nous pourrions aussi reprendre les configurations étendues.

Alternativement, nous pourrions bien sûr aussi modifier les sources du projet actuel. Et si nous avions travaillé avec de nouvelles bases de données plutôt qu’avec de nouveaux schémas, nous aurions pu utiliser le même projet grâce aux fichiers de service (comme décrit ici).

Si tu veux essayer ça toi-même, tu trouveras ici le modèle de traitement:

Et pour un autre cas d’usage – comment construire un modèle avec les algorithmes de traitement Model Baker afin d’exporter un sous-ensemble de données – tu trouveras ici dans la documentation de Model Baker, ainsi que des descriptions plus détaillées des algorithmes.

Amuse-toi bien à tester!