Je travaille à l’IGN et nous migrons une partie de notre outillage vers QGIS pour le processus de collecte. A ce titre, nous allons développer des plugins génériques et d’autres plus spécifiques. Peut être que dans certains cas, une amélioration de QGIS natif pourrait être demandé.
Je commence à prendre contact avec la communauté QGIS et je me pose des questions sur l’organisation de la participation aux plugins et à QGIS même.
J’ai pu voir qu’il y a un git pour créer des issues ici : Issues · qgis/QGIS ? mais ne faut-il pas discuter avec la communauté avant de créer un ticket? Qui participe à ces développements? Comment se mettre à disposition pour les améliorations?
Pour les plugins, nous allons en déposer sur les dépôts officiels QGIS en espérant qu’ils puissent servir à d’autres utilisateurs (pour les plugins génériques), comment demander l’approbation d’un plugin? Comment participer à l’approbation d’autres plugins? Qui les valide?
Je poste en me disant que les réponses pourront intéresser d’autres personnes.
Désolée, si cette question a déjà été traitée, je ne l’ai pas vue.
Bonjour Mélanie et bienvenue dans la communauté QGIS, et merci pour ta présentation. Très heureux de voir l’implication de l’IGN se renforcer.
L’écosystème des extensions, traitements et ressources communes est justement là pour laisser les utilisateurs libre de réaliser des développements en s’appuyant sur le framework QGIS.
Les avantages en sont une plus grande simplicité de développement, un cycle de vie séparé de QGIS et une installation simplifiée.
Les limites sont que lorsque c’est le fonctionnement du coeur de QGIS qui est limitant, le plugin proposera une alternative, mais devra être maintenu par son auteur, qui devra lui même créer sa propre communauté si il ne veut pas supporter tous les coûts de maintenance. Lorsque plusieurs personnes identifient un problème ou un manque fonctionnel dans QGIS, et les tickets sont là pour centraliser ces besoins, c’est le moment où il faut se poser la question de faire évoluer QGIS core. Ce sera plus solide, performant pour des missions critiques qu’un contournement python. Mais cela se planifie plus sérieusement, en évaluant la faisabilité, en estimant la version cible QGIS qui recevra la fonctionnalité et la version long terme LTR qu’on voudra déployer en production ;
Depuis très peu de temps, il n’est plus nécessaire de passer le parcours du combattant de la création du compte osgeo et son mantra, un antispam humain efficace, mais un peu lourd, et il est possible de se logguer avec des services tiers ( pour l’instant github, gitlab.com , google, et bientôt notre propre gestionnaire qgis.org)
Tu as bien fait!
C’est toute la vocation de ce forum. Un plugin qui a vocation d’être un commun à l’échelle française mérite totalement d’être discuté ici. On avait fait ça pour le plugin de recherche d’adresse BAN, le plugin cadastre etc…