Utilisez-vous un workflow éprouvé pour éditer et documenter des modèles ArcGIS ModelBuilder?

Avez-vous une référence à des exemples de meilleures pratiques ou pouvez-vous partager votre expertise sur la façon de suivre les modifications apportées aux modèles ModelBuilder, de suivre les modifications entre les versions de modèle / outil et de maintenir la stabilité, la robustesse et la fonction du modèle?

Je connais les directives ESRI sur la gestion, la copie et la dénomination des modèles ici .

Je serais intéressé si quelqu'un a établi des pratiques ou une expertise spécifique dans l'utilisation du suivi de version, de l'archivage, de l'édition des outils ModelBuilder qu'ils utilisent avec succès pour suivre le développement et la vérification des modèles et pour maintenir les modèles dans un état stable.

Actuellement, nous conservons simplement les boîtes à outils sur un serveur de fichiers Windows et rétrogradons en utilisant la fonctionnalité " Versions précédentes " en cas de problème.

Je cherche à stocker des boîtes à outils dans Git (en utilisant TortoiseGit et GitHub Enterprise ), que nous utilisons déjà pour les scripts Python et les espaces de travail FME . Étant donné que les boîtes à outils standard sont binaires, vous ne pouvez pas les différencier et les fusionner de manière interactive comme vous le feriez avec des fichiers de texte brut, mais vous pouvez toujours obtenir des messages / historique de validation, des balises, des branches et fusionner des fichiers binaires entiers (tout ou rien).

La meilleure chose que je pense que vous pourriez faire serait de passer complètement à Python et d'utiliser des boîtes à outils Python et des compléments Python au lieu de ModelBuilder. De plus, si vous avez FME qui peut faire à peu près tout ce que vous pouvez faire avec ModelBuilder et généralement beaucoup plus efficacement et facilement, et est plus auto-documenté, avec des signets, des annotations, des descriptions d'espace de travail, etc.

Avec GitHub, vous pouvez utiliser ses fonctionnalités Wiki ou Pages pour une documentation plus complète.

Une méthode plus basique mais toujours efficace consiste simplement à inclure un fichier texte lisez-moi avec des informations sur le but, l'utilisation et l'historique de la boîte à outils / modèle.

Je ne pense pas qu'il existe un moyen de suivre les changements dans un modèle pendant que vous le construisez et je ne sais pas pourquoi vous voudriez le faire de toute façon?

Ce qui est important, c'est d'expliquer aux autres le raisonnement derrière votre modèle. Par exemple, pourquoi vos entrées doivent-elles se trouver dans une géodatabase fichier, pourquoi avez-vous créé un champ et divisé une valeur par un autre nombre?

Ce type d'informations importantes est essentiel pour les utilisateurs et le développeur qui doit les récupérer lorsque vous "vous faites écraser par un bus". :)

Il y a deux endroits où je documenterais un modèle, en tant qu'étiquettes dans le générateur de modèles (celles-ci seraient dirigées vers les développeurs) et dans la description de l'élément (métadonnées) de l'outil. Vous pouvez vraiment aller en ville en ajoutant des informations utiles qui guident un utilisateur.

Malheureusement, la plupart des personnes qui développent des modèles font un mauvais travail en ajoutant des informations aux paramètres, ce qui rend le modèle difficile à comprendre si vous y revenez des mois plus tard. Je le sais ... je l'ai fait!

Quelques minutes passées maintenant à ajouter des descriptions à un paramètre de modèle peuvent transformer un modèle utile en un excellent outil qui est rapidement adopté par une organisation, sinon son autre modèle à moitié désarchivé qui disparaît rapidement sur votre lecteur réseau!

En plus de ce qui a déjà été dit, je suggère d'essayer de stocker votre boîte à outils dans une base de données ArcSDE. Cela peut vraiment aider pour l'édition et l'accès simultanés. Je sauvegarde également cette base de données afin de pouvoir revenir en arrière en cas de problème.

Pour plus de détails, jetez un œil à une autre de mes réponses .

Dans la partie "documentation", utilisez l' éditeur de métadonnées aka Description de l'article , voir Présentation rapide des outils de documentation et des boîtes à outils .

La boîte de l'éditeur de texte enrichi est fonctionnelle mais limitée. Enregistrez et vérifiez souvent les résultats dans l'aperçu de la description de l'élément et dans la boîte de dialogue de l'outil lui-même, car certains formats peuvent être mélangés ou non conservés, en particulier les éléments de liste. Vous pouvez coller à partir de Word, Onenote, Dream Weaver, etc. pour obtenir un démarrage rapide, mais à moins que le formatage ne soit vraiment simple, il sera gâché rapidement.

(Une mise en garde: l'ancienne méthode consistait à utiliser la boîte de dialogue "Modèle >> Modifier >> Propriétés du modèle" et à y coller du code html dans le champ "Description". Si vous le faites ou l'avez fait, lorsque l'éditeur de description d'article accède au contenu est copié, ce qui est formidable. Cependant, les modifications que vous apportez ne seront pas recopiées. Supprimez donc la version des propriétés du modèle pour éviter toute confusion.)

Le contrôle de version est possible en sortant un peu de la boîte: lorsque vous affichez la description de l'élément, affichez le menu contextuel, cliquez sur >> Afficher la source , puis enregistrez le code HTML dans votre dossier source-control / docs . Les images sont omises, mais si vous souhaitez ajouter encore un peu de travail, vous pouvez examiner le code HTML et les récupérer %temp%.

Vous pouvez obtenir un plus grand degré de contrôle en référençant un fichier d'aide compilé (CHM) . Le point de départ semble être Microsoft HTML Help 1.4 .